Author Topic: Hacking the DSO2X1X (Read 140195 times)

DavidAlfa · « **Reply #100 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);

AndrewBCN · « **Reply #101 on:** June 04, 2021, 01:41:02 am »

Quote from: DavidAlfa on June 04, 2021, 01:37: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!

DavidAlfa · « **Reply #102 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~~. Edit: It seems to be a GW2AR-18

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 ...

DavidAlfa · « **Reply #103 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.

AndrewBCN · « **Reply #104 on:** June 05, 2021, 02:17:44 pm »

Bravo!

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. .

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

DavidAlfa · « **Reply #105 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

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.

JC221 · « **Reply #106 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

DavidAlfa · « **Reply #107 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.

AndrewBCN · « **Reply #108 on:** June 06, 2021, 11:00:54 am »

Quote from: DavidAlfa on June 05, 2021, 09:12:56 pm

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.

AndrewBCN · « **Reply #109 on:** June 06, 2021, 11:05:49 am »

Quote from: JC221 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,
...

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.

DavidAlfa · « **Reply #110 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

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!

DavidAlfa · « **Reply #111 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!

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

Nominal Animal · « **Reply #112 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.

AndrewBCN · « **Reply #113 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.

Piton · « **Reply #114 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.

DavidAlfa · « **Reply #115 on:** June 09, 2021, 09:33:54 pm »

Yeah I spent some hours doing the same

.
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

Nominal Animal · « **Reply #116 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.

DavidAlfa · « **Reply #117 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

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...

Josepsp · « **Reply #118 on:** June 10, 2021, 08:43:28 am »

Quote from: Boyeen on April 16, 2021, 02:55:20 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

jemarro12 · « **Reply #119 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!!!

Josepsp · « **Reply #120 on:** June 10, 2021, 08:41:17 pm »

Quote from: jemarro12 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!!!

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.

tttonyyy · « **Reply #121 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

DavidAlfa · « **Reply #122 on:** June 10, 2021, 10:37:08 pm »

Yes, you can boot anything you want, of course compiled first (another fun party).
But meh, not having FPU cripples the performance by a factor of 20 or more... it's a bad base from the start.
I don't feel it worths the time anymore.

AndrewBCN · « **Reply #123 on:** June 13, 2021, 12:09:32 pm »

As I posted in the main DSO2X1X thread, there is a software tool that allows access to the Allwinner F1C200s SOC in FEL mode through the USB connector on the back of the scope: sunxi-fel, which is part of sunxi-tools.

I am using Ubuntu 20.10 on my laptop, and it has available a packaged version of sunxi-tools (unfortunately not the latest version, but that can be compiled easily).

Just a quick test with booting the DSO in FEL mode and connecting it to my Linux laptop:

andrew@andrew-ThinkPad-T420:~$ sunxi-fel version
ERROR: You don't have permission to access Allwinner USB FEL device
andrew@andrew-ThinkPad-T420:~$ sudo sunxi-fel version
Warning: no 'soc_sram_info' data for your SoC (id=1663)
AWUSBFEX soc=00001663(unknown) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000

Two things:
1. You must run sunxi-tools as root or give permission to user.
2. The packaged sunxi-tools in Ubuntu 20.10 works but does not identify the F1C200s, but the latest version of sunxi-fel does.

Note that this FEL mode is before u-boot has started, so the actions available are very limited, but for example one should be able to tell the SOC to load the u-boot SPL binary from a file and run it, then starts u-boot proper (see the uboot <file-with-SPL> command below). (SPL = Secondary Program Loader which load the main u-boot binary into RAM)

So at this point I should be able to run any sunxi-fel command:

Usage: ./sunxi-fel [options] command arguments... [command...]
-v, --verbose Verbose logging
-p, --progress "write" transfers show a progress bar
-l, --list Enumerate all (USB) FEL devices and exit
-d, --dev bus:devnum Use specific USB bus and device number
--sid SID Select device by SID key (exact match)

spl file Load and execute U-Boot SPL
If file additionally contains a main U-Boot binary
(u-boot-sunxi-with-spl.bin), this command also transfers that
to memory (default address from image), but won't execute it.

uboot file-with-spl like "spl", but actually starts U-Boot
U-Boot execution will take place when the fel utility exits.
This allows combining "uboot" with further "write" commands
(to transfer other files needed for the boot).

hex[dump] address length Dumps memory region in hex
dump address length Binary memory dump
exe[cute] address Call function address
reset64 address RMR request for AArch64 warm boot
readl address Read 32-bit value from device memory
writel address value Write 32-bit value to device memory
read address length file Write memory contents into file
write address file Store file contents into memory
write-with-progress addr file "write" with progress bar
write-with-gauge addr file Output progress for "dialog --gauge"
write-with-xgauge addr file Extended gauge output (updates prompt)
multi[write] # addr file ... "write-with-progress" multiple files,
sharing a common progress status
multi[write]-with-gauge ... like their "write-with-*" counterpart,
multi[write]-with-xgauge ... but following the 'multi' syntax:
<#> addr file [addr file [...]]
echo-gauge "some text" Update prompt/caption for gauge output
ver[sion] Show BROM version
sid Retrieve and output 128-bit SID key
clear address length Clear memory
fill address length value Fill memory

Note that when you boot in FEL mode the DSO buttons light up but the screen stays black (no backlight). This is as expected since the buttons LEDs are controlled by an FPGA but the screen and its backlight are controlled by the SOC.

AndrewBCN · « **Reply #124 on:** June 13, 2021, 03:35:44 pm »

I have just built the version of sunxi-tools patched by Icenowy for the F1C100s (identical to the F1C200s, except different DRAM size). Now sunxi-fel correctly identifies the SOC:

$ sudo /usr/local/bin/sunxi-fel version
AWUSBFEX soc=00001663(F1C100s) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000

As DavidAlfa found out recently, the latest version of sunxi-fel can be used to read the SPI flash to a file, but the version of sunxi-tools patched by Icenowy doesn't.
So I tried the sunxi-fel which I compiled from source:

$ sudo sunxi-fel spiflash-info
Warning: no 'soc_sram_info' data for your SoC (id=1663)
SPI support not implemented yet for 0 ((null))!

But then I remembered that George Hilliard had merged Icenowy patches with the master sunxi-tools, his version of sunxi-tools can be found here: https://github.com/thirtythreeforty/sunxi-tools

Which I compiled (it takes 30 seconds) and tested: success!

$ sudo /usr/local/bin/sunxi-fel spiflash-info
Manufacturer: Unknown (00h), model: EFh, size: 1024 bytes.

$ sudo /usr/local/bin/sunxi-fel spiflash-read 0 1024 flash.bin

The resulting flash.bin renamed to flash.txt is attached below and yes, it does seem to be u-boot and Linux kernel related code.

So in principle it should be possible to examine/read/write/backup the SPI flash (in other words, the DSO firmware) using sunxi-fel amd the USB OTG port on the back of the DSO. I still have to check how to make the Winbond SPI chip get properly recognized by sunxi-fel.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Hacking the DSO2X1X (Read 140195 times)

Share me