From: Roger B. <ro...@ro...> - 2004-05-03 06:00:57
|
> Sometimes the length byte is not adjacent to the > string, but after a whole bunch of other things, like it was added as an > afterthought. I think the firmware engineers could quite easily write a book called 101 Ways to encode a string! > The Sanyo is like this. Packets are 505 bytes, not including checksum > and framing byte. For the newer phones, the packet size went to over > 1000, although, in most cases the extra 500 bytes are never used. But > for these newer phones, the packet sent to the phone does not need to > match in size any more. The Audiovox has different sized packets depending on the command. I also did some experiments and it turns out I don't need to do the silly padding. The sync tool I sniffed did that so maybe it is a constraint only of the earlier phones. I also tried sending packets that were too small (eg used a one byte slot number instead of two) and you get back pseudo-valid junk. > > It also has no error codes. > Sanyo has an error code if you send it a packet that doesn't have the > right size or is otherwise bad. It sends back a small packet with Y (I > think) as the first character and a fragment of the packet sent to it. Packets begining with 'Y' (0x59) are Brew packets. The second byte is the command and the third byte is the error code. > For Sanyos, if the slot has been previously used, you get the old data, > otherwise zeros. So if you delete entries on the phone, you could > potentially recover them. (Or someone else could!) The PC-Sync software I am sniffing requires you to connect to the phone and supply the security code. Of course you don't really need it to read entries. If you are bored, try sending 0x26 0x52 as a packet and see what you get. I have also just renamed several pieces in the Audiovox code to use the same terminology as you (ie "slots"). > > It still boggles my mind > > how badly written the embedded software is in these phones. > At least all these phones share the same HDLC framing. They also all use LSB integers. Roger |