Jack Miller
2008-07-30 21:39:44 UTC
Hi all.
This isn't strictly Bitpim related (yet), but I'm attempting to reverse
engineer the format of the Sprint Rumor's contentInfo/executionInfo
databases. It's going very well for the most part and I have 90% of the file
figured out, but one thing I can't figure out is their string storage
techniques.
Perhaps someone in bitpim development will recognize the format, or have some
insight?
First there's a type code
0x00 0x04
Then a field num (incremented for each variable in the record)
0x36
The a field length
0x10
A marker of some sort
0x00 0xFF 0x00
The string, in ASCII (null terminated)
Applications
After the null terminator, though there's what is apparently garbage. The
string length includes the marker, terminator and the garbage, so it can be
used to jump over accurately. Sometimes it's got some random bytes in it.
Sometimes it's all zeroes. Sometimes there is no garbage.
It's not a hash of any sort, because it's changes between two identical
strings ("Applications" appears alot), and even the number of bytes of
garbage changes between identical strings.
It also can't be some sort of padding, as far as I can tell, it adds all
sorts of number of bytes, and the strings don't start or end on any special
address.
Also, the string 0x98 0xFE 0xCD 0xAB shows up a lot in the garbage as well,
but not always and not always at the beginning or the end when it does.
Anyone seen anything like this before? I've been manipulating the files with
a Python script, and two files one before I added a ringer via the internet
and one after and the *only* difference between the file I generate and the
reference file is the lengths of the strings/record/file and the lack of
garbage. Yet the reference file works and mine doesn't, so their must be
something to it...
Thanks for your help.
--Jack
This isn't strictly Bitpim related (yet), but I'm attempting to reverse
engineer the format of the Sprint Rumor's contentInfo/executionInfo
databases. It's going very well for the most part and I have 90% of the file
figured out, but one thing I can't figure out is their string storage
techniques.
Perhaps someone in bitpim development will recognize the format, or have some
insight?
First there's a type code
0x00 0x04
Then a field num (incremented for each variable in the record)
0x36
The a field length
0x10
A marker of some sort
0x00 0xFF 0x00
The string, in ASCII (null terminated)
Applications
After the null terminator, though there's what is apparently garbage. The
string length includes the marker, terminator and the garbage, so it can be
used to jump over accurately. Sometimes it's got some random bytes in it.
Sometimes it's all zeroes. Sometimes there is no garbage.
It's not a hash of any sort, because it's changes between two identical
strings ("Applications" appears alot), and even the number of bytes of
garbage changes between identical strings.
It also can't be some sort of padding, as far as I can tell, it adds all
sorts of number of bytes, and the strings don't start or end on any special
address.
Also, the string 0x98 0xFE 0xCD 0xAB shows up a lot in the garbage as well,
but not always and not always at the beginning or the end when it does.
Anyone seen anything like this before? I've been manipulating the files with
a Python script, and two files one before I added a ringer via the internet
and one after and the *only* difference between the file I generate and the
reference file is the lengths of the strings/record/file and the lack of
garbage. Yet the reference file works and mine doesn't, so their must be
something to it...
Thanks for your help.
--Jack