Hacking the DSO2X1X

[DavidAlfa]

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]

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]

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:

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

@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]

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]

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]

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]

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]

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]

@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]

@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]

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]

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]

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]

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.