[Bitpim-devel] Audiovox CDM8900

[Roger Binns]

The code in CVS can now read the CDM8900 phonebook. If you have a 8900,
please try it out. (You won't hurt your phone).

There are two fields whose values don't quite make sense. Turn on protocol
logging, read your phonebook, and then press Ctrl-Alt-P in the log pane.
Look for ones where the class ends in readpbentryresponse (they are of
size 344) and come just before an entry saying "Read entry 9 - a name".

In the middle pane, open the tree view. The two fields are the ones I
marked as previous and next. They mostly seem to point to the previous
and next entry/slot numbers on the phone display (ie control the sort
order). They were perfectly in tune with the sort order for me until
I started screwing with phonebook entries (adding/removing some, setting
entries to secret) at which point many seemed to point to 0xffff.
I would be interested in thoughts on what they could be.

For those who are curious (eg Stephen :-) the phone has 300 slots
available for phonebook entries. There is one request to get a listing
of which slots are in use (with a byte per slot, a non-zero value in
the byte). It also has yet another silly way of encoding strings
for the phone numbers (other strings use a different mechanism).
There is a count byte, followed by a fix sized buffer. The count
says how many of the bytes make up the string. It also uses a
scheme where if a response is 123 bytes, you have to send a 123 byte
request (ie requests must be the same size as the expected response).
It also has no error codes. If you ask for a slot that has nothing
in it, you get almost random data back. The same is true of
padding in the strings. (If it was actually using the buffer
I sent, I would have expected nulls). It still boggles my mind
how badly written the embedded software is in these phones.

Roger

[Stephen Wood]

Post by Roger Binns
For those who are curious (eg Stephen :-) the phone has 300 slots
available for phonebook entries. There is one request to get a listing
of which slots are in use (with a byte per slot, a non-zero value in
the byte). It also has yet another silly way of encoding strings
for the phone numbers (other strings use a different mechanism).
There is a count byte, followed by a fix sized buffer. The count
says how many of the bytes make up the string.

The Sanyo strings are fixed length fields and most have a length byte.
I ignore the length on reading, because the strings are always null
padded if less than the field length. (Of course on writes, the length
has to be computed.) 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.

Post by Roger Binns
It also uses a
scheme where if a response is 123 bytes, you have to send a 123 byte
request (ie requests must be the same size as the expected response).

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.

Post by Roger Binns
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.

Post by Roger Binns
If you ask for a slot that has nothing
in it, you get almost random data back.

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!)

Post by Roger Binns
The same is true of
padding in the strings. (If it was actually using the buffer
I sent, I would have expected nulls).

Fortunately, my strings are null padded.

Post by Roger Binns
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.

I may have a Samsung phone to play with soon. We'll see how it's
weirdness compares to what we know so far.

Stephen

Post by Roger Binns
Roger

[Roger Binns]

Post by Stephen Wood

Post by Roger Binns
For those who are curious (eg Stephen :-) the phone has 300 slots
available for phonebook entries. There is one request to get a listing
of which slots are in use (with a byte per slot, a non-zero value in
the byte). It also has yet another silly way of encoding strings
for the phone numbers (other strings use a different mechanism).
There is a count byte, followed by a fix sized buffer. The count
says how many of the bytes make up the string.

The Sanyo strings are fixed length fields and most have a length byte.
I ignore the length on reading, because the strings are always null
padded if less than the field length. (Of course on writes, the length
has to be computed.) 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.

Post by Roger Binns
It also uses a
scheme where if a response is 123 bytes, you have to send a 123 byte
request (ie requests must be the same size as the expected response).

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.

Post by Roger Binns
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.

Post by Roger Binns
If you ask for a slot that has nothing
in it, you get almost random data back.

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!)

Post by Roger Binns
The same is true of
padding in the strings. (If it was actually using the buffer
I sent, I would have expected nulls).

Fortunately, my strings are null padded.

Post by Roger Binns
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.
I may have a Samsung phone to play with soon. We'll see how it's
weirdness compares to what we know so far.
Stephen

Post by Roger Binns
Roger

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bitpim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[Roger Binns]

Post by Stephen Wood
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!

Post by Stephen Wood
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.

Post by Stephen Wood

Post by Roger Binns
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.

Post by Stephen Wood
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").

Post by Stephen Wood

Post by Roger Binns
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