Author Topic: Possible GW Instek GDS-1000B hack  (Read 74461 times)

0 Members and 2 Guests are viewing this topic.

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Possible GW Instek GDS-1000B hack
« Reply #200 on: January 11, 2021, 04:14:14 pm »
A guess: You might need to format the NAND with the UBI-fs first (which is a wear levelling layer) and then create the mtd partitions.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline danymogh

  • Regular Contributor
  • *
  • Posts: 51
  • Country: ge
Re: Possible GW Instek GDS-1000B hack
« Reply #201 on: January 11, 2021, 07:35:57 pm »
A guess: You might need to format the NAND with the UBI-fs first (which is a wear levelling layer) and then create the mtd partitions.

thanks a lot for your reply!

Unfortunately, UBI-fs is only used for Linux. MTD partitions are defined from the bootloader and then passed to Linux.

I found out that I was mistaken and the BBT information is actually in the dump and in the last 4 blocks. I still think this is a software issue but have no clue how it has come to this.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Possible GW Instek GDS-1000B hack
« Reply #202 on: January 11, 2021, 08:11:03 pm »
A guess: You might need to format the NAND with the UBI-fs first (which is a wear levelling layer) and then create the mtd partitions.

thanks a lot for your reply!

Unfortunately, UBI-fs is only used for Linux. MTD partitions are defined from the bootloader and then passed to Linux.
On the system I have worked on both bootloader and the Linux kernel use UBI fs. The bootloader has to in order to read the kernel from the filesystem and boot it. In general it makes no sense to use NAND flash directly unless you have (more expensive and rare) NAND flash with a 'known good' boot area. Having a wear levelling / error correcting layer in between makes a lot more sense. IOW: it would surprise me if the bootloader uses raw NAND flash.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline danymogh

  • Regular Contributor
  • *
  • Posts: 51
  • Country: ge
Re: Possible GW Instek GDS-1000B hack
« Reply #203 on: January 12, 2021, 06:37:56 am »
A guess: You might need to format the NAND with the UBI-fs first (which is a wear levelling layer) and then create the mtd partitions.

thanks a lot for your reply!

Unfortunately, UBI-fs is only used for Linux. MTD partitions are defined from the bootloader and then passed to Linux.
On the system I have worked on both bootloader and the Linux kernel use UBI fs. The bootloader has to in order to read the kernel from the filesystem and boot it. In general it makes no sense to use NAND flash directly unless you have (more expensive and rare) NAND flash with a 'known good' boot area. Having a wear levelling / error correcting layer in between makes a lot more sense. IOW: it would surprise me if the bootloader uses raw NAND flash.

based on the boot.bin file from the upgrade files and a dump from another scope I'd say the bootloader used raw Nand flash. also in the Zynq 7000 docs, there's no indication of UBI-fs for the bootloader. however, it seems the Zynq first enables the internal ECC and then starts to read the flash. this might be why the boot is failing. I've programmed the bootloader with the ECC disabled which means the OOB area is not the same as in a working scope. that is the last thing that I've found and I'm going to try it and see If it works.

Edit: unfortunately the programmer I have doesn't support enabling the ECC feature. If one of the forum members would be kind to send me the dump of their bootloader including the OOB data i'd be delighted.
the command is : nanddump -f booloader.bin -o /dev/mtd0
any bootloader version would do
« Last Edit: January 12, 2021, 07:32:44 am by danymogh »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16677
  • Country: 00
Re: Possible GW Instek GDS-1000B hack
« Reply #204 on: January 12, 2021, 09:13:10 am »
based on the boot.bin file from the upgrade files and a dump from another scope I'd say the bootloader used raw Nand flash.

You don't really need wear-levelling for firmware and it's a whole layer of extra complexity for a low-level bootloader.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Possible GW Instek GDS-1000B hack
« Reply #205 on: January 12, 2021, 09:16:19 am »
based on the boot.bin file from the upgrade files and a dump from another scope I'd say the bootloader used raw Nand flash.

You don't really need wear-levelling for firmware and it's a whole layer of extra complexity for a low-level bootloader.
You do because nand flash is that bad. Wear levelling is also about checking the contents and in case a sector is very bad it needs to be mapped out. See the problems Keysight has with their oscilloscopes. And nowadays bootloaders are very advanced pieces of software. Not just a few lines of code but close to being an OS in themselves.
« Last Edit: January 12, 2021, 09:22:56 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3221
  • Country: pt
Re: Possible GW Instek GDS-1000B hack
« Reply #206 on: January 12, 2021, 09:54:11 am »
You said you had a NAND dump?

If so, share it with us to have a look.
 

Offline danymogh

  • Regular Contributor
  • *
  • Posts: 51
  • Country: ge
Re: Possible GW Instek GDS-1000B hack
« Reply #207 on: January 12, 2021, 11:42:50 am »
You said you had a NAND dump?

If so, share it with us to have a look.

Yes, I have a full dump including the OOB data but after the firmware is corrupted. so the bootloader section OOB is useless.
Also, the other dumps I got from the other working scope don't include OOB data and unfortunately, I bricked that scope as well  |O because I had no Idea the "nandtest" command messes up the block content.

here is the full dump including OOB after bootloader being messed up
https://mega.nz/file/EwhBHK5Z#iWaQYef7AYeb_-1wFezzOjsCgKbDqYcK72qOQfp7sz4

as you can see on page 65472 and 65408  there is the BBT according to Zynq documents (in the last 4 blocks)
also, I have a boot log that points to them as well

Code: [Select]
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01

according to Micron ECC the OOB area is 64 bytes and the table explains each part. however, that table (should?) be valid only when the internal ECC is used. It seems the Zynq uses address 0x804 - 0x807 to store the BBT signature (spare 0) and address 0x808 - 0x80F are the calculated ECC parity bits based on the content of main0 and spare 0 the subsequent addresses are similar.

to sum it up, the last 8 bytes in each row are the parity bits, the first 8 bytes of each row are the Bad block information (2 bytes) + 6 byte user data (from that 6 bytes 2 bytes are not ECC protected (User metadata II) and 4 bytes are ECC protected (user metadata I))
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Possible GW Instek GDS-1000B hack
« Reply #208 on: January 12, 2021, 12:56:15 pm »
Perhaps a better way is to let the bootloader boot a Linux image (from Xilinx) over the network and use that to create the MTD partitions which are missing and then populate them with data from an extracted firmware image.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline danymogh

  • Regular Contributor
  • *
  • Posts: 51
  • Country: ge
Re: Possible GW Instek GDS-1000B hack
« Reply #209 on: January 12, 2021, 01:59:25 pm »
Perhaps a better way is to let the bootloader boot a Linux image (from Xilinx) over the network and use that to create the MTD partitions which are missing and then populate them with data from an extracted firmware image.

unfortunately, that's not possible since it is the bootloader that loads the device tree which has the definition of all connected peripherals.

if only one of the people who has the GDS-1054b could provide a dump from their bootloader using the command I specified, that's a great help to me.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Possible GW Instek GDS-1000B hack
« Reply #210 on: January 12, 2021, 02:32:47 pm »
What if you use the Xilinx devicetree as well? Basically set the oscilloscope up as if it is a Xilinx Zync development board and go from there. Likely a lot of the peripherals will be taken from a development board design so ethernet might just work.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: tv84

Offline danymogh

  • Regular Contributor
  • *
  • Posts: 51
  • Country: ge
Re: Possible GW Instek GDS-1000B hack
« Reply #211 on: January 12, 2021, 03:41:34 pm »
What if you use the Xilinx devicetree as well? Basically set the oscilloscope up as if it is a Xilinx Zync development board and go from there. Likely a lot of the peripherals will be taken from a development board design so ethernet might just work.

that might work but I need a Xilinx Jtag and also I need to know the pinout on the board which I don't. also, I don't have the files of the device tree o just saw them in the bootloader dump. I've started working on the programmer to implement the enable ECC part.
 

Offline 450bush

  • Newbie
  • Posts: 6
  • Country: us
Re: Possible GW Instek GDS-1000B hack
« Reply #212 on: January 12, 2021, 04:08:34 pm »
What if you use the Xilinx devicetree as well? Basically set the oscilloscope up as if it is a Xilinx Zync development board and go from there. Likely a lot of the peripherals will be taken from a development board design so ethernet might just work.

that might work but I need a Xilinx Jtag and also I need to know the pinout on the board which I don't. also, I don't have the files of the device tree o just saw them in the bootloader dump. I've started working on the programmer to implement the enable ECC part.

You may try the Pluto SDR github repository for some help... https://github.com/analogdevicesinc/plutosdr-fw . The firmware can be found at the link and it is basec on a Zync processor. The u-boot code/configuration is posted there!

good luck...
 

Offline danymogh

  • Regular Contributor
  • *
  • Posts: 51
  • Country: ge
Re: Possible GW Instek GDS-1000B hack
« Reply #213 on: January 15, 2021, 01:48:59 pm »
I finally got it working !!

here is the correct image for version 1.28 from offset 0x000000000000 to 0x0000033c0000.
which includes the following :

0x000000000000-0x0000001c0000 : "boot"
0x0000001c0000-0x0000001e0000 : "devtree"
0x0000001e0000-0x000000200000 : "env"
0x000000200000-0x000000280000 : "fpga-core"
0x000000280000-0x000000580000 : "kernel"
0x000000580000-0x0000033c0000 : "rootfs"

it should be programmed to the Nand which has no bad blocks in that address range. be careful not to erase the rest of the address space since valuable user data like calibration data and serial number, etc are in there! basically, always have a backup of the /home/dso directory.
also, the last 4 blocks (2 of them) contain the Zynq BBT information in their OOB area which is important for the boot to happen successfully.
« Last Edit: January 21, 2021, 04:53:27 pm by danymogh »
 
The following users thanked this post: edavid, Mortymore

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Possible GW Instek GDS-1000B hack
« Reply #214 on: January 15, 2021, 03:52:50 pm »
Great news! I hope you can make some progress with the Lua scripting.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3221
  • Country: pt
Re: Possible GW Instek GDS-1000B hack
« Reply #215 on: January 15, 2021, 04:45:17 pm »
0x00000000-0x001c0000 : "boot"
0x001c0000-0x001e0000 : "devtree"
0x001e0000-0x00200000 : "env"
0x00200000-0x00280000 : "fpga-core"
0x00280000-0x00580000 : "kernel"
0x00580000-0x033c0000 : "rootfs"
0x033c0000-0x07000000 : "user"

Parsings:

0x000000000000-0x0000001c0000 : "boot"

Code: [Select]
**********  Zynq-7000 SoC Boot Header  **********
00000000 -            ARM Vector Table: 8 x EAFFFFFE
00000020 -             Width Detection: AA995566
00000024 -            Header Signature: XLNX
00000028 -                  Key Source: 00000000  -  Not Encrypted
0000002C -                     Version: 01010000  (0x01010000)
00000030 -           FSBL Image Offset: 00000D40
00000034 -           FSBL Image Length: 00014014
00000038 -     FSBL Load Address (RAM): 00000000
0000003C -     FSBL Exec Address (RAM): 00000000
00000040 -           Total FSBL Length: 00014014
00000044 -          QSPI Configuration: 00000001  (0x00000001)
00000048 -        Boot Header Checksum: FC16CED8  CHKSUM OK
0000004C -                User Defined: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
00000098 -   Image Header Table Offset: 000008C0
0000009C - Partit. Header Table Offset: 00000C80
**********  Zynq-7000 SoC Device Register Initialization Table  **********
000000A0 - Register Initialization Pairs  [000000A0-0000089F]
**********  Zynq-7000 SoC Device Image Header Table  **********
000008C0 -                     Version: 01020000  (0x01020000)
000008C4 -             # Image Headers: 00000002
000008C8 - 1st Partition Header Offset: 00000C80
000008CC -     1st Image Header Offset: 00000900
000008D0 -   Header Auth Certif Offset: 00000000
000008D4 -                    Reserved: FFFFFFFF
**********  Zynq-7000 SoC Device Image Headers  **********
           Partitio Reserved  Length  Name
00000900 - 00000C80 00000000 00000001 fsbl_nand.elf
00000940 - 00000CC0 00000000 00000001 u-boot.Ap3RNQMM.elf
**********  Zynq-7000 SoC Device Partition Headers  **********
           EncryLen UnencLen TotalLen DestLoad DestExec ImgOffst AttrBits Sections Checksm  ImHdOffs AuthOffs HdChkSum
00000C80 - 00014014 00014014 00014014 00000000 00000000 00000D40 00000010 00000000 00000000 00000900 00000000 FFFF0A50   CHKSUM OK
00000CC0 - 000F321C 000F321C 000F321C 04000000 04000000 00014D80 00000010 00000001 00000000 00000940 00000000 F7F444A9   CHKSUM OK

Your devtree is empty...

0x000000200000-0x000000280000 : "fpga-core"

00200000-0026C4DC  fpga-core.gz    CRC32: 61485AD2  DecompSize: 001FCB9C

IDCODE = 03722093      => Zynq XC7Z010
Code: [Select]
00000030 - AA995566             Sync Word (BPI/SPI Mode)
00000034 - 20000000             T1 - 00000000  NOP      (1x)
00000038 - 30022001 00000000    T1 W 00000001  TIMER
00000040 - 30020001 00000000    T1 W 00000001  WBSTAR
00000048 - 30008001 00000000    T1 W 00000001  CMD      NULL - No Operation
00000050 - 20000000             T1 - 00000000  NOP      (1x)
00000054 - 30008001 00000007    T1 W 00000001  CMD      RCRC - Reset CRC
0000005C - 20000000             T1 - 00000000  NOP      (2x)
00000064 - 30026001 00000000    T1 W 00000001  FALL_EDGE
0000006C - 30012001 02003FE5    T1 W 00000001  COR0
00000074 - 3001C001 00000000    T1 W 00000001  COR1
0000007C - 30018001 03722093    T1 W 00000001  IDCODE
00000084 - 30008001 00000009    T1 W 00000001  CMD      SWITCH - Switch CCLK Frequency
0000008C - 20000000             T1 - 00000000  NOP      (1x)
00000090 - 3000C001 00000401    T1 W 00000001  MASK
00000098 - 3000A001 00000401    T1 W 00000001  CTL0
000000A0 - 3000C001 00000000    T1 W 00000001  MASK
000000A8 - 30030001 00000000    T1 W 00000001  CTL1
000000B0 - 20000000             T1 - 00000000  NOP      (8x)
000000D0 - 30002001 00000000    T1 W 00000001  FAR
000000D8 - 30008001 00000001    T1 W 00000001  CMD      WCFG - Write Config Data
000000E0 - 20000000             T1 - 00000000  NOP      (1x)
000000E4 - 30004000             T1 W 00000000  FDRI
000000E8 - 5007F0A0             T2 W 0007F0A0
001FC374 - 20000000             T1 - 00000000  NOP      (2x)
001FC37C - 30008001 0000000A    T1 W 00000001  CMD      GRESTORE - Pulse GRESTORE Signal
001FC384 - 20000000             T1 - 00000000  NOP      (1x)
001FC388 - 30008001 00000003    T1 W 00000001  CMD      DGHIGH/LFRM - Last Frame
001FC390 - 20000000             T1 - 00000000  NOP      (100x)
001FC520 - 30008001 00000005    T1 W 00000001  CMD      START - Begin Startup Sequence
001FC528 - 20000000             T1 - 00000000  NOP      (1x)
001FC52C - 30002001 03BE0000    T1 W 00000001  FAR
001FC534 - 3000C001 00000501    T1 W 00000001  MASK
001FC53C - 3000A001 00000401    T1 W 00000001  CTL0
001FC544 - 30000001 15E91D43    T1 W 00000001  CRC
001FC54C - 20000000             T1 - 00000000  NOP      (2x)
001FC554 - 30008001 0000000D    T1 W 00000001  CMD      DESYNC - Reset DALIGN Signal
001FC55C - 20000000             T1 - 00000000  NOP
001FCB98 - 00000000           ... give time for internal startup

0x000000280000-0x000000580000 : "kernel"

Code: [Select]
00280000                 Magic: 27051956    uImage File OK
00280004         Header CRC-32: 13203039  [00280000-0028003F]    CRC OK
00280008               Created: 07/01/2020 04:02:12
0028000C             Data Size: 002F8A58
00280010     Data Load Address: 00008000
00280014   Entry Point Address: 00008000
00280018           Data CRC-32: 3044F5BF  [00280040-00578A97]    CRC OK
0028001C      Operating System: Linux
0028001D      CPU Architecture: ARM
0028001E                  Type: OS Kernel Image
0028001F           Compression: None
00280020                  Name: Linux-3.12.0-xilinx
00280040 - Image 0 [00280040-00578A97]  002F8A58 bytes


So as I see it, before you ruined MTD0 and MTD1. Now you have corrected only MTD0 (boot.bin) and it seems the scope is working without the devtree flashed. Interesting...  ::)
« Last Edit: January 15, 2021, 08:58:40 pm by tv84 »
 

Offline danymogh

  • Regular Contributor
  • *
  • Posts: 51
  • Country: ge
Re: Possible GW Instek GDS-1000B hack
« Reply #216 on: January 15, 2021, 07:25:39 pm »
So as I see it, before you ruined MTD0 and MTD1. Now you have corrected only MTD0 (boot.bin) and it seems the scope is working without the devtree flashed. Interesting...  ::)

yes, that is what I thought but I checked "devtree" with the dump I got from another working scope with the same model, and as it turns out it actually is empty! I think they didn't name the partitions correctly perhaps? the devtree seems to be loaded either from bootloader or "env" partition.

btw, what tools did you use to make the parsings? for the boot.bin I had to write my own tool for analysis here:

https://github.com/danyhm/Xilinx-BIF-Tool

but yours seems like a lot better!
« Last Edit: January 15, 2021, 07:40:16 pm by danymogh »
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3221
  • Country: pt
Re: Possible GW Instek GDS-1000B hack
« Reply #217 on: January 15, 2021, 08:41:36 pm »
yes, that is what I thought but I checked "devtree" with the dump I got from another working scope with the same model, and as it turns out it actually is empty! I think they didn't name the partitions correctly perhaps? the devtree seems to be loaded either from bootloader or "env" partition.

btw, what tools did you use to make the parsings? for the boot.bin I had to write my own tool for analysis here:

https://github.com/danyhm/Xilinx-BIF-Tool

but yours seems like a lot better!

I've verified all the FW files I have and none has the .DTB.   |O   But the env refers to them. I think it should exist.

I have my own parsers. My Zynq boot parser already does the CRC validations.  ;)

That was one of the reasons why I passed all your FW through the parser: to check that all CRCs were correct and everything in order.

Then I noticed that you really messed up your MTD0 and 1 (all the rest was/is good). How did you do that?
 

Offline danymogh

  • Regular Contributor
  • *
  • Posts: 51
  • Country: ge
Re: Possible GW Instek GDS-1000B hack
« Reply #218 on: January 15, 2021, 09:07:51 pm »
I ran the "nandtest" command on them without knowing it actually changes the data in the partitions if not instructed to keep the original date.
then after a reboot .... boom!! no boot. luckily I didn't run it on the user partition or else there would have been no way to recover from that!

the .DTB file is used in the Zynq project. after being compiled to binary you can only see the definitions inside it and can't get the file back directly. but I think it's possible to write a script for that to recover the original .DTB is the case it's needed
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3221
  • Country: pt
Re: Possible GW Instek GDS-1000B hack
« Reply #219 on: January 15, 2021, 09:15:46 pm »
Here is the .DTB.  :)

It's inside the bootloader (offset 0xFA154) and, most probably, it's loaded by it.

Parsing:
Code: [Select]
000FA154                 Magic: D00DFEED    FDT File OK
000FA158             File Size: 00002868
000FA15C      DT Struct Offset: 000FA18C
000FA160     DT Strings Offset: 000FC430
000FA164     Mem RsvMap Offset: 000FA17C
000FA168               Version: 00000011
000FA16C  Last Compatible Vers: 00000010
000FA170           Boot CPU_ID: 00000000
000FA174       DT Strings Size: 0000058C
000FA178        DT Struct Size: 000022A4
000FA18C
000FA194     #address-cells = 0x00000001
000FA1A4     #size-cells = 0x00000001
000FA1B4     compatible = xlnx,zynq-7000
000FA1D0     model = Xilinx Zynq
000FA1E8     aliases
000FA1F4        ethernet0 = /amba@0/ps7-ethernet@e000b000
000FA220        serial0 = /amba@0/serial@e0001000
000FA244        i2c0 = /amba@0/ps7-i2c@e0004000
000FA270     chosen
000FA27C        bootargs = console=ttyPS0,115200n8 ubi.mtd=5,2048 root=ubi0:rootfs rootfstype=ubifs ro earlyprintk mem=124M memmap=4M$0x7C00000 memmap=128M$0x08000000
000FA314        linux,stdout-path = /amba@0/ps7-uart1@e0001000
000FA340     cpus
000FA34C        #address-cells = 0x00000001
000FA35C        #size-cells = 0x00000000
000FA36C        cpu@0
000FA378           bus-handle = 0x00000001
000FA388           compatible = arm,cortex-a9
000FA3A4           d-cache-line-size = 0x00000020
000FA3B4           d-cache-size = 0x00008000
000FA3C4           device_type = cpu
000FA3D4           i-cache-line-size = 0x00000020
000FA3E4           i-cache-size = 0x00008000
000FA3F4           interrupt-handle = 0x00000002
000FA404           reg = 00000000
000FA418        cpu@1
000FA424           bus-handle = 0x00000001
000FA434           compatible = arm,cortex-a9
000FA450           d-cache-line-size = 0x00000020
000FA460           d-cache-size = 0x00008000
000FA470           device_type = cpu
000FA480           i-cache-line-size = 0x00000020
000FA490           i-cache-size = 0x00008000
000FA4A0           interrupt-handle = 0x00000002
000FA4B0           reg = 00000001
000FA4C8     pmu
000FA4D0        compatible = arm,cortex-a9-pmu
000FA4F0        interrupt-parent = 0x00000002
000FA500        interrupts = 000000000000000500000004000000000000000600000004
000FA524        reg = F889100000001000F889300000001000
000FA540        reg-names = cpu0
000FA55C     memory@0
000FA56C        device_type = memory
000FA580        reg = 0000000010000000
000FA598     amba@0
000FA5A4        #address-cells = 0x00000001
000FA5B4        #size-cells = 0x00000001
000FA5C4        compatible = xlnx,ps7-axi-interconnect-1.00.a
000FA5FC        ranges =
000FA608        linux,phandle = 0x00000001
000FA618        phandle = 0x00000001
000FA628        ps7-afi@f8008000
000FA640           compatible = xlnx,ps7-afi-1.00.a
000FA660           reg = F800800000001000
000FA678        ps7-afi@f8009000
000FA690           compatible = xlnx,ps7-afi-1.00.a
000FA6B0           reg = F800900000001000
000FA6C8        ps7-afi@f800a000
000FA6E0           compatible = xlnx,ps7-afi-1.00.a
000FA700           reg = F800A00000001000
000FA718        ps7-afi@f800b000
000FA730           compatible = xlnx,ps7-afi-1.00.a
000FA750           reg = F800B00000001000
000FA768        ps7-ddrc@f8006000
000FA780           compatible = xlnx,ps7-ddrc-1.00.a
000FA7B0           reg = F800600000001000
000FA7C4           xlnx,has-ecc = 0x00000000
000FA7D8        ps7-dev-cfg@f8007000
000FA7F4           clock-names = ref_clk
000FA820           clocks =
000FA854           compatible = xlnx,ps7-dev-cfg-1.00.a
000FA878           interrupt-parent = 0x00000002
000FA888           interrupts = 000000000000000800000004
000FA8A0           reg = F800700000000100
000FA8B8        ps7-dma@f8003000
000FA8D0           #dma-cells = 0x00000001
000FA8E0           #dma-channels = 0x00000008
000FA8F0           #dma-requests = 0x00000004
000FA900           arm,primecell-periphid = 0x00041330
000FA910           clock-names = apb_pclk
000FA928           clocks =
000FA93C           compatible = xlnx,ps7-dma-1.00.a
000FA974           interrupt-names = abort
000FA9B0           interrupt-parent = 0x00000002
000FA9C0           interrupts = 000000000000000D00000004000000000000000E00000004000000000000000F00000004000000000000001000000004000000000000001100000004000000000000002800000004000000000000002900000004000000000000002A00000004000000000000002B00000004
000FAA38           reg = F800300000001000
000FAA50        ps7-ethernet@e000b000
000FAA6C           #address-cells = 0x00000001
000FAA7C           #size-cells = 0x00000000
000FAA8C           clock-names = ref_clk
000FAAAC           clocks =
000FAAC8           compatible = xlnx,ps7-ethernet-1.00.a
000FAAF0           interrupt-parent = 0x00000002
000FAB00           interrupts = 000000000000001600000004
000FAB18           local-mac-address =
000FAB2C           phy-handle = 0x00000004
000FAB3C           phy-mode = rgmii-id
000FAB54           reg = E000B00000001000
000FAB68           xlnx,eth-mode = 0x00000001
000FAB78           xlnx,has-mdio = 0x00000001
000FAB88           xlnx,ptp-enet-clock = ♠?k?
000FAB98           mdio
000FABA4              #address-cells = 0x00000001
000FABB4              #size-cells = 0x00000000
000FABC4              phy@0
000FABD0                 compatible = micrel,ksz9031
000FABEC                 device_type = ethernet-phy
000FAC08                 reg = 00000000
000FAC18                 linux,phandle = 0x00000004
000FAC28                 phandle = 0x00000004
000FAC44        ps7-gpio@e000a000
000FAC5C           #gpio-cells = 0x00000002
000FAC6C           clocks =
000FAC80           compatible = xlnx,ps7-gpio-1.00.a
000FACA4           emio-gpio-width = 0x00000040
000FACB4           gpio-controller =
000FACC0           gpio-mask-high = 0x00000000
000FACD0           gpio-mask-low = ☼►?☻
000FACE0           interrupt-parent = 0x00000002
000FACF0           interrupts = 000000000000001400000004
000FAD08           reg = E000A00000001000
000FAD1C           linux,phandle = 0x00000005
000FAD2C           phandle = 0x00000005
000FAD40        ps7-i2c@e0004000
000FAD58           bus-id = 0x00000000
000FAD68           clocks =
000FAD7C           compatible = xlnx,ps7-i2c-1.00.a
000FAD9C           input-clk = ♠?k?
000FADAC           i2c-clk = 0x000186A0
000FADBC           i2c-reset =
000FADD4           interrupt-parent = 0x00000002
000FADE4           interrupts = 000000000000001900000004
000FADFC           reg = E000400000001000
000FAE10           xlnx,has-interrupt = 0x00000000
000FAE20           #address-cells = 0x00000001
000FAE30           #size-cells = 0x00000000
000FAE40           touch@38
000FAE50              compatible = edt-ft5x06
000FAE68              reg = 00000038
000FAE80        ps7-iop-bus-config@e0200000
000FAEA0           compatible = xlnx,ps7-iop-bus-config-1.00.a
000FAECC           reg = E020000000001000
000FAEE4        ps7-pl310@f8f02000
000FAEFC           arm,data-latency =
000FAF14           arm,tag-latency =
000FAF2C           cache-level = 0x00000002
000FAF3C           cache-unified =
000FAF48           compatible = xlnx,ps7-pl310-1.00.a
000FAF7C           interrupt-parent = 0x00000002
000FAF8C           interrupts = 000000000000000200000004
000FAFA4           reg = F8F0200000001000
000FAFBC        ps7-ocmc@f800c000
000FAFD4           compatible = xlnx,ps7-ocmc-1.00.a
000FB008           interrupt-parent = 0x00000002
000FB018           interrupts = 000000000000000300000004
000FB030           reg = F800C00000001000
000FB048        ps7-scugic@f8f01000
000FB060           #address-cells = 0x00000002
000FB070           #interrupt-cells = 0x00000003
000FB080           #size-cells = 0x00000001
000FB090           compatible = xlnx,ps7-scugic-1.00.a
000FB0D0           interrupt-controller =
000FB0DC           num_cpus = 0x00000002
000FB0EC           num_interrupts = 0x00000060
000FB0FC           reg = F8F0100000001000F8F0010000000100
000FB118           linux,phandle = 0x00000002
000FB128           phandle = 0x00000002
000FB13C        ps7-scutimer@f8f00600
000FB158           clocks =
000FB16C           compatible = xlnx,ps7-scutimer-1.00.a
000FB1AC           interrupt-parent = 0x00000002
000FB1BC           interrupts = 000000010000000D00000301
000FB1D4           reg = F8F0060000000020
000FB1EC        ps7-scuwdt@f8f00620
000FB204           clocks =
000FB218           compatible = xlnx,ps7-scuwdt-1.00.a
000FB23C           device_type = watchdog
000FB254           interrupt-parent = 0x00000002
000FB264           interrupts = 000000010000000E00000301
000FB27C           reg = F8F00620000000E0
000FB294        ps7-slcr@f8000000
000FB2AC           compatible = xlnx,ps7-slcr-1.00.a
000FB2DC           reg = F800000000001000
000FB2F0           clocks
000FB2FC              #address-cells = 0x00000001
000FB30C              #size-cells = 0x00000000
000FB31C              clkc
000FB328                 #clock-cells = 0x00000001
000FB338                 clock-output-names = armpll
000FB4B0                 compatible = xlnx,ps7-clkc
000FB4CC                 fclk-enable = 0x0000000F
000FB4DC                 ps-clk-frequency = ☻bZ
000FB4EC                 linux,phandle = 0x00000003
000FB4FC                 phandle = 0x00000003
000FB518        ps7-smcc@e000e000
000FB530           #address-cells = 0x00000001
000FB540           #size-cells = 0x00000001
000FB550           clock-names = ref_clk
000FB570           clocks =
000FB58C           compatible = xlnx,ps7-smcc-1.00.a
000FB5BC           interrupt-parent = 0x00000002
000FB5CC           interrupts = 000000000000001200000004
000FB5E4           ranges =
000FB5F0           reg = E000E00000001000
000FB604           xlnx,addr25 = 0x00000000
000FB614           xlnx,nor-chip-sel0 = 0x00000000
000FB624           xlnx,nor-chip-sel1 = 0x00000000
000FB634           xlnx,sram-chip-sel0 = 0x00000000
000FB644           xlnx,sram-chip-sel1 = 0x00000000
000FB654           ps7-nand@e1000000
000FB66C              compatible = xlnx,ps7-nand-1.00.a
000FB690              reg = E100000001000000
000FB6A4              xlnx,nand-clk-freq-hz = ♣??
000FB6B4              xlnx,nand-cycle-t0 = 0x0000000F
000FB6C4              xlnx,nand-cycle-t1 = 0x0000000F
000FB6D4              xlnx,nand-cycle-t2 = 0x00000007
000FB6E4              xlnx,nand-cycle-t3 = 0x00000007
000FB6F4              xlnx,nand-cycle-t4 = 0x00000007
000FB704              xlnx,nand-cycle-t5 = 0x00000007
000FB714              xlnx,nand-cycle-t6 = 0x0000000F
000FB724              xlnx,nand-width = 0x00000008
000FB734              #address-cells = 0x00000001
000FB744              #size-cells = 0x00000001
000FB754              partition@0x0
000FB768                 label = boot
000FB77C                 gw_part_type = 0x00000001
000FB78C                 reg = 00000000001C0000
000FB7A4              partition@0x1c0000
000FB7BC                 label = devtree
000FB7D0                 gw_part_type = 0x00000002
000FB7E0                 reg = 001C000000020000
000FB7F8              partition@0x1e0000
000FB810                 label = env
000FB820                 gw_part_type = 0x00000000
000FB830                 reg = 001E000000020000
000FB848              partition@0x200000
000FB860                 label = fpga-core
000FB878                 gw_part_type = 0x0000000B
000FB888                 reg = 0020000000080000
000FB8A0              partition@0x280000
000FB8B8                 label = kernel
000FB8CC                 gw_part_type = 0x00000014
000FB8DC                 reg = 0028000000300000
000FB8F4              partition@0x580000
000FB90C                 label = rootfs
000FB920                 gw_part_type = 0x0000001E
000FB930                 reg = 0058000002E40000
000FB948              partition@0x33C0000
000FB960                 label = user
000FB974                 gw_part_type = 0x00000064
000FB984                 reg = 033C000003C40000
000FB9A4        ps7-spi@e0006000
000FB9BC           clock-names = ref_clk
000FB9DC           clocks =
000FB9F8           compatible = xlnx,ps7-spi-1.00.a
000FBA18           interrupt-parent = 0x00000002
000FBA28           interrupts = 000000000000001A00000004
000FBA40           num-chip-select = 0x00000002
000FBA50           reg = E000600000001000
000FBA64           #address-cells = 0x00000000
000FBA74           #size-cells = 0x00000001
000FBA88        ps7-ttc@f8001000
000FBAA0           clocks =
000FBAB4           compatible = xlnx,ps7-ttc-1.00.a
000FBAE0           interrupt-names = ttc0
000FBAFC           interrupt-parent = 0x00000002
000FBB0C           interrupts = 000000000000000A00000004000000000000000B00000004000000000000000C00000004
000FBB3C           reg = F800100000001000
000FBB54        serial@e0001000
000FBB68           clock-names = ref_clk
000FBB88           clocks =
000FBBA4           compatible = xlnx,ps7-uart-1.00.a
000FBBD4           current-speed = 0x0001C200
000FBBE4           device_type = serial
000FBBF8           interrupt-parent = 0x00000002
000FBC08           interrupts = 000000000000003200000004
000FBC20           port-number = 0x00000000
000FBC30           reg = E000100000001000
000FBC44           xlnx,has-modem = 0x00000000
000FBC58        ps7-usb@e0002000
000FBC70           clocks =
000FBC84           compatible = xlnx,ps7-usb-1.00.a
000FBCA4           dr_mode = otg
000FBCB4           interrupt-parent = 0x00000002
000FBCC4           interrupts = 000000000000001500000004
000FBCDC           phy_type = ulpi
000FBCF0           reg = E000200000001000
000FBD04           xlnx,usb-reset = ????
000FBD18        ps7-usb@e0003000
000FBD30           clocks =
000FBD44           compatible = xlnx,ps7-usb-1.00.a
000FBD64           dr_mode = host
000FBD78           interrupt-parent = 0x00000002
000FBD88           interrupts = 000000000000002C00000004
000FBDA0           phy_type = ulpi
000FBDB4           reg = E000300000001000
000FBDC8           xlnx,usb-reset = ????
000FBDDC        ps7-xadc@f8007100
000FBDF4           clocks =
000FBE08           compatible = xlnx,ps7-xadc-1.00.a
000FBE2C           interrupt-parent = 0x00000002
000FBE3C           interrupts = 000000000000000700000004
000FBE54           reg = F800710000000020
000FBE6C        gw-lcdc@88800000
000FBE84           compatible = gw,gds-lcdc
000FBE9C           reg = 8880000000002000
000FBEB0           num-of-layers = 0x00000003
000FBEC0           row-stride = 0x00000320
000FBED0           column-stride = 0x000005A0
000FBEE0           use-background = 0x00000000
000FBEF0           buffer-0-offset = 0x00000000
000FBF00           layer-0-data-width = 0x00000010
000FBF10           layer-0-offset = 0x00000000
000FBF20           vmem-baseaddr = ?
000FBF30           vmem-highaddr = ???
000FBF44        gds_video_params
000FBF5C           pixel-component-format = RGB
000FBF6C           pixel-component-layer =
000FBF80           active-layer = 0x00000000
000FBF90           videomode = 800x480
000FBFA4           800x480
000FBFB0              refresh = 0x0000003C
000FBFC0              xres = 0x00000320
000FBFD0              yres = 0x000005A0
000FBFE0              vmode = 0x00000000
000FBFF4           800x600
000FC000              refresh = 0x0000003C
000FC010              xres = 0x00000320
000FC020              yres = 0x00000708
000FC030              vmode = 0x00000000
000FC048        gds_wfrm_swctl
000FC05C           compatible = gw,gds-wfrm-swctl
000FC07C           seginfo-base = ☼??
000FC08C           channel-source = ch1
000FC0CC        gds_iofpga
000FC0DC           compatible = gw,gds-iofpga
000FC0F8           iofpga-base = x??
000FC108           dvr0
000FC114              compatible = gds-iofpga,ad5207
000FC134              dev-id = 0x00000000
000FC144              create-dev-node = 0x00000001
000FC158           dvr1
000FC164              compatible = gds-iofpga,ad5207
000FC184              dev-id = 0x00000001
000FC194              create-dev-node = 0x00000001
000FC1A8           dvr2
000FC1B4              compatible = gds-iofpga,ad5207
000FC1D4              dev-id = 0x00000002
000FC1E4              create-dev-node = 0x00000001
000FC1F8           dvr3
000FC204              compatible = gds-iofpga,ad5207
000FC224              dev-id = 0x00000003
000FC234              create-dev-node = 0x00000001
000FC248           adc
000FC250              compatible = gds-iofpga,hmcad1511
000FC274              dev-id = 0x00000004
000FC284              create-dev-node = 0x00000001
000FC298           vco
000FC2A0              compatible = gds-iofpga,adf4360
000FC2C0              dev-id = 0x00000006
000FC2D0              create-dev-node = 0x00000001
000FC2E4           sensor
000FC2F0              compatible = gds-iofpga,lm95071
000FC310              dev-id = 0x00000007
000FC320              create-dev-node = 0x00000001
000FC334           led
000FC33C              compatible = gds-iofpga,gds_led
000FC35C              dev-id = 0x00000008
000FC36C              create-dev-node = 0x00000001
000FC380           fram
000FC38C              compatible = gds-iofpga,fm25cl
000FC3AC              dev-id = 0x00000009
000FC3BC              create-dev-node = 0x00000001
000FC3D0           fe
000FC3D8              compatible = gds-iofpga,gds1000b_fe
000FC3FC              dev-id = 0x0000000E
000FC40C              create-dev-node = 0x00000001
End of file!
 

Offline danymogh

  • Regular Contributor
  • *
  • Posts: 51
  • Country: ge
Re: Possible GW Instek GDS-1000B hack
« Reply #220 on: January 16, 2021, 04:30:22 am »
dude! you gotta share that parser of yours, it's pretty neat!
 

Offline danymogh

  • Regular Contributor
  • *
  • Posts: 51
  • Country: ge
Re: Possible GW Instek GDS-1000B hack
« Reply #221 on: January 16, 2021, 06:54:25 pm »
A basic info about the Lua App plugins:

The app consists of at least 4 files:
Code: [Select]
[app.png]        -- App Icon
[app.lua]         -- App main lua file
[app.txt] -- App Description
[app.inf] -- App install information (more below)

first of all, we need a script to swap the nibbles of 2 files.
1- app.txt
2- app.inf

I've created a simple nibbleswap.py python script that does that. for some reason, GW people thought of this as a way to obfuscate the app's info.

the app needs to be GunZipped in a folder with the apps' name just like the examples from the website or the SSH app I wrote as an example.

the [app.txt] is a brief explanation you see on the apps menu before opening the app.
the [app.inf] contains the install information with the following parameters:

Code: [Select]
[0x32453030] -- Fix value(most probably)
[0x03] -- App Id - must be unique among all apps (see below)
[0x0] -- UNKNOWN
[/home/dso/DigitalFilter] -- App install location
[DigitalFilter.png] -- App Icon
[DigitalFilter.lua] -- App main lua file
[DigitalFilter.txt] -- App Description
[DigitalFilter.log] -- App log (not sure what the use is)?
[0x0] -- App run mode - 0x3-> embedded(not lua -> e.g. DVM , DataLog) , 0x0 -> from app lua file.
[0x1] -- UNKNOWN
[0x1] -- App uninstall-able flag. setting to 0 disables uninstall!
[V0.00] -- App version. increasing this seems to install another app apparently.


the App Ids already occupied are :
Code: [Select]
0 - Go-nogo
1 - DVM
2 - DataLog
3 - [empty]
4 - [empty]
5 - DigitalFilter
So if you install the GW website apps you can't use the 0,1,2 and 5 for the ID parameter.
I've used #3 for the SSH app.

some more notes:

editing .inf files from SSH has no effect. the app has to be uninstalled and installed again.
installed information is stored in /home/dso/lua/NewLuaAPPInfo.txt
removing and creating an empty file causes all apps to be removed from the menu. (Excluding GO_NOGO App)

as an example of what can be done with the Lua, you can see the GO_NOGO.lua file which gives a pretty good understanding of how the app runs. the exposed Lua functions are in the /home/dso/lua directory. Also, I think doing a reflection like programming can give more insight into what functions are available on the Lua side.
 
The following users thanked this post: nctnico

Offline kcbrown

  • Frequent Contributor
  • **
  • Posts: 880
  • Country: us
Re: Possible GW Instek GDS-1000B hack
« Reply #222 on: February 04, 2021, 03:40:15 am »
I just got a brand new GDS-1054B with firmware 1.28 and I am running the code in the attached file. Yet it doesn't seem to accept these licenses. The unit gives me an error when I try all the options.

I may not have copied the ClearCode data correctly into the Javascript. I wasn't sure what the value for k should be. Can anyone help?

The file you attached is identical to what worked for me.  The serial number you enter is case-sensitive.  The serial number is what shows up on your scope in the dialog box that it shows when you hit Utility -> System -> System Info.  You should enter it exactly as that box shows, case and all. Mine was all upper-case, and worked correctly.

Note that the GDS-1054B will not accept the spectrum analyzer.  I didn't try any of the bandwidth keys because it looks like it's not going to have any effect, as it appears that the bandwidth is limited in hardware (see https://www.eevblog.com/forum/testgear/possible-gw-instek-gds-1000b-hack/msg3306636/#msg3306636).
 

Offline Grifto45

  • Newbie
  • Posts: 1
  • Country: ca
Re: Possible GW Instek GDS-1000B hack
« Reply #223 on: March 10, 2021, 01:35:01 am »
Hi I know it's been a while and I'm probably out of luck but is it still possible to hack it even after they locked the SSH acess?
 

Offline ResistorRob

  • Regular Contributor
  • *
  • Posts: 115
  • Country: us
Re: Possible GW Instek GDS-1000B hack
« Reply #224 on: March 10, 2021, 03:34:26 am »
Hi I know it's been a while and I'm probably out of luck but is it still possible to hack it even after they locked the SSH acess?

I read the first 2 pages of replies and it said you could downgrade the Firmware to version 1.8. Hack it, and then update the firmware to current.
You might want to read all 9 pages to see what all the latest developments are.

The Instek scope I would really like to hack is their MDO 2000. I've seen 1 comment ever with a guy claiming he did it, but never a post saying how to do it!
If I could get a MDO 4 channel scope for $1,400 then do a free update to unlock the 200MHz and all the decoding that would be very tempting indeed!
For my 10th Birthday I got a Fisher Price oscilloscope!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf