Author Topic: Hacking the DSO2X1X  (Read 25379 times)

0 Members and 2 Guests are viewing this topic.

Online DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1509
  • Country: es
Re: Hacking the DSO2X1X
« Reply #100 on: June 03, 2021, 11:40:00 pm »
More hacking! The Model, Serial, Vendor and PCB can be changed using the VISA API.
Running strings in Phoenix app showed to be very productive:
Code: [Select]
PRIVate:SET:SERIal
PRIVate:SET:SERIal?
PRIVate:SET:MODEl1
PRIVate:SET:MODEl2
PRIVate:SET:MODEl?
PRIVate:SET:VENDor
PRIVate:SET:VENDor?
PRIVate:SET:PCB
PRIVate:SET:PCB?
PRIVate:SET:LANGuage:VALId
PRIVate:SET:LANGuage:CONFig
PRIVate:CLEAr:EE
PRIVate:SET:BIAS
PRIVate:SET:CODE
PRIVate:SET:BOARD
PRIVate:SET:BOARD?
PRIVate:GET:ERRO?
PRIVate:FACTORY:RESET
PRIVate:WRITE:EEPROM
PRIVate:READ:EEPROM
PRIVate:READ:BANDWidth
PRIVate:TEST:RESUlt?
PRIVate:HARDWare:TEST
PRIVate:HARDWare:INFO
DDS:CAL:OFFSet
DDS:CAL:AMP
DDS:CAL:RESUlt
PRIVate:TEST:CH1:FACTOR
PRIVate:TEST:CH2:FACTOR
PRIVate:RELAY
SYSTem:ERRor?
SYSTem:ERRor:NEXT?
SYSTem:ERRor:COUNt?
SYSTem:VERSion?
SYSTem:IP
SYSTem:IP?
SYSTem:SET:TIME
SYSTem:TIME?
SYSTem:USB?
STATus:QUEStionable?
STATus:QUEStionable:EVENt?
STATus:QUEStionable:ENABle
STATus:QUEStionable:ENABle?
STATus:PRESet
AUTorange:STARt
AUTorange:STOP
SETUp:NORMal?
PRIVate:GET:STATus?
CHANnel1:BWLimit
CHANnel1:BWLimit?
CHANnel1:COUPling
CHANnel1:COUPling?
CHANnel1:DISPlay
CHANnel1:DISPlay?
CHANnel1:INVert
CHANnel1:INVert?
CHANnel1:OFFSet
CHANnel1:OFFSet?
CHANnel1:RANGe
CHANnel1:RANGe?
CHANnel1:SCALe
CHANnel1:SCALe?
CHANnel1:PROBe
CHANnel1:PROBe?
CHANnel1:VERNier
CHANnel1:VERNier?
CHANnel2:BWLimit
CHANnel2:BWLimit?
CHANnel2:COUPling
CHANnel2:COUPling?
CHANnel2:DISPlay
CHANnel2:DISPlay?
CHANnel2:INVert
CHANnel2:INVert?
CHANnel2:OFFSet
CHANnel2:OFFSet?
CHANnel2:RANGe
CHANnel2:RANGe?
CHANnel2:SCALe
CHANnel2:SCALe?
CHANnel2:PROBe
CHANnel2:PROBe?
CHANnel2:VERNier
CHANnel2:VERNier?
CHANnel3:BWLimit
CHANnel3:BWLimit?
CHANnel3:COUPling
CHANnel3:COUPling?
CHANnel3:DISPlay
CHANnel3:DISPlay?
CHANnel3:INVert
CHANnel3:INVert?
CHANnel3:OFFSet
CHANnel3:OFFSet?
CHANnel3:RANGe
CHANnel3:RANGe?
CHANnel3:SCALe
CHANnel3:SCALe?
CHANnel3:PROBe
CHANnel3:PROBe?
CHANnel3:VERNier
CHANnel3:VERNier?
CHANnel4:BWLimit
CHANnel4:BWLimit?
CHANnel4:COUPling
CHANnel4:COUPling?
CHANnel4:DISPlay
CHANnel4:DISPlay?
CHANnel4:INVert
CHANnel4:INVert?
CHANnel4:OFFSet
CHANnel4:OFFSet?
CHANnel4:RANGe
CHANnel4:RANGe?
CHANnel4:SCALe
CHANnel4:SCALe?
CHANnel4:PROBe
CHANnel4:PROBe?
CHANnel4:VERNier
CHANnel4:VERNier?
TIMebase:WINDow:ENABle
TIMebase:WINDow:ENABle?
TIMebase:WINDow:POSition
TIMebase:WINDow:POSition?
TIMebase:WINDow:SCALe
TIMebase:WINDow:SCALe?
TIMebase:WINDow:RANGe
TIMebase:WINDow:RANGe?
TIMebase:POSition
TIMebase:POSition?
TIMebase:SCALe
TIMebase:SCALe?
TIMebase:RANGe
TIMebase:RANGe?
TIMebase:MODE
TIMebase:MODE?
TIMebase:VERNier
TIMebase:VERNier?
TIMebase:XY:XSOUrce
TIMebase:XY:XSOUrce?
TIMebase:XY:YSOUrce
TIMebase:XY:YSOUrce?
ACQuire:MODe
ACQuire:MODe?
ACQuire:POINts
ACQuire:POINts?
ACQuire:TYPE
ACQuire:TYPE?
ACQuire:SRATe?
ACQuire:COUNt
ACQuire:COUNt?
TRIGger:FORCe
TRIGger:MODE
TRIGger:MODE?
TRIGger:COUPling
TRIGger:COUPling?
TRIGger:STATus?
TRIGger:SWEep
TRIGger:SWEep?
TRIGger:HOLDoff
TRIGger:HOLDoff?
TRIGger:NREJect
TRIGger:NREJect?
TRIGger:SENSitivity
TRIGger:SENSitivity?
TRIGger:EDGe:SOURce
TRIGger:EDGe:SOURce?
TRIGger:EDGe:SLOPe
TRIGger:EDGe:SLOPe?
TRIGger:EDGe:LEVel
TRIGger:EDGe:LEVel?
TRIGger:PULSe:SOURce
TRIGger:PULSe:SOURce?
TRIGger:PULSe:POLarity
TRIGger:PULSe:POLarity?
TRIGger:PULSe:WHEN
TRIGger:PULSe:WHEN?
TRIGger:PULSe:WIDth
TRIGger:PULSe:WIDth?
TRIGger:PULSe:LEVel
TRIGger:PULSe:LEVel?
TRIGger:SLOPe:SOURce
TRIGger:SLOPe:SOURce?
TRIGger:SLOPe:POLarity
TRIGger:SLOPe:POLarity?
TRIGger:SLOPe:WHEN
TRIGger:SLOPe:WHEN?
TRIGger:SLOPe:WIDth
TRIGger:SLOPe:WIDth?
TRIGger:SLOPe:ALEVel
TRIGger:SLOPe:ALEVel?
TRIGger:SLOPe:BLEVel
TRIGger:SLOPe:BLEVel?
TRIGger:TV:SOURce
TRIGger:TV:SOURce?
TRIGger:TV:POLarity
TRIGger:TV:POLarity?
TRIGger:TV:MODE
TRIGger:TV:MODE?
TRIGger:TV:LINE
TRIGger:TV:LINE?
TRIGger:TV:STANdard
TRIGger:TV:STANdard?
TRIGger:VIDeo:LEVel
TRIGger:VIDeo:LEVel?
TRIGger:TIMeout:SOURce
TRIGger:TIMeout:SOURce?
TRIGger:TIMeout:LEVel
TRIGger:TIMeout:LEVel?
TRIGger:TIMeout:WIDth
TRIGger:TIMeout:WIDth?
TRIGger:TIMeout:POLarity
TRIGger:TIMeout:POLarity?
TRIGger:WINDOw:SOURce
TRIGger:WINDOw:SOURce?
TRIGger:WINDOw:ALEVel
TRIGger:WINDOw:ALEVel?
TRIGger:WINDOw:BLEVel
TRIGger:WINDOw:BLEVel?
TRIGger:INTERVAl:SOURce
TRIGger:INTERVAl:SOURce?
TRIGger:INTERVAl:SLOp
TRIGger:INTERVAl:SLOp?
TRIGger:INTERVAl:WHEN
TRIGger:INTERVAl:WHEN?
TRIGger:INTERVAl:TIME
TRIGger:INTERVAl:TIME?
TRIGger:INTERVAl:ALEVel
TRIGger:INTERVAl:ALEVel?
TRIGger:UNDER_Am:SOURce
TRIGger:UNDER_Am:SOURce?
TRIGger:UNDER_Am:POLarity
TRIGger:UNDER_Am:POLarity?
TRIGger:UNDER_Am:WHEN
TRIGger:UNDER_Am:WHEN?
TRIGger:UNDER_Am:TIME
TRIGger:UNDER_Am:TIME?
TRIGger:UNDER_Am:ALEVel
TRIGger:UNDER_Am:ALEVel?
TRIGger:UNDER_Am:BLEVel
TRIGger:UNDER_Am:BLEVel?
TRIGger:UART:SOURce
TRIGger:UART:SOURce?
TRIGger:UART:CONdition
TRIGger:UART:CONdition?
TRIGger:UART:BAUd
TRIGger:UART:BAUd?
TRIGger:UART:ALEVel
TRIGger:UART:ALEVel?
TRIGger:UART:DATA
TRIGger:UART:DATA?
TRIGger:UART:WIDTh
TRIGger:UART:WIDTh?
TRIGger:UART:STOP
TRIGger:UART:STOP?
TRIGger:UART:PARIty
TRIGger:UART:PARIty?
TRIGger:UART:WHEN
TRIGger:UART:WHEN?
TRIGger:UART:IDLe
TRIGger:UART:IDLe?
TRIGger:CAN:SOURce
TRIGger:CAN:SOURce?
TRIGger:CAN:IDLe
TRIGger:CAN:IDLe?
TRIGger:CAN:BAUd
TRIGger:CAN:BAUd?
TRIGger:CAN:CONdition
TRIGger:CAN:CONdition?
TRIGger:CAN:ID
TRIGger:CAN:ID?
TRIGger:CAN:DLC
TRIGger:CAN:DLC?
TRIGger:CAN:DATA
TRIGger:CAN:DATA?
TRIGger:CAN:ALEVel
TRIGger:CAN:ALEVel?
TRIGger:CAN:VALId
TRIGger:CAN:VALId?
TRIGger:LIN:SOURce
TRIGger:LIN:SOURce?
TRIGger:LIN:IDLe
TRIGger:LIN:IDLe?
TRIGger:LIN:BAUd
TRIGger:LIN:BAUd?
TRIGger:LIN:CONdition
TRIGger:LIN:CONdition?
TRIGger:LIN:ID
TRIGger:LIN:ID?
TRIGger:LIN:DATA
TRIGger:LIN:DATA?
TRIGger:LIN:ALEVel
TRIGger:LIN:ALEVel?
TRIGger:LIN:VALId
TRIGger:LIN:VALId?
TRIGger:IIC:SDA:SOURce
TRIGger:IIC:SDA:SOURce?
TRIGger:IIC:SCL:SOURce
TRIGger:IIC:SCL:SOURce?
TRIGger:IIC:CONdition
TRIGger:IIC:CONdition?
TRIGger:IIC:ADDer
TRIGger:IIC:ADDer?
TRIGger:IIC:DATA
TRIGger:IIC:DATA?
TRIGger:IIC:ALEVel
TRIGger:IIC:ALEVel?
TRIGger:IIC:BLEVel
TRIGger:IIC:BLEVel?
TRIGger:IIC:VALId
TRIGger:IIC:VALId?
TRIGger:IIC:ACT:LEVEl
TRIGger:IIC:ACT:LEVEl?
TRIGger:SPI:SDA:SOURce
TRIGger:SPI:SDA:SOURce?
TRIGger:SPI:SCL:SOURce
TRIGger:SPI:SCL:SOURce?
TRIGger:SPI:IDLe
TRIGger:SPI:IDLe?
TRIGger:SPI:SCK
TRIGger:SPI:SCK?
TRIGger:SPI:WIDth
TRIGger:SPI:WIDth?
TRIGger:SPI:DATA
TRIGger:SPI:DATA?
TRIGger:SPI:MASK
TRIGger:SPI:MASK?
TRIGger:SPI:ALEVel
TRIGger:SPI:ALEVel?
TRIGger:SPI:BLEVel
TRIGger:SPI:BLEVel?
TRIGger:SPI:OVERtime
TRIGger:SPI:OVERtime?
TRIGger:SPI:ACT:LEVEl
TRIGger:SPI:ACT:LEVEl?
TRIGger:PATTern:PATTern
TRIGger:PATTern:PATTern?
TRIGger:PATTern:LEVel
TRIGger:PATTern:LEVel?
CALibrate:STARt
CALibrate:STATus?
CALibrate:QUIT
CALibrate:GET:TEMPerture?
CALibrate:GET:CONDition?
MATH:DISPlay
MATH:DISPlay?
MATH:OPERator
MATH:OPERator?
MATH:SOURce1
MATH:SOURce1?
MATH:SOURce2
MATH:SOURce2?
MATH:SCALe
MATH:SCALe?
MATH:OFFSet
MATH:OFFSet?
MATH:FFT:SOURce
MATH:FFT:SOURce?
MATH:FFT:WINDow
MATH:FFT:WINDow?
MATH:FFT:UNIT
MATH:FFT:UNIT?
MATH:FFT:HSCale
MATH:FFT:HSCale?
MATH:FFT:HCENter
MATH:FFT:HCENter?
REFerence1:DISPlay
REFerence1:DISPlay?
REFerence1:SOURce
REFerence1:SOURce?
REFerence1:VSCale
REFerence1:VSCale?
REFerence1:VOFFset
REFerence1:VOFFset?
REFerence1:CURRent
REFerence1:CURRent?
REFerence1:SAVe
REFerence2:DISPlay
REFerence2:DISPlay?
REFerence2:SOURce
REFerence2:SOURce?
REFerence2:VSCale
REFerence2:VSCale?
REFerence2:VOFFset
REFerence2:VOFFset?
REFerence2:CURRent
REFerence2:CURRent?
REFerence2:SAVe
WAVeform:SOURce
WAVeform:SOURce?
WAVeform:SOURce:SUBSource
WAVeform:SOURce:SUBSource?
WAVeform:BYTeorder
WAVeform:BYTeorder?
WAVeform:FORMat
WAVeform:FORMat?
WAVeform:POINts:MODE
WAVeform:POINts:MODE?
WAVeform:UNSigned
WAVeform:UNSigned?
WAVeform:PREamble?
WAVeform:COUNt?
WAVeform:POINts
WAVeform:POINts?
WAVeform:STARt
WAVeform:STARt?
WAVeform:STOP
WAVeform:STOP?
WAVeform:DATA
WAVeform:DATA:DISP?
PRIVate:WAVeform:DATA:ALL?
WAVeform:XINCrement?
WAVeform:XORigin?
WAVeform:XREFerence?
WAVeform:YINCrement?
WAVeform:YORigin?
WAVeform:YREFerence?
DISPlay:CLEar
DISPlay:DATA?
DISPlay:TYPE
DISPlay:TYPE?
DISPlay:GRADing:TIME
DISPlay:WBRightness
DISPlay:WBRightness?
DISPlay:GRID
DISPlay:GRID?
DISPlay:GBRightness
DISPlay:GBRightness?
CURSor:MODE
CURSor:MODE?
CURSor:MANual:TYPE
CURSor:MANual:TYPE?
CURSor:MANual:SOURce
CURSor:MANual:SOURce?
CURSor:MANual:AX
CURSor:MANual:AX?
CURSor:MANual:AXValue?
CURSor:MANual:AY
CURSor:MANual:AY?
CURSor:MANual:AYValue?
CURSor:MANual:BX
CURSor:MANual:BX?
CURSor:MANual:BXValue?
CURSor:MANual:BY
CURSor:MANual:BY?
CURSor:MANual:BYValue?
CURSor:MANual:XDELta?
CURSor:MANual:YDELta?
CURSor:MANual:IXDELta?
CURSor:TRACk:SOURcea
CURSor:TRACk:SOURcea?
CURSor:TRACk:SOURceb
CURSor:TRACk:SOURceb?
CURSor:TRACk:AX
CURSor:TRACk:AX?
CURSor:TRACk:AXValue?
CURSor:TRACk:AY?
CURSor:TRACk:AYValue?
CURSor:TRACk:BX
CURSor:TRACk:BX?
CURSor:TRACk:BXValue?
CURSor:TRACk:BY?
CURSor:TRACk:BYValue?
CURSor:TRACk:XDELta?
CURSor:TRACk:YDELta?
CURSor:TRACk:IXDELta?
MEASure:ENABle
MEASure:ENABle?
MEASure:SOURce
MEASure:SOURce?
MEASure:COUNter:VALue?
MEASure:CLEar
MEASure:RECover
MEASure:ADISplay
MEASure:ADISplay?
MEASure:AMSource
MEASure:AMSource?
MEASure:CHANnel1:ITEM
MEASure:CHANnel2:ITEM
MEASure:CHANnel3:ITEM
MEASure:CHANnel4:ITEM
MEASure:CHANnel1:ITEM?
MEASure:CHANnel2:ITEM?
MEASure:CHANnel3:ITEM?
MEASure:CHANnel4:ITEM?
MEASure:MATH:ITEM?
MEASure:GATE:ENABle
MEASure:GATE:ENABle?
MEASure:GATE:AY
MEASure:GATE:AY?
MEASUre:GATE:BY
MEASure:GATE:BY?
MEASure:COUNter
MEASure:CHANnel1:COUNter?
MEASure:CHANnel2:COUNter?
MEASure:CHANnel3:COUNter?
MEASure:CHANnel4:COUNter?
MEASure:CHANnel1:FREQ?
MEASure:CHANnel2:FREQ?
MEASure:CHANnel3:FREQ?
MEASure:CHANnel4:FREQ?
MEASure:DEL:ALL
MASK:EANBle
MASK:EANBle?
MASK:SOURce
MASK:SOURce?
MASK:OPERate
MASK:OPERate?
MASK:MDISplay
MASK:MDISplay?
MASK:SOOutput
MASK:SOOutput?
MASK:OUTPut
MASK:OUTPut?
MASK:X
MASK:X?
MASK:Y
MASK:Y?
MASK:CREate
MASK:PASSed?
MASK:FAILed?
MASK:TOTal?
SAVE:SETup
SAVE:MULTi
SAVE:CSV
SAVE:IMAGe
SAVE:MASK
RECall:SETup
RECall:MULTi
RECall:MASK
SYSTem:GAM?
SYSTem:RAM?
SYSTem:PON
SYSTem:PON?
SYSTem:LANGuage
SYSTem:LANGuage?
SYSTem:LOCKed
SYSTem:LOCKed?
DDS:SWITch
DDS:SWITch?
DDS:TYPE
DDS:TYPE?
DDS:FREQ
DDS:FREQ?
DDS:AMP
DDS:AMP?
DDS:OFFSet
DDS:OFFSet?
DDS:DUTY
DDS:DUTY?
DDS:WAVE:MODE
DDS:WAVE:MODE?
DDS:MODE:TYPE
DDS:MODE:TYPE?
DDS:MODE:WAVE:TYPE
DDS:MODE:WAVE:TYPE?
DDS:MODE:FREQ
DDS:MODE:FREQ?
DDS:MODE:DEPThordeviation
DDS:MODE:DEPThordeviation?
DDS:BURSt:SWITch
DDS:BURSt:SWITch?
DDS:BURSt:TYPE
DDS:BURSt:TYPE?
DDS:BURSt:CNT
DDS:BURSt:CNT?
DDS:BURSt:SRC
DDS:BURSt:SRC?
DDS:BURSt:SLOPE
DDS:BURSt:SLOPE?
DDS:BURSt:GATE:POLArity
DDS:BURSt:GATE:POLArity?
DDS:BURSt:TRIGger
DDS:SETUp:ALL?


You can send these commands using KeySight Interactive IO.
Also, you can open Keysight IO Monitor and see what DigitalScope or WaveEditor apps are doing.

PRIVate:FACTORY:RESET does what its name says. Resets the user settings and reboots. Serial, model remains unchanged.

Be careful of these commands!
- PRIVate:WRITE:EEPROM
- PRIVate:CLEAr:EE


PRIVate:READ:EEPROM returns:
Code: [Select]
<- 0????????????????????????«x01»«x01»
But in the IO Monitor:
Code: [Select]
30 ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff 01 01

I don't know how to restore these values since the cmd box only allows ascii characters!

The commands ended in '?' are queries. First, you send them, then click on "Read response".
The commands with arguments don't have response.
Don't execute a read response if you didn't send a query first, phoenix handles that pretty bad, it's easy to cause a buffer overflow, crashing the system.

You can easily change the values in seconds:
Code: [Select]
PRIVate:SET:MODEl1 DSO2D15
PRIVate:SET:SERIal CN2101029000000
PRIVate:SET:VENDor Hantek
PRIVate:SET:PCB "000.000.000.000.000.000.000.001"




« Last Edit: June 04, 2021, 05:39:14 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate
 

Online DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1509
  • Country: es
Re: Hacking the DSO2X1X
« Reply #101 on: June 04, 2021, 01:01:38 am »
People complained about the UART decoding only showing HEX data.
It was extremely easy to patch the phoenix binary to show ASCII:

Sync decode patch:







Monitor patch:



« Last Edit: June 04, 2021, 01:56:38 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate
 

Offline AndrewBCN

  • Frequent Contributor
  • **
  • Posts: 255
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #102 on: June 04, 2021, 01:18:34 am »
DavidAlfa,
If you have the time, could you please check what happens when you plug in the DSO to your PC using the USB cable on the back:
1. What is the kernel message you get (dmesg)?
2. What kernel module if any is loaded (lsmod)?
3. What USB devices are seen by the kernel (lsusb)?
4. Can you list the kernel modules available in /lib/modules?
5. Can you list the tty devices in /dev (ls /dev/tty*)?

What I am trying to determine is if it's possible to get a serial console on the USB OTG interface. This would make it possible to login to the DSO as root without opening it.  :-BROKE

See here for Allwinner SOCs: https://linux-sunxi.org/USB_Gadget/Serial

About writing to the display: it should be as simple as writing to memory, since I believe the display buffer is mapped to RAM, you have the specific region in the kernel message I believe.
« Last Edit: June 04, 2021, 01:40:08 am by AndrewBCN »
 

Online DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1509
  • Country: es
Re: Hacking the DSO2X1X
« Reply #103 on: June 04, 2021, 01:37:02 am »
Dmesg is very quiet. Little information is shown.
There are very few kernel modules. The system is really stripped down.
I already have some logs in my Drive folder, including dmesg and ls of the whole system (/bin, /dev, /proc, /sys, /lib... everything).
Did you check them?

Code: (lsmod) [Select]
# lsmod
Module                  Size  Used by    Tainted: G
tp_adc                 16384  0
usbtmc                 24576  0
fpga_i2c_kb            16384  0
spi_fpga_tn652         16384  0


Code: (lsusb) [Select]
# lsusb
Bus 001 Device 001: ID 1d6b:0002

Code: (modules) [Select]
# ls -R /lib/modules
/lib/modules:
3.10.65

/lib/modules/3.10.65:
kernel               modules.builtin.bin  modules.order
modules.alias        modules.dep          modules.softdep
modules.alias.bin    modules.dep.bin      modules.symbols
modules.builtin      modules.devname      modules.symbols.bin

/lib/modules/3.10.65/kernel:
drivers  net      sound

/lib/modules/3.10.65/kernel/drivers:
input    media    spi      staging  usb      video

/lib/modules/3.10.65/kernel/drivers/input:
touchscreen

/lib/modules/3.10.65/kernel/drivers/input/touchscreen:
icn85xx

/lib/modules/3.10.65/kernel/drivers/input/touchscreen/icn85xx:
icn85xx_ts.ko

/lib/modules/3.10.65/kernel/drivers/media:
platform   v4l2-core

/lib/modules/3.10.65/kernel/drivers/media/platform:
sunxi-vfe

/lib/modules/3.10.65/kernel/drivers/media/platform/sunxi-vfe:
actuator     device       vfe_io.ko    vfe_v4l2.ko

/lib/modules/3.10.65/kernel/drivers/media/platform/sunxi-vfe/actuator:
actuator.ko    ad5820_act.ko  dw9714_act.ko  ov8825_act.ko

/lib/modules/3.10.65/kernel/drivers/media/platform/sunxi-vfe/device:
ar0330.ko        gt2005.ko        ov5647_mipi.ko   s5k5e2yx.ko
gc0307.ko        hi253.ko         ov5648.ko        sp0718.ko
gc0308.ko        imx214.ko        ov5650.ko        sp0838.ko
gc0311.ko        nt99141.ko       ov7736.ko        sp0a19.ko
gc0328.ko        ov12830.ko       ov8825.ko        sp2518.ko
gc0328c.ko       ov13850.ko       ov8850.ko        sp2519.ko
gc0329.ko        ov16825.ko       ov8858.ko        sp5408.ko
gc2035.ko        ov2640.ko        ov8858_4lane.ko  sp5409.ko
gc2145.ko        ov2686.ko        s5k4e1.ko        t8et5.ko
gc2155.ko        ov2710_mipi.ko   s5k4e1_mipi.ko
gc5004.ko        ov5640.ko        s5k4ec.ko
gc5004_mipi.ko   ov5647.ko        s5k4ec_mipi.ko

/lib/modules/3.10.65/kernel/drivers/media/v4l2-core:
videobuf2-core.ko        videobuf2-dma-contig.ko  videobuf2-memops.ko

/lib/modules/3.10.65/kernel/drivers/spi:
spi-fpga-tn652.ko

/lib/modules/3.10.65/kernel/drivers/staging:
android

/lib/modules/3.10.65/kernel/drivers/staging/android:
ion

/lib/modules/3.10.65/kernel/drivers/staging/android/ion:
sunxi

/lib/modules/3.10.65/kernel/drivers/staging/android/ion/sunxi:
ion-kernel-use-demo.ko

/lib/modules/3.10.65/kernel/drivers/usb:
gadget

/lib/modules/3.10.65/kernel/drivers/usb/gadget:
g_android.ko     libcomposite.ko

/lib/modules/3.10.65/kernel/drivers/video:
backlight

/lib/modules/3.10.65/kernel/drivers/video/backlight:
backlight.ko   generic_bl.ko  lcd.ko

/lib/modules/3.10.65/kernel/net:
ipv4       netfilter

/lib/modules/3.10.65/kernel/net/ipv4:
netfilter

/lib/modules/3.10.65/kernel/net/ipv4/netfilter:
ipt_REJECT.ko      iptable_mangle.ko

/lib/modules/3.10.65/kernel/net/netfilter:
xt_LOG.ko        xt_comment.ko    xt_mac.ko        xt_multiport.ko
xt_TCPMSS.ko     xt_limit.ko      xt_mark.ko       xt_time.ko

/lib/modules/3.10.65/kernel/sound:
core

/lib/modules/3.10.65/kernel/sound/core:
oss  seq

/lib/modules/3.10.65/kernel/sound/core/oss:
snd-mixer-oss.ko  snd-pcm-oss.ko

/lib/modules/3.10.65/kernel/sound/core/seq:
oss                    snd-seq-dummy.ko       snd-seq.ko
snd-seq-device.ko      snd-seq-midi-event.ko

/lib/modules/3.10.65/kernel/sound/core/seq/oss:
snd-seq-oss.ko


Code: (tty) [Select]
# ls /dev/tty*
/dev/tty    /dev/tty2   /dev/tty31  /dev/tty43  /dev/tty55  /dev/ttyS0
/dev/tty0   /dev/tty20  /dev/tty32  /dev/tty44  /dev/tty56  /dev/ttyS1
/dev/tty1   /dev/tty21  /dev/tty33  /dev/tty45  /dev/tty57  /dev/ttyS2
/dev/tty10  /dev/tty22  /dev/tty34  /dev/tty46  /dev/tty58  /dev/ttyS3
/dev/tty11  /dev/tty23  /dev/tty35  /dev/tty47  /dev/tty59  /dev/ttyp0
/dev/tty12  /dev/tty24  /dev/tty36  /dev/tty48  /dev/tty6   /dev/ttyp1
/dev/tty13  /dev/tty25  /dev/tty37  /dev/tty49  /dev/tty60  /dev/ttyp2
/dev/tty14  /dev/tty26  /dev/tty38  /dev/tty5   /dev/tty61  /dev/ttyp3
/dev/tty15  /dev/tty27  /dev/tty39  /dev/tty50  /dev/tty62  /dev/ttyp4
/dev/tty16  /dev/tty28  /dev/tty4   /dev/tty51  /dev/tty63  /dev/ttyp5
/dev/tty17  /dev/tty29  /dev/tty40  /dev/tty52  /dev/tty7   /dev/ttyp6
/dev/tty18  /dev/tty3   /dev/tty41  /dev/tty53  /dev/tty8   /dev/ttyp7
/dev/tty19  /dev/tty30  /dev/tty42  /dev/tty54  /dev/tty9

When plugging the usb to the computer:
Code: [Select]
[   51.724893] configfs-gadget gadget: high-speed config #1: c
[   53.919748] tmc_function_setup:32, 7
[   53.923503] tmc_function_setup:32, 7
==========str_model = DSO2D15
str_vendor = Hantek
str_serial = CN2101029000000
str = Hantek, DSO2D15, CN2101029000000, 1.1.0(20210517.00)

The usb depends somehow on the phoenix app for the initial setup. It monitors the usb and changes the usb modes.
I guess it reads some GPIO or registers in the SOC that are set when something is connected to the usb port.
And enables Host or device mode by writing some register bits.

Once phoenix did whatever to make usb work, killing it won't make the usb to stop working.
But USB will stay in the last mode phoenix configured it, host or device mode.
So if it was in host mode, only a usb drive will work, but not connecting to the computer. And so on.
Edit: I found how to change the USB mode:
Code: [Select]
echo host > /sys/devices/platform/soc/1c13000.usb/musb-hdrc.1.auto/mode
echo peripheral > /sys/devices/platform/soc/1c13000.usb/musb-hdrc.1.auto/mode

To turn the usb power on/off
Code: [Select]
echo 1 >  /sys/class/gpio/gpio0/value
echo 0 >  /sys/class/gpio/gpio0/value

You can write directly to the LCD framebuffer using  /dev/fb0

The drawing seems to be done by libanolis(in /dso/lib), there are a lot of references to it inside phoenix:
Code: [Select]
    anolis_picture_fill(uVar2,local_b4)
    anolis_canvas_draw_string(uVar1,0x118,5,"UART DATA",0xffffffff);
    anolis_canvas_draw_line(uVar1,0,0x19,600,0x19);
« Last Edit: June 04, 2021, 02:36:37 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate
 
The following users thanked this post: AndrewBCN

Offline AndrewBCN

  • Frequent Contributor
  • **
  • Posts: 255
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #104 on: June 04, 2021, 01:41:02 am »
Dmesg is very quiet. Little information is shown.
There are very few kernel modules. I already have some logs in my Drive folder, did you check them?

I am going to check them, thanks!
 

Online DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1509
  • Country: es
Re: Hacking the DSO2X1X
« Reply #105 on: June 04, 2021, 03:15:03 am »
Reading the peripherals registers, I found that Uart0 hardware is actually linked to the GPIO pins.
So the patching is no longer needed, only find their connection in the board.

Here's the F1C200s pinout asignment:
Quote
PIN   GPIO         NAME    FUNCTION              CONNECTED TO

6      GPIO96      PD0      TWI0_SDA(I2C)      U9 5, LemonTree 118
7      GPIO97      PD1      LCD_D3                  LCD
8      GPIO98      PD2      LCD_D4                  LCD
9      GPIO99      PD3      LCD_D5                  LCD
10    GPIO100    PD4      LCD_D6                  LCD
11    GPIO101    PD5      LCD_D7                  LCD
12    GPIO102    PD6      LCD_D10                LCD
13    GPIO103    PD7      LCD_D11                LCD
14    GPIO104    PD8      LCD_D12                LCD
15    GPIO105    PD9      LCD_D13                LCD
16    GPIO106    PD10    LCD_D14                LCD
17    GPIO107    PD11    LCD_D15                LCD
18    GPIO108    PD12    TWI0_SCK(I2C)       U9 6, LemonTree 117
19    GPIO109    PD13    LCD_D19                LCD
21    GPIO110    PD14    LCD_D20                LCD
23    GPIO111    PD15    LCD_D21                LCD
24    GPIO112    PD16    LCD_D22                LCD
25    GPIO113    PD17    LCD_D23                LCD
26    GPIO114    PD18    LCD_CLK                LCD
27    GPIO115    PD19    LCD_DE                  LCD
28    GPIO116    PD20    LCD_HSYNC            LCD
29    GPIO117    PD21    LCD_VSYNC            LCD
37    GPIO140    PE12    PWM0                     LCD BACKLIGHT
38    GPIO139    PE11    Input                      R196, V USB detect from computer
39    GPIO138    PE10    SPI_MISO               LemonTree 87
40    GPIO137    PE9      SPI1_CLK               LemonTree 15
41    GPIO136    PE8      SPI1_MOSI             LemonTree 90
42    GPIO135    PE7      Output                   LemonTree 88
43    GPIO134    PE6      Input                      Buzzer signal from LemonTree 21, R19
44    GPIO133    PE5      Output                   LemonTree 20, R101
45    GPIO132    PE4      EINTE4                   LemonTree 22, R278
48    GPIO129    PE1      UART0_TX              UART0
49    GPIO128    PE0      UART0_RX              UART0
59    GPIO64      PC0      SPI0_CLK               SPI NAND FLASH U2
60    GPIO65      PC1      SPI0_CS                 SPI NAND FLASH U2
61    GPIO66      PC2      SPI0_MISO             SPI NAND FLASH U2
62    GPIO67      PC3      SPI0_MOSI             SPI NAND FLASH U2
63    GPIO3        PA3      UART1_TX              UART1
64    GPIO1        PA2      UART1_RX              UART1 
65    GPIO1        PA1      TP_X2                    ?_?
66    GPIO0        PA0      Output                   V OTG enable

After looking at the pinout, it definitely seems a Gowin product. Probably a customized version for Hantek.
But most pinout, if not all, is the same as the GW1N-4.




We got distracted thinking the unpopulated connector was a RJ45!

U1 seems to be a MAX232, as RX and TX go to pins 9 and 10.
I prefer to avoid soldering wires to 0603 pads, it's like asking for trouble, these pads will break easily.
So I had to put two 100ohm resistors to route the circuit to the connector pins.



On unmodified firmware, u-boot and linux shell are shown!
Code: [Select]
U-Boot SPL 2018.01 (May 25 2021 - 08:44:03)
DRAM: 64 MiB
Trying to boot from sunxi SPI


U-Boot 2018.01 (May 25 2021 - 08:44:03 +0800) Allwinner Technology

CPU:   Allwinner F Series (SUNIV)
Model: Lichee Pi Nano
DRAM:  64 MiB
show_dram_config:82ea5bc0, 82ea7ee8, 0, 82fc8000
SPI-NAND: W25N01GV is found size: 128MB.
*** Warning - bad CRC, using default environment

cfg_video_init:in:e59ff014
Setting up a 800x480 lcd console (overscan 0x0)
SPI-NAND: W25N01GV is found size: 128MB.
sunxi_lcdc_backlight_enable_user pwm 80
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
SPI-NAND: W25N01GV is found size: 128MB.
SPI-NAND: 3145728 bytes @ 0xf00000 Read: OK
SPI-NAND: 20480 bytes @ 0xd00000 Read: OK
## Booting kernel from Legacy Image at 80500000 ...
   Image Name:   Linux-5.2.0-licheepi-nano
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3071416 Bytes = 2.9 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 80c00000
   Booting using the fdt blob at 0x80c00000
   Loading Kernel Image ... OK
   Loading Device Tree to 816fa000, end 816ffee3 ... OK
add fb mem rsv ok, 83f44000, bc000

Starting kernel ...
« Last Edit: September 24, 2021, 08:23:23 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate
 
The following users thanked this post: AndrewBCN

Online DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1509
  • Country: es
Re: Hacking the DSO2X1X
« Reply #106 on: June 04, 2021, 08:19:05 pm »
I overcame the ocassional lockups.
The problem happens because the phoenix process crashes, but the system keeps running normally.
This do_other_update file (attached) will create a script that monitors phoenix, set it to start at boot time, and restart phoenix if it dies.
The result can be read in result.log in the usb drive.

Code: [Select]
#!/bin/sh
SCRIPT="/etc/init.d/S31local.sh"

echo "Adding phoenix monitor to the system" >/mnt/udisk/result.log

# Create phoenix_monitor
echo '#!/bin/sh' >/usr/bin/monitor_phoenix
echo 'LD_LIBRARY_PATH=/dso/lib/:$LD_LIBRARY_PATH' >>/usr/bin/monitor_phoenix
echo 'export LD_LIBRARY_PATH' >>/usr/bin/monitor_phoenix
echo 'while true; do' >>/usr/bin/monitor_phoenix
echo '        sleep 1' >>/usr/bin/monitor_phoenix
echo '        if [ "$(pidof phoenix)" = "" ]; then' >>/usr/bin/monitor_phoenix
echo '                echo "Phoenix killed! Restarting..."' >>/usr/bin/monitor_phoenix
echo '                /dso/app/app &' >>/usr/bin/monitor_phoenix
echo '        fi' >>/usr/bin/monitor_phoenix
echo 'done' >>/usr/bin/monitor_phoenix

# Set exec permissions
chmod +x /usr/bin/monitor_phoenix

# Ensure file exists and the line wasn't already added
if [ -f $SCRIPT ]; then
if [ "$(cat $SCRIPT | grep monitor_phoenix)" = "" ]; then
echo '/usr/bin/monitor_phoenix &' >> $SCRIPT
echo "Entry added to the boot script" >>/mnt/udisk/result.log
else
echo "Entry already exist, skipping" >>/mnt/udisk/result.log
fi
else
echo "$\"SCRIPT\" not found!" >>/mnt/udisk/result.log
echo "Your file might use a different filename" >>/mnt/udisk/result.log
echo >>/mnt/udisk/result.log
echo "init.d contents:" >>/mnt/udisk/result.log
ls /etc/init.d/S* >>/mnt/udisk/result.log
fi

Recovering takes only 4 seconds, much better than rebooting the whole system, until Hantek fixes the bugs.

The procedure is as simple as copying "do_other_update" and "3kb_do_other_update.upk"(In Gdrive folder) to the usb and run a system update.
« Last Edit: June 04, 2021, 08:22:31 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate
 
The following users thanked this post: Algoma, AndrewBCN

Offline AndrewBCN

  • Frequent Contributor
  • **
  • Posts: 255
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #107 on: June 05, 2021, 02:17:44 pm »
Bravo!  :clap:  :clap:  :clap:  :clap:

DavidAlfa,

Amazing work and way beyond hacking, at this stage you should offer your services to Hantek, to fix their broken firmware. You could teach more than a few lessons to their programmers. .  :-+  :-BROKE

BTW per your suggestion, I moved my post about the usbtmc.ko module from the main thread to this hacking thread.

The usbtmc.ko module is the driver for the USB test measurement and control protocol that is used by the DSO Hantek program to interface to a PC through the rear USB port. Loading it probably loads some other USB drivers in the USB stack that enable the front USB port, and the update command does the same.

The best way is to check what modules are loaded before and after insmodding the usbtmc.ko module and comparing. lsmod is the command to check which modules are loaded.

More information about the USB Test and Measurement Class protocol can be found here: https://github.com/dpenkler/linux-usbtmc
« Last Edit: June 05, 2021, 02:28:59 pm by AndrewBCN »
 

Online DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1509
  • Country: es
Re: Hacking the DSO2X1X
« Reply #108 on: June 05, 2021, 09:12:56 pm »
I'm struggling with something that migh be pretty stupid for linux users.

I have this script:
Code: (start_doom.sh) [Select]
while true; do
    sleep 1
      if [ -f /mnt/udisk/doom/fbdoom ] && [ -f /mnt/udisk/doom/doom1.wad ]; then
          pidof phoenix | xargs kill -9
          cat /dev/tty0
      fi
done
After this, I can see the output of the keypad.
If I try to read tty0 while phoenix is running, I get nothing, and tty0 stops working, I need to reboot after that.


The system drops messages to the kernel log like this:
Code: [Select]
[  464.270101] dso keyboard: key (code 0x15) pressed.,20
[  464.920075] dso keyboard: key (code 0x15) released.,20

So, in the script, I tried to check if the Start/Stop was pressed by reading the last line of dmesg.
But that also hangs tty0. Very very strange. I don't undertand why, since I only read dmesg!
Code: (start_doom.sh) [Select]
while true; do
    sleep 1
    if [ -f /mnt/udisk/doom/fbdoom ] && [ -f /mnt/udisk/doom/doom1.wad ]; then
        while [ -z "$(dmesg | tail -1 | grep -Eo '(0x15)')" ]; do
            sleep 1
        done
        pidof phoenix | xargs kill -9
        cat /dev/tty0
    fi
done


It's driving me crazy |O |O |O

Edit: I gave up. Made the Doom package, but there's no key to trigger it, it will run whenever the doom files are present.
« Last Edit: June 06, 2021, 01:36:51 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate
 

Offline JC221

  • Newbie
  • Posts: 1
  • Country: uy
Re: Hacking the DSO2X1X
« Reply #109 on: June 06, 2021, 02:26:56 am »
Hello everyone, I just registered and I want to ask a question, I have the DSO2D15 but I have not used it yet, what I want to know is if to read the SPI memory it is necessary to desolder it or can you connect it directly with wires to the programmer, the programmer that I have It is the RT809H.
Thanks
Regards
 

Online DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1509
  • Country: es
Re: Hacking the DSO2X1X
« Reply #110 on: June 06, 2021, 02:49:32 am »
Don't worry, there's no need to do so.
We have all hardware version firmare to flash the whole system.
And there're methods to restore you serial number.
It's unbrickable, you can always flash it.
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate
 
The following users thanked this post: AndrewBCN, JC221

Offline AndrewBCN

  • Frequent Contributor
  • **
  • Posts: 255
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #111 on: June 06, 2021, 11:00:54 am »
I'm struggling with something that migh be pretty stupid for linux users.
...

DavidAlfa,
As I wrote in the main thread, the problem is when the update process starts the shell with "sh -c <string>", it doesn't take the input from the keyboard but from the <string>  argument.
What you could do about this is at least in theory very simple: kill the shell process and restart it, then it will accept commands from the keyboard (tty0) again.
 

Offline AndrewBCN

  • Frequent Contributor
  • **
  • Posts: 255
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #112 on: June 06, 2021, 11:05:49 am »
Hello everyone, I just registered and I want to ask a question, I have the DSO2D15 but I have not used it yet, what I want to know is if to read the SPI memory it is necessary to desolder it or can you connect it directly with wires to the programmer,
...

Neither is required. Thanks to the amazing work of DavidAlfa, and as he explained, there is a switch underneath the scope that puts it into FEL mode. Check his repository for more information.
 
The following users thanked this post: JC221

Online DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1509
  • Country: es
Re: Hacking the DSO2X1X
« Reply #113 on: June 06, 2021, 12:50:50 pm »
Please read my post carefully. I'm running it from the console. The issue is not related to the "sh -c" thing.
Anyways, when your update script is called, it's executed inside that shell.
Guess what happens when you kill the opened sh? Yes, your script is killed too...

The only workaround I found was to add a file to /etc/init.d, so it gets called at boot start and runs the doom monitor script as a daemon.
It works nicely, except whenever I read dmesg while phoenix is running.

I found the culprit of everything!
Running this:
Code: [Select]
pidof phoenix | xargs kill -9
cat /dev/tty0

- Booting the system, not touching any key, works!
- Pressing any key before killing phoenix, hangs tty0  |O |O

I found some code that opens and debugs dev/input devices.
Indeed, it shows data when no key was pressed while running phoenix.
Otherwise, it shows nothing.

Checking inside libanolis, it seems to open /dev/input/event0.
Thus, I guess killing it leaves the device open/busy.

We're getting close!
« Last Edit: June 06, 2021, 02:25:23 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate
 

Online DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1509
  • Country: es
Re: Hacking the DSO2X1X
« Reply #114 on: June 06, 2021, 04:23:59 pm »
I cross-compiled ltrace to trace librarycalls and hopefully see the calls to libanolis.
But ltrace doesn't support arm for new kernels since long time ago!  |O
Any other way to spy library calls?

I sucessfully cross compiled strace. It works nicely.
Attach the binary for anyone wanting to hack around!
Easy as copying to the usb an running it.

I'm analyzing the endless output after tracing phoenix! Looooots of calls
If anyone wants to look (18MB for barely 10 second run!): https://drive.google.com/file/d/1VTvxoUMlnpno_Ax5hFIcQDQiDj4zq0JI/view?usp=sharing
I Saw:
Code: [Select]
181   00:01:03.494214 open("/dev/input/event0", O_RDWR) = 8
181   00:01:03.501070 ioctl(8, EVIOCGNAME(128), "afg3050_kbd\0") = 12
« Last Edit: June 06, 2021, 11:35:15 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2827
  • Country: fi
    • My home page and email address
Re: Hacking the DSO2X1X
« Reply #115 on: June 08, 2021, 11:51:15 pm »
I grabbed the strace, and looked at the things I'd look first: accesses to character devices and pseudofiles.  (Essentially variants of grep -ne /dev/ -e /proc/ -e /sys/ 'strace phoenix.txt', where the -n option enables line numbers, so I can refer to those easily.)

Running ldd binaryname would reveal the dynamic library dependencies directly.  It obviously uses FreeType for rendering text, but the libanolis.so.0 got me stumped.  I wonder if it is Hantek's internal GUI library or what.  Other than that, the lib references I see are typical compression and image format stuff, SQLite3 for file-based database stuff, C++ standard library 6.0.21, libsigc++, expat XML library, and so on.

Lines 187-190 show that the process opens the raw framebuffer, and memory-maps 768000 bytes of it, after getting the framebuffer information.  I'd wager it's a 16-bit truecolor (R5G5B5 or R5G6B5) 800×480 framebuffer; the numbers match.

Around line 1292, we can see the /dso/etc/load_fpga_kb.sh script is used to ensure the FPGA kernel module is loaded.  At lines 1369-1370, we see that the FPGA character device driver /dev/tn652_fpga_cfg is only used to tell it which firmware file to load, by writing the firmware file name (psram_board_test.fs.bin) and nothing else.

From line 1584 onwards, you can see that the process uses configfs (another pseudofilesystem like sysfs and procfs, dedicated for kernel stuff) to configure the USB gadget /sys/kernel/config/usb_gadget/g1, so that the system will appear as an USB device when connected to another host, using the standard Linux USB gadget driver.
Note that seems to use musb_hdrc, Inventra Highspeed Dual Role Controller, as used on e.g. Allwinner SOCs.

From line 1906 onwards, we can see how GPIO pins are configured and used.  Another set continues at line 2873.

At and after line 1998, we can see that the process opens /dev/input/event0, which happens to be an afg3050_kbd type Linux Input device.  As I understand it, AFG3050 is an FPGA, so the afg3050_kbd driver obviously implements an event device for the "keyboard" on the device.  Normally, events (16 bytes per struct input_event) are only read from the device (the uinput device being special one, allowing one to create input event devices in software), but there are a LOT of writes to this device... intriguing.

At and after line 2859, we can see that the /dev/spidev1.0 character device is used a lot. This is a Linux spidev device node, controlling a SPI bus; this part also mixes in some GPIO pin stuff.  Poor gpiochip0 pin gpio135 seems to be pulsed at 33Hz for a while.

To get any further, one would need to know what to look for.  For example, see what the process does when stuff is manipulated; or see how different bootups differ.
 
The following users thanked this post: AndrewBCN

Offline AndrewBCN

  • Frequent Contributor
  • **
  • Posts: 255
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #116 on: June 09, 2021, 08:04:01 am »
@NominalAnimal

Good work! Yes, libanolis is probably an internal Hantek GUI library, as you won't find any references to it except in other Hantek products.

Also the AFG3050 FPGA is used in other Hantek DSOs, my guess it's just an 8-bit MCU+FPGA to debounce/process the various LEDs, buttons and rotary controls on the front panel of their DSOs.
 

Offline Piton

  • Regular Contributor
  • *
  • Posts: 55
  • Country: ua
Re: Hacking the DSO2X1X
« Reply #117 on: June 09, 2021, 06:12:22 pm »
Hello. With the firmware of the platform versions 3000, 3101, everything works normally for me, and in version 3102 the rear USB connection icon does not disappear, and when the flash drive is connected, it is not detected until you start the update. My version is determined not by 3000, but by b000 (b101). I was flashing the original platform, there is version a015.
I also want to ask if someone connects PhoenixSuit_CN to the oscilloscope? I have no connection.
« Last Edit: June 09, 2021, 06:15:49 pm by Piton »
 

Online DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1509
  • Country: es
Re: Hacking the DSO2X1X
« Reply #118 on: June 09, 2021, 09:33:54 pm »
Yeah I spent some hours doing the same :-DD.
Remember that strace is done with -ff argument, so ALL child process are shown there too!
You forgot the lines where it calls check_sys_inf to retrieve the system config model, serial, pcb... ;)

libanolis uses /dev/fb0, which is a 800x480 16bit framebuffer, so yes, its size is exactly 750KB.

The system starts in /etc/init.d/S31local.sh, it calls /dso/app/boot.sh
boot.sh calls /dso/app/app (also a bash script).
app opens /dso/app/phoenix (executable)

Then phoenix / libanolis call these scripts among others:
[/dso/etc/]: load_fpga_kb.sh, insmod_usb_driver, S30dbus, usb_bord_mount.sh
« Last Edit: June 09, 2021, 10:07:47 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2827
  • Country: fi
    • My home page and email address
Re: Hacking the DSO2X1X
« Reply #119 on: June 10, 2021, 02:06:24 am »
If you run
    LANG=C LC_ALL=C objdump -T path-to-dynamic-library | awk '$2=="g" && $4==".text" { printf "%s (%s)\n", $7, $6 }' | sort | uniq
you get a list of dynamic symbols in the code section (the part in parentheses is the version each symbol).  Since this is just a list of symbols in alphabetic order, it is neither functional nor creative, and is therefore not protected by copyright.

Then, you can create an interposing library that is loaded by specifying the path to the interposing library in the LD_PRELOAD_LIB environment variable (multiple ones can be specified if separated by colons, :.)  If the binary uses setuid bits to stop this functionality, you can rename the actual library and use an wrapper library instead.  (On read-only mounts, you can do this via bind-mounts or overlays.)

Problem is, we cannot really write the interposing/wrapping (and tracking) functions themselves in C, because we don't know their prototypes.  All the functions know is the current registers, the address where it was called from, and obviously the address of the function it is to interpose/wrap.  It has to preserve all registers to do anything meaningful, so a hardware-specific inline assembly wrapper can be used via macros to define the interposers (via a call to a C function to log it, perhaps using a single logger C function); the interposed symbol addresses are looked up using <dlfcn.h> dlsym(RTLD_NEXT, "symname") call for each one in an ELF constructor function (which are run when the library is loaded, automatically, by the dynamic run-time linker) and stored in variables the interposer functions use to call. There is some overhead, but this is a purely userspace implementation.

So, tracing interesting function calls is quite doable even without ltrace, but without function prototypes, we cannot gather much information.  Although, I wonder if just updating ltrace's arm sysdeps would suffice it to get it working on current kernels; I wasn't even aware it had bit-rotted enough to not work on arm on current kernels.

I wonder how interesting objdump -d /dso/lib/libanolis.so.0.0.0 would be...
Almost as interesting as modinfo /dso/etc/*.ko would be, especially those that have a license: GPL line, I think.
 

Online DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1509
  • Country: es
Re: Hacking the DSO2X1X
« Reply #120 on: June 10, 2021, 03:38:01 am »
Oh, I forgot. Here I found an already compiled ltrace that worked.
Dumbest thing in my life. Searched "ltrace arm support", "ltrace armv5", "ltrace arm fix" and a thousand more.
But never something simple as "ltrace arm". Bang, first google result. Made me feel kinda stupid :-DD
Worked with it 2 days go, but is excruciatingly slow and crashes often, in the end I got tired and left it for other moment...
« Last Edit: June 10, 2021, 03:41:18 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate
 

Offline Josepsp

  • Contributor
  • Posts: 14
  • Country: es
Re: Hacking the DSO2X1X
« Reply #121 on: June 10, 2021, 08:43:28 am »
Dang it's hard to post pictures here...

I promised an update when I upgraded my DSO2C15 to a DSO2D15 by installing 3 missing components on the motherboard.
It was a hairy install as I have soldering skills but not of surface mount and the DAC is horrendously small pitch.
However, it works...

The missing parts were easy to find:

DAC : DAC902E           (Arrow)
OpAmp : LMH6702      (Arrow)
Relay : FD4/4.5-S |428||282| XA0920A  (EBay)

Total incl. shipping was under $27


Thank you very much for the references list and pictures. Brilliant!

I purchased all the parts in Aliexpress and yesterday they arrived and I did the population of my DSO2C10 board. Everything works and I have a functional enough DSO2D15.

I guess going for the cheapest components have compromised a bit the quality. The signal is quite noisy compared with the calibration signal, but enabling the BW 20MHz fixes the issue completely.


edit: d'oh! I missed the quote
« Last Edit: June 10, 2021, 09:23:16 am by Josepsp »
 

Offline jemarro12

  • Newbie
  • Posts: 3
  • Country: es
Re: Hacking the DSO2X1X
« Reply #122 on: June 10, 2021, 05:32:06 pm »
@Josepsp did u find all components in ali?
Can u share link maybe in pm. I don't want to pay Digi or arrow 20 for the shipment... Thanks!!!
 

Offline Josepsp

  • Contributor
  • Posts: 14
  • Country: es
Re: Hacking the DSO2X1X
« Reply #123 on: June 10, 2021, 08:41:17 pm »
@Josepsp did u find all components in ali?
Can u share link maybe in pm. I don't want to pay Digi or arrow 20 for the shipment... Thanks!!!
Sure, I'm sending you a PM with the links, although they should be easy to find just by searching the references that @Boyeen shared.

If anyone is in the same boat the tricky one was the relay  FD4/4.5-S , which appeared only with the search term "relay HDF4".

BTW, checking the datasheet the S refers to "smd", but there's also a DIP variant with the same exact dimensions without the S in the code, which I was about to search too, as it looked suitable just bending and clipping the legs. I finally found the proper one so no need. The units with an L in the code are latching ones and I assume those will malfunction.
 

Offline tttonyyy

  • Regular Contributor
  • *
  • Posts: 54
  • Country: gb
Re: Hacking the DSO2X1X
« Reply #124 on: June 10, 2021, 09:49:51 pm »
When I was reading about FEL mode for the Allwinner, there is a section on a page that suggests that you can u-boot over USB to either boot into the internal software, or boot the entire system over USB by loading your own initramfs:

https://linux-sunxi.org/FEL/USBBoot#Boot_the_system_over_USB

If this was used to start miniroot (the linked busybox initramfs) it might be possible to then mount other internal bits of flash filesystem for inspection.
Or potentially decompose the firmware upgrade into the parts needed to entirely boot externally from USB.

It looks like there is a lot that could be played with :)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf