labtool48 软件解析
48UXP (sw)February 12th, 2009 by bushing · 5 Comments(This is the second part of a three part series. The first part described the hardware of this device; this part will describe the software / firmware that drives this thing, and the last part will document the modifications I made to the hardware and software to try to get it to do what I want.)There are three different programmable devices inside the 48UXP:[*]80C32 MCU
[*]XC3030A FPGA
[*]Cypress EZ-USB FX2
Of these, only the 80C32 has nonvolatile code storage; the other two devices have their code uploaded by the client every time they are used.
80C32 firmwareThe 80C32 firmware is contained on an EEPROM chip inside the device; I pulled the chip and read it using my crappy Willem-clone programmer.It contains about 6K of code and 24K of random bits of data, 2.5K of which is a “default” bitstream to upload to the XC3030A.It’s responsible for transferring commands and data over an 8-bit pipe from the FX2 (or parallel port), programming the XC3030A over JTAG, driving the shift registers connected to the pin drivers, and transferring commands and data over an 8-bit pipe to the XC3030A.There’s a lookup table which takes a 1-byte command and jumps to a fixed pointer.There’s a command that lets you upload data to arbitrary places in the SRAM, and a command that causes execution to jump to code inside the SRAM; this lets them upload routines and run them.XC3030A bitstreamsThere are a number of different FPGA bitstreams in use here.One is hard-coded in the 80C32 firmware, and two hard-coded in the Windows client executable.The rest are contained in the resource files, which we will discuss shortly.Unfortunately, there’s no way to analyze these bitstreams; we just have to treat them as black boxes, and deduce their functionality from context.FX2 firmwareThe FX2 has a USB bootloader which accepts code over USB.The Windows client has two different firmwares embedded in it, and it seems to pick one or the other based on a device ID.It calls itself “EPP LabTool USB 2.0 Bridge Version 1.13″, and like the 80C32 firmware, it accepts one-byte commands.However, these one byte commands are mainly used … to send sequences of one-byte commands to the 80C32.We have layers and layers of protocol, here, and I sort of wish I had started looking at the parallel port version of this software before the USB version.That being said, there are much better tools available for capturing and analyzing USB traffic, and I don’t even have a parallel port!Windows clientThe thing has a Windows client — if you’d like, you can download a free “demo” copy from here, or more specifically, here. As with the Infectus software analysis I did, I used three tools:
[*]IDA Pro, to analyze the executable — this proved to be less helpful this time than I had hoped
[*]SniffUsb (inside VMWare Fusion) — there are several free / open-source programs that do similar things with similar names; This version is the one that has worked best for me.
[*]usbsnoop2libusb.pl — this amazing perl script will take the output from the above program and make it into a C program that uses libusb to replay the transactions back to the device. I didn’t use it for that, directly, but it’s a nice base to use to develop code to filter the above output into something more readable.
All of the interesting bits are contained in a set of “resource files” (*.rez) that are unpacked by the installer alongside the main executable. It’s a binary container format, which was annoying to deal with — rather than try to explain the exact format, I refer you to the ugly Python script I cranked out to try to make some sense of it. The USB dumps ended up playing a critical role in understanding the binary file format, because I was able to modify the binary .rez file and observe the change in the data sent over USB.First, we have a file containing a list of all supported devices (lots and lots and lots!) Here’s an annotated excerpt:TDevPool: 02a9 07f8 001b 00 00ec 0076 00 001f 01 02 K9F1208U0A *48TSTDevPool: 02ba 07f8 001b 00 00ec 0076 00 001f 01 02 K9F1208U0B *48TSTDevPool: 02cb 07f8 0018 00 00ec 0073 00 001f 01 02 K9F2808U0B *48TSTDevPool: 02dc 07f8 0018 00 00ec 0073 00 001f 01 02 K9F2808U0C *48TSTDevPool: 02ed 07f8 001a 00 00ec 0075 00 001f 01 02 K9F5608U0B *48TSTDevPool: 02fe 07f8 001a 00 00ec 0075 00 001f 01 02 K9F5608U0C *48TSTDevPool: 030f 07f8 0017 00 00ec 00e6 00 006c 01 02 K9F6408U0A *44TSTDevPool: 0320 07f8 0017 00 00ec 00e6 00 006c 01 02 K9F6408U0B *44TSTDevPool: 0331 07f8 0017 00 00ec 00e6 00 006c 01 02 K9F6408U0C *44TSIn order, the fields are table_index, device_class, device_type, ?, vendor ID, chip ID, ?, ?, ?, ?, chip name, adapter name. device_class is looked up in a table inside the executable, which gives a class of “TXPMemDev” and a corresponding resource file of “GDBA____.rez”.I now draw your attention to my partially-decoded version of GDBA___.rez.Let’s take a specific example from that file:D1b: TXPMemDev: famcode=0013 pinmap=000c 0000 ff 04200000 08 00 00 00 20 04 00 42 00 00 04200000D1b corresponds to the device_type in the device list. 0×04200000 is the size of the chip — it’s a 64MB small-block NAND flash chip. 000c tells us which pinmap to use:Pc: TPinCode: 48 pins,0000000004 09 00 02 00 02 00 182f 01 00 04 00 00 17 190000001029 06 00 08 00 10 11 1213 1c 1d 1e 1f 03 00 1d0000002000 01 02 07 08 09 0a 0b0c 0d 0e 0f 14 15 16 19000000301a 1b 20 21 22 23 24 2526 27 28 29 2d 2e 04 000000004003 00 01 00 04 00 0e 0005 00 0f 00 06 00 0b 000000005018 00 07 00 2a 00 08 002b 00 03 00 2c 00 0c 00000000602f 00(I don’t know anything more about the format of this entry)We also know which “TFamCode” to use:M13: TFamCode: 0c0000 002b _FUN_POWERON0001 0033 _FUN_POWEROFF0002 002d _FUN_DEVINIT0003 0031 _FUN_DEVRESET0004 002e _FUN_GETID000a 0030 _FUN_ERASE0017 0039 _FUN_DNLDERASE0014 003a _FUN_DNLDPROG0011 003b _FUN_DNLDREAD0013 003c _FUN_DNLDBLKCHK0015 003d _FUN_DNLDVERIFY001b 003f _FUN_XC3030DataHere, we’re getting closer to something usable. The first column is an index into a list of functions (you can find it elsewhere in the file) — I’ve decoded it to put the function name on the right. This tells us what “WaveCode” we need to use.WaveCodesI’m assuming that “Wave” here is short for “Waveform”, meaning that these blobs tell the device how to generate the signals which need to be applied to each pin.There are three types:Type 0: Bytecode0000 002b _FUN_POWERONW2b: TWaveCode: type = 0 data =0000000030 00 12 00 02 33 01 110f 00 11 04 00 11 01 000000001003 0b 00 0b 0c 01 00 0002 01 00 3b c0 3b ff 34000000200f 11 03 01 11 08 01 110e 01 11 0f 01 32 40 0d0000003003 00In my notes, I have this down as being some sort of interpreted bytecode, run on a statemachine inside the Windows program. Looking at it with fresh eyes and comparing it to the USB traffic, it may just be a list of 80C32 commands. Something that immediately stands out here is the ‘ff’ at 0x1e — that’s the RESET code in the NAND command set.Type 4: FPGA Bitstream001b 003f _FUN_XC3030DataW3f: TWaveCode: type = 4 data =00000000da 0a ff 04 a0 36 f9 fcff ff ff ff ff ff ff ff00000010ff ff ef f7 f7 f7 f7 f7ef ef ef ef ef fe e6 fe00000020fe fe fe fe fd fd fd fdf5 cf ff ff ff ff ff fe[...]00000ad0ff ff ff ff df ff ff ffbf bf ff ffThis bitstream is sent before anything else is done with the chip. It’s really the code to which the 80C32 talks, and it’s what actually drives the pins on the flash chip.Type 6: 80C32 code0011 003b _FUN_DNLDREADW3b: TWaveCode: type = 6 (805x) len1 = 0189 addr=6000 len2 = 0185 data =0000000090 f0 00 75 a0 c8 20 b2fd 30 b5 03 02 61 23 7500000010a0 d8 e2 fc 54 f0 70 0790 60 58 ec 23 23 73 ec00000020c3 94 7f 50 2c 75 e0 00c0 e0 75 e0 60 c0 e0 90[...]00000180d2 97 02 60 06This code is uploaded to the 80C32′s attached SRAM chip at address 0×6000; it is then executed. We can disassemble this code to see how it works, and I ended up doing so to modify it, but we’ll get to that in the next article.I can post some annotated USB logs, if there’s interest. 东西不错！可惜我E文不行！:D 找个字典慢慢看阿，我是觉得还没说到点子上，作者有保留 2009年2月,12th套管·5的评论
(这是第二部分的三个组成部分的系列。第一部分描述了该装置的硬件;本部分将描述软件/固件驱动的事情,最后一部分将文件修改我的硬件和软件去做我想做的事。)
有三种不同的可编程器件在48 UXP:
1.80 C32单片机
2。XC3030A FPGA
3。柏树FX2 ez - usb
其中,只有80 C32已失代码存储;另外两个设备有自己的代码上传客户每次运用它们。
80 C32固件
80 C32固件就包含在EEPROM芯片内的设备;我把芯片和读它用我蹩脚的Willem-clone程序员。它含有大约6 K代码和24 K的随机比特的数据,2.5 K是一个“默认为“零到XC3030A上传。它负责传递命令和数据在一个8位的管道从FX2(或平行港口),规划XC3030A JTAG的转变,在驾驶寄存器连接到销的车手,命令和数据传递一个8位XC3030A管道。有一个查询表中占有重要1-byte指挥和跳一个固定的指针。有一个命令,让你上传数据任意地方的静态存储器,一个命令导致执行跳转到代码内,这让他们上传柱体套路和运行它们。
XC3030A bitstreams
有好几种不同的FPGA bitstreams使用这里。 一是硬编码在80 C32固件和两个硬编码在窗口客户端执行的。其余的是包含在源文件,我们将予以讨论。不幸的是,没有办法分析这些bitstreams;我们要做的只是把他们视为黑色的盒子,而演绎和语境的功能。
FX2的固件
有一个USB引导的FX2承接代码USB。窗户的客户有两个不同的嵌入固件,似乎才选好了一顶 这个汉化可真拗口 翻译的狗屁不通
页:
[1]