[Epic 4G Android Development] LiberatorUSA:
Clues in modem_delta.bin

*updated, inspecting other deltas as well and adjusting theories*

If the file structure where compressed using method of fixed blocks and RLE or something similar you would expect that a file which is the superset of the other to show identical blocks. Alas no such identical blocks are found.

The block matching I did on these files was with blocks of 64 bytes.

I did notice that the delta files have the first 6 bytes differing and then have a block of 90 bytes which are identical with lots of 0's and some identical values.

Looking through the different delta files we find a value at byte 24 which is:

To DI07: 3

To DI18: 2

To DK28: 2

To EB13: 2

To EC05: 3

The question here is, why do DI-7 and EC05 get a 3 and the rest a 2? Perhaps 3 = feature release/update and 2 = maintenance update?

Clearly the start of the delta file is some sort of header with meta-data.

Another interesting section in all delta files is a sequence pattern of:

5D 00 00 20 00 ## ## 00 00 00 00 00 00 00 00 ## ##

You can find this sequence at the following offsets:

DG27 to DI07: 125, 1484, 6901, 7797, 8684, 8838

DI07 to DI18: 125, 672, 3147, 3352, 3980, 4049

DI18 to DK28: 125, 16093, 27460, 34378, 37486, 40429

DI18 to EB13: 125, 17641, 29228, 36646, 39868, 42916

DI18 to EC05: 125, 17307, 29866, 37811, 41322, 44882

EB13 to EC05: 125, 7094, 15299, 18442, 19970, 21726

Each delta file always has this sequence 6 times. Delta files vary quite a bit in size, why would there always be 6 of these?

This seems to be some sort of section header or delimiter

Ill number the pound bytes so I can reference them:

5D 00 00 20 00 #1 #2 00 00 00 00 00 00 00 00 #3 #4 #5

5D 00 00 20 00 ## ## 00 00 00 00 00 00 00 00 ## ## ##

Ill place the values in the same order as the offsets.

For #1 & #2 we find the following:

DG27 to DI07: 61 15, 8D 23, 96 04, 67 04, A8 00, 3A 02

DI18 to DK28: A4 7A, D2 5A, A1 30, BE 15, 4E 13, 90 29

DI18 to EB13: B2 7E, 8D 5E, 7C 35, A5 16, B2 13, 54 2D

DI18 to EC05: B5 8A, 00 64, CA 37, BF18, 94 16, 2E 32

EB13 to EC05: 30 3F, EF 3E, 0B 16, B5 08, FE 0C, 02 14

Since the ARM CPU's can work in both little and big endian mode plus of course conversions could be made while reading the data (although this is less likely, why would sammy make it difficult for themselves) I will show these bytes interpreted as 16bit integers in either format:

As an experiment, here are the values for the 2nd sequence:

For little-endian:

DI18 to DK28: 23250

DI18 to EB13: 24205

DI18 to EC05: 25600

EB13 to EC05:16111

For big-endian:

DI18 to DK28: 53850

DI18 to EB13: 36190

DI18 to EC05: 100

EB13 to EC05: 61246

The little endian numbers are within better range wrt achother and doesnt have an odd outlier like the 100 number so going forward we will assume that any integers etc are stored in little endian format.

These numbers could be an offset if it is then if doesnt have to be an offset in bytes. it can be an offset in blocks with a fixed block size such as 64 or 256 etc.

For #3 we find the following:

DI18 to DK28: 80

DI18 to EB13: 80

DI18 to EC05: 80

EB13 to EC05: 80

For #4 we find the following:

DI18 to DK28: 24

DI18 to EB13: 24

DI18 to EC05: 25

EB13 to EC05: 16

For #5 we find the following:

DI18 to DK28: 53

DI18 to EB13: 52

DI18 to EC05: 54

EB13 to EC05: EA