The firmware of the MSP430 FET is distributed for purposes of upgrades within MSP430.dll. In this brief article, I'll describe its location and a method for extraction.
Firmware as Regions
All of these examples will use MSP430.dll with the following checksum. My previous FET articles have used a firmware image from the last revision of libMSP430.so, so addresses and code fragments will differ slightly.
f0685a0eca0545dfc542530afff8159f
A bit of quick searching reveals that the firmware of the MSP430 FET is contained within MSP430.dll as little-endian words at these addresses.
Bootloader code at offset of 0x1BFE8, region [0xF800,0xFFE0).
Application code at offset of 0x1EB38, region [0x2500,0xF7E0).
IVT at offset of 0x1BDBC, region [0xFFE0,0xFFFF].
That is, to recover the bootloader, copy 32 bytes (0x10000-0xFFE0=0x20) from the DLL at (0x1BDBC+0xFFE0=0x2BD9C) offset to the target MSP430 image at 0xFFE0.
Below are memory maps of my first attempt at extraction and an old EZ430 FET. It's clear that a lot of junk has been included by accident, which is why tabular entries, rather than regions should be used.
In addition to the large segments, there are also a few scattered bytes that form the lower IVT. (See Repurposing the TI EZ430U, Part 3 for an explanation of why there are two Interrupt Vector Tables.) Because the lower IVT is sparse, only those words which are not 0xFFFF are included. For example, the lower RESET vector--which, incidentally, is never read by the bootloader, in which the lower RESET is hard-coded--resides at 0xF7FE and points to 0x2502.
Searching MSP430.DLL for the interrupt vector, "02 25", yields a few results, one of which is "fe f7 d9 02 02 25". That's quite clearly an entry in a table of some sort. Searching around it yields a few more entries.
Firmware as a Table
By this point is should be clear that while it might be possible to extract the different fragments of the firmware manually, it would by much nicer to dump the whole damned thing as a table. This can be done.
Each entry is of the form {adr, len, data} where adr is the 16-bit address of the fragment within the firmware image, len is the length of the data in 16-bit words, and data is a collection of 16-bit words as little-endian. Following one entry is another, ending with an invalid address. (Anything less than 0x200 is I/O, anything less than 0x2500 is not flash.) Adding 4+(len<<1) to an entry's pointer gives the next entry.
Using this technique and finding an initial entry point of 0x21036, I generated a dump that produces the following image (left) as compared to the previous attempt (right).
The new attempt contains everything important, including a few bytes which were missed in the first attempt. It also lacks all of the vestigial bytes that got roped in by the previous method. Further, as each binary is defined by a single entry point, it shouldn't be terribly difficult to search for the entry point in order to generically dump any version of the library.
This cleanliness is confirmed by the callgraph below, which properly shows no function calls between the bootloader (right) and the application (left). (Branches are not graphed.)
The Code
The MSP430 Flash Emulation Tool's firmware is available for free download in MSP430.DLL, and anyone wishing to experiment with it need only download the library and extract the code.
A hastily written extraction utility can be found by subversion. A screenshot follows.
svn co https://goodfet.svn.sourceforge.net/svnroot/goodfet/contrib/fetextract
Tidak ada komentar:
Posting Komentar