bitpim-devel

[Bitpim-devel] Audiovox CDM8900

[Roger B. <ro...@ro...>]

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

Re: [Bitpim-devel] Audiovox CDM8900

[Stephen W. <sa...@us...>]

On Sun, 2004-05-02 at 04:15, Roger Binns wrote:
> 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.


>   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.

> 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.

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

> 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.

> 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

> 
> Roger
> 

Re: [Bitpim-devel] Audiovox CDM8900

[Roger B. <ro...@ro...>]

Stephen Wood wrote:
> On Sun, 2004-05-02 at 04:15, Roger Binns wrote:
> > 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.
> 
> 
> >   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.
> 
> > 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.
> 
> >  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!)
> 
> > 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.
> 
> > 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
> 
> > 
> > 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
> Bit...@li...
> https://lists.sourceforge.net/lists/listinfo/bitpim-devel

Re: [Bitpim-devel] Audiovox CDM8900

[Roger B. <ro...@ro...>]

> 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