DIY编程器网

标题: labtool48 软件解析 [打印本页]
作者: liyf    时间: 2011-9-20 09:22
标题: 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:
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 firmware
The 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 bitstreams
There 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 firmware
The 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 client
The 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:
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 *48TS
TDevPool: 02ba 07f8 001b 00 00ec 0076 00 001f 01 02 K9F1208U0B *48TS
TDevPool: 02cb 07f8 0018 00 00ec 0073 00 001f 01 02 K9F2808U0B *48TS
TDevPool: 02dc 07f8 0018 00 00ec 0073 00 001f 01 02 K9F2808U0C *48TS
TDevPool: 02ed 07f8 001a 00 00ec 0075 00 001f 01 02 K9F5608U0B *48TS
TDevPool: 02fe 07f8 001a 00 00ec 0075 00 001f 01 02 K9F5608U0C *48TS
TDevPool: 030f 07f8 0017 00 00ec 00e6 00 006c 01 02 K9F6408U0A *44TS
TDevPool: 0320 07f8 0017 00 00ec 00e6 00 006c 01 02 K9F6408U0B *44TS
TDevPool: 0331 07f8 0017 00 00ec 00e6 00 006c 01 02 K9F6408U0C *44TS
In 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 04200000
D1b 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,
00000000  04 09 00 02 00 02 00 18  2f 01 00 04 00 00 17 19
00000010  29 06 00 08 00 10 11 12  13 1c 1d 1e 1f 03 00 1d
00000020  00 01 02 07 08 09 0a 0b  0c 0d 0e 0f 14 15 16 19
00000030  1a 1b 20 21 22 23 24 25  26 27 28 29 2d 2e 04 00
00000040  03 00 01 00 04 00 0e 00  05 00 0f 00 06 00 0b 00
00000050  18 00 07 00 2a 00 08 00  2b 00 03 00 2c 00 0c 00
00000060  2f 00
(I don’t know anything more about the format of this entry)
We also know which “TFamCode” to use:
M13: TFamCode: 0c
0000 002b _FUN_POWERON
0001 0033 _FUN_POWEROFF
0002 002d _FUN_DEVINIT
0003 0031 _FUN_DEVRESET
0004 002e _FUN_GETID
000a 0030 _FUN_ERASE
0017 0039 _FUN_DNLDERASE
0014 003a _FUN_DNLDPROG
0011 003b _FUN_DNLDREAD
0013 003c _FUN_DNLDBLKCHK
0015 003d _FUN_DNLDVERIFY
001b 003f _FUN_XC3030Data
Here, 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.
WaveCodes
I’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: Bytecode
0000 002b _FUN_POWERON
W2b: TWaveCode: type = 0 data =
00000000  30 00 12 00 02 33 01 11  0f 00 11 04 00 11 01 00
00000010  03 0b 00 0b 0c 01 00 00  02 01 00 3b c0 3b ff 34
00000020  0f 11 03 01 11 08 01 11  0e 01 11 0f 01 32 40 0d
00000030  03 00
In 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 Bitstream
001b 003f _FUN_XC3030Data
W3f: TWaveCode: type = 4 data =
00000000  da 0a ff 04 a0 36 f9 fc  ff ff ff ff ff ff ff ff
00000010  ff ff ef f7 f7 f7 f7 f7  ef ef ef ef ef fe e6 fe
00000020  fe fe fe fe fd fd fd fd  f5 cf ff ff ff ff ff fe
[...]
00000ad0  ff ff ff ff df ff ff ff  bf bf ff ff
This 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 code
0011 003b _FUN_DNLDREAD
W3b: TWaveCode: type = 6 (805x) len1 = 0189 addr=6000 len2 = 0185 data =
00000000  90 f0 00 75 a0 c8 20 b2  fd 30 b5 03 02 61 23 75
00000010  a0 d8 e2 fc 54 f0 70 07  90 60 58 ec 23 23 73 ec
00000020  c3 94 7f 50 2c 75 e0 00  c0 e0 75 e0 60 c0 e0 90
[...]
00000180  d2 97 02 60 06
This 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.
作者: bedz    时间: 2011-9-20 16:17
东西不错！可惜我E文不行！
作者: liyf    时间: 2011-9-20 17:49
找个字典慢慢看阿，我是觉得还没说到点子上，作者有保留
作者: liumingwei    时间: 2011-9-28 18:56
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。窗户的客户有两个不同的嵌入固件,似乎才选好了一顶
作者: liyf    时间: 2011-9-28 19:49
这个汉化可真拗口
作者: zjs423315    时间: 2017-6-30 11:58
翻译的狗屁不通



欢迎光临 DIY编程器网 (http://diybcq.com./) Powered by Discuz! X3.2