Author Topic: TDS 744A (& friends) firmware reverse engineering  (Read 7712 times)

0 Members and 1 Guest are viewing this topic.

Offline charlyd

  • Regular Contributor
  • *
  • Posts: 74
  • Country: nl
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #50 on: October 17, 2017, 05:37:50 am »
Yes that is correct i have a TDS784D and a TDS754D here both have CPU board seems to be 679-4349-00 .
The ACQ board is  679-4771-01.
« Last Edit: November 23, 2017, 09:53:09 am by charlyd »
 

Offline smartboy123

  • Contributor
  • Posts: 8
  • Country: cn
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #51 on: October 19, 2017, 12:08:15 pm »
Whoops, looks like i have to update the documentation. But glad to hear that it works for you now and the scope isn't bricked.

Your document is still with typo error, I check just now   :-DD :-DD :-DD :-DD
 

Offline charlyd

  • Regular Contributor
  • *
  • Posts: 74
  • Country: nl
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #52 on: November 11, 2017, 06:47:12 am »
typo error for what?
 

Offline fenugrec

  • Contributor
  • Posts: 45
  • Country: ca
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #53 on: November 25, 2017, 08:20:28 am »
Nice to see some action here, even if it's not quite in the direction I was hoping. Does anyone have the combination of the following :

- TDS7xx scope
- dumped firmware (either dumped themselves, or available online like ko4bb's archive)
- internal service port hooked up

Each of these is easy, but I have yet to find a *matching* combination of the correct fw version dump, plus someone with the service port hookup.

[EDIT]
I am now GPIB-enabled, and also I have just found dxl's github repo : )
https://github.com/sschnelle/tekfwtool
« Last Edit: January 03, 2018, 08:33:12 am by fenugrec »
 

Offline fenugrec

  • Contributor
  • Posts: 45
  • Country: ca
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #54 on: January 13, 2018, 11:56:08 am »
Finally, I have dumped my TDS744A v1.1e firmware and NVRAM areas.
For the moment they're in "recent uploads" on KO4BB
http://www.ko4bb.com/getsimple/index.php?id=manuals&dir=07_Recent_Uploads

I had to "backport" dxl's tekfwtool to compile and run on DOS, since the computer with the GPIB-AT card runs freeDOS !
More details on that patch @ https://github.com/sschnelle/tekfwtool/pull/1
 

Offline fenugrec

  • Contributor
  • Posts: 45
  • Country: ca
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #55 on: February 13, 2018, 08:48:08 am »
I've started analysis work on my 1.1e ROM . Lots of interesting stuff ! Having the symbol table is a tremendous help.

Here's a few interesting things I've found so far, sifting through the symbols and disassembly:

- "_Unpack_text" .  A lot of text is packed (compressed) into a raw array (aptly named _Packed_text ), and accessed through a table of records ("_RecIndex"). On my ROM there are 648 strings, for a total of ~58kB of packed data ! I guess pretty much all the UI stuff is in there; the other plaintext strings in the ROM seem to be mostly debugging / logging.

- On my ROM, a certain number of functions (like _RunAcqDiagCh1) are not implemented and jump to the generic "_stubme" function that just logs an error.

- the rs232 comms function would probably allow to set a custom, higher baudrate for the service console. This would make dumping the ROM over the console port a viable option.

- the ability to do basically everything from the service console means that there's no real technical obstacle to reflashing / modifying options from the console port, instead of requiring a GPIB connection.

I'm not sure why there's apparently so little hacking done on the firmware for these. The CPU is a well known 68k architecture, the ROMs are fairly easy to dump and/or available online, and for goodness sake they include an exhaustive symbol table that maps almost every important function and global variable !!

Plus, if I'm not mistaken there's plenty of ROM space left. This opens the door to all kinds tweaks and hacks.
« Last Edit: March 14, 2018, 05:10:39 am by fenugrec »
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 5032
  • Country: us
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #56 on: February 13, 2018, 09:07:17 am »
It would be awesome if someone managed to add SPI/I2C/Serial/etc protocol decoding. That's about the only thing I can think of lacking in these scopes compared to more modern instruments.
 

Offline fenugrec

  • Contributor
  • Posts: 45
  • Country: ca
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #57 on: March 14, 2018, 06:55:48 am »
I imagine the structure and implementation of these scope's firmware will be very, very similar between versions and models. All the info I present is based on my own TDS744A with 1.1e firmware.

************** ROM header
Yay, the main ROM has a header with meaningful metadata !

It looks like this :

Code: [Select]
// the sizeof()  for this is 0x2C (determined by checksum code in kernel ROM)
struct flashhdr_short {
u8 jmp_trampoline[8]; // "nop", then "jmp _romInit"
u32 cksum_body_start; //ptr to beginning of body area to sum
u32 idata_start; // initial vals for _sdata in RAM
u32 sdata; //addr of _sdata in RAM
u32 bss_start; //also end of _sdata area
u32 cksum_body; //32-bit checkum of body area
u8 unknown[6];
u8 padding[8]; //always 0xFF bytes ?
u16 cksum_hdr; //checksum of this header
};


************* Boot process (main ROM startup)
Part of the boot process goes like this :

  • the kernel ROM jumps to the main ROM jmp "trampoline" (at 0x100 0000). This jumps to
  • _romInit : does some basic ROM / RAM checks, including calling _InitDataSpace. Then passes control to _usrInit.
  • _InitDataSpace : short function that initializes the "_sdata" section in RAM with data from the ROM's idata section; also clears the bss section in RAM.
  • _usrInit : preps the interrupt and exception vectors, then calls _kernelInit . Note ! starting here, "kernel" refers to the VxWorks kernel and not the one that ran on initial power up. This function initializes Vx with a new task :
  • _usrRoot ; things get interesting.  It calls some interesting functions like _led_walk, _bumpLed, _symTblAdd (more on this later) , _printLogo ( !) and others. Then things branch out a lot due to the use of _taskSpawn .


************* symbol table
It took me a while to figure all this out, but here's some information that will
make the process easier when analyzing a new ROM.

ROM format : as we know the main ROM is mapped at 0x0100 0000 in the address
space. This must be kept in mind when looking at the raw data.  For instance,
 to be able to parse the ROM's built-in symbol table. This table
is the golden key : it associates a readable name to many, many functions and variables.
Each symbol item looks like this :

Code: [Select]
struct sym_item {
u32 unknown_0; //always 0 ?
u32 pName; //point to string
u32 pItem; //point to actual item (function or variable)
u8 type; //not 100% sure. 5 = code,  7 = idata, 9 = bss data ?
u8 unknown_1; //always 0 ?
};

Here's an example :
Code: [Select]
00 00 00 00   01 27 3E 6D    01 1E 0D 9E   05   00pName = 0x0127 3E6D , if we look inside the ROM at 0x273E6D, there's a string "_validateBootRomHeader"
pItem = 0x011E 0D9E, this is the entry point of that function.
type = 5, by now I'm pretty sure 5 means code, 7 and 9 are variables in RAM.


This symbol table is huge (5300 entries on my ROM) and quite conspicuous;
moreover its location at the end of the .idata section makes it pretty easy to find.
Allow me to save a thousand words :

Code: [Select]
                                            Location in address space
                                            (= ROM file offset + 0x0100 000)

    +-------------------------------------+
    | ROM image header                    | 0x0100 0000
    +-------------------------------------+
    | copyright strings                   | 0x0100 002C
    |                                     |
    |                                     |
    +-------------------------------------+
    | .text  |                            | 0x0100 01AA : _startChecksumming
    |        |  some code                 |
    |        |  "VROM" chunk              |
    |        |                            |
    |        |  more code                 |
    |        |                            |
    |        |                            |
    |        |  strings for each symbol   |
    |        |  (not copied to RAM)       |
    |        |                            |
    |        |                            |
    +-------------------------------------+
    | .idata | generic data               |  0x12750AA
    |        |                            |
    |        |                            |
    |        +----------------------------+
    |        | symlist[num_of_entries]    |  0x0129 92E8
    |        |                            |
    |        +----------------------------+
    |        | sym_num_of_entries         |  0x012A B474
    +-------------------------------------+
    | empty (0xFF)                        |  0x012A B47C
    |                                     |
    |                                     |
    |                                     |
    +-------------------------------------+  0x013F FFFF

*************
I think that's enough writing for today.
I'd love to hear from anyone else looking at these ROMs !

 

Offline ZL1CVD

  • Contributor
  • Posts: 32
  • Country: nz
Re: TDS 744A (& friends) firmware reverse engineering
« Reply #58 on: May 11, 2018, 09:23:05 pm »
could you please tell me you software setup for doing this with Agilent 82357B. I have same Agilent USB GPIB, Windows 7 64-bit, TDS-744A. I have NVSRAM & RTC to change out and need to back up everything before I do. Just not sure how to go about reading firmware and NVSRAM so any help would be greatly appreciated. 
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf