On Fri, Apr 03, 2009 at 03:21:38AM -0400, Alexander Shumakovitch wrote: [...] > 3) Protocol used. > The firmware upload process consists of a couple of simple handshaking > messages and verbatim shoving of the firmware into the corresponding serial > interface. The firmware is sent in 1MB-long chunks with zero-length packets > in between. One of the firmware file is cut short by 8 bytes for some > reason. The correct length can be found in QDLService.txt > This file contains all the messages completely, except that most of them are > surrounded by 0xfe with the checksum added before sending (compare messages > in QDLService.txt with those in my script). I see 0x7e there... > > This is the only place where the sniffer is needed, since I wasn't able to > guess the algorithm for this checksum. Perhaps someone can figure it out. > Then all the information needed to upload the firmware will be contained in > QDLService.txt completely. Looks like typical PPP-async framing - 0x7e flag bytes around, and 16-bit FCS calculated using the CRC-CCITT algorithm (at least the messages in your info match the CRC-CCITT results). See lib/crc-ccitt.c and drivers/net/ppp_async.c:ppp_async_encode() (basically, you pass all data bytes to crc_ccitt() using 0xffff as the initial value, then invert the result and send it LSB first). Most likely the 0x7d and 0x7e bytes in the raw data need to be transferred as escape sequences (0x7d 0x5d and 0x7d 0x5e). send3 and send5 do not have 0x7e flag bytes around them, but seem to have the PPP FCS at the end too. [...] > send1="7e 01 51 43 4f 4d 20 68 69 67 68 20 73 70 65 65 64 20 70 72 \ > 6f 74 6f 63 6f 6c 20 68 73 74 00 00 00 00 04 04 30 03 0b 7e" > > # receive1="7e 02 51 43 4f 4d 20 68 69 67 68 20 73 70 65 65 64 20 70 \ > # 72 6f 74 6f 63 6f 6c 20 74 67 74 04 00 f0 cb 04 04 00 00 00 \ > # 00 00 00 00 00 00 00 00 00 00 30 64 7a 7e" > > send2="7e 25 05 88 51 91 00 01 00 00 00 04 00 00 c4 e2 7e" > > # receive2="7e 26 00 00 01 00 00 00 04 52 65 7e" > > send3="27 00 00 00 00 00 00 88 51 91 00 b4 5c" > > # receive3="7e 28 00 00 00 00 00 00 00 00 14 39 7e" > > send4="7e 25 06 1c 71 36 00 01 00 00 00 04 00 00 98 ae 7e" > > # receive4="7e 26 00 00 01 00 00 00 04 52 65 7e" > > send5="27 00 00 00 00 00 00 1c 71 36 00 5b 21" > > # receive5="7e 28 00 00 00 00 00 00 00 00 14 39 7e" > > send6="7e 29 bb 4c 7e" [...]
Attachment:
signature.asc
Description: Digital signature
