[Epic 4G Android Development] LiberatorUSA:
modem_delta.bin header clues

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

Again we will be assuming that little endian is used.

We find the following interesting sequence starting at byte 96:

For DG27 to DI07: 65 72 73 FC 95

For DI07 to DI18: D4 AF 0B B4 95

For DI18 to ****: 25 03 4E 06 95

For EB13 to EC05: B1 B9 A0 6C 95

The interesting thing here is that this sequence seems to be dependent on what the source version of the modem is

If you take the first 4 bytes and ignore the 95 byte and convert it to 32bit integers you get the following:

For DG27 to DI07: 1701999612

For DI07 to DI18: -726725708

For DI18 to ****: 620973574

For EB13 to EC05: 2981732460

Additionally we seem to have the following after this sequence:

2 bytes which for the same source version are somewhat in the same value range:

DI18 to DK28: 60 3E

DI18 to EB13: 6C 44

DI18 to EC05: 1E 43

EB13 to EC05: 39 1B

These two bytes as a little endian 16 bit integer:

DI18 to DK28: 24638

DI18 to EB13: 27716

DI18 to EC05: 7747

EB13 to EC05: 14619

Now after this we see something else interesting,.. 2 0's followed by 2 non-zero bytes. I'm going to take a wild guess here and say that they are likely a sequence of 32 bit integers. It seems unlikely they would put 0's in there just for the fun of it. So starting at byte 103:

1)

DI18 to DK28: 00 00 67 2C

DI18 to EB13: 00 00 43 2D

DI18 to EC05: 00 00 0F 31

EB13 to EC05: 00 00 0D 20

1 as little endian 32bit integer)

DI18 to DK28: 26412 (26412)

DI18 to EB13: 17197 (17197)

DI18 to EC05: 3889 (3889)

EB13 to EC05: 3360 (3360)

2)

DI18 to DK28: 00 00 06 1B

DI18 to EB13: 00 00 FA 1C

DI18 to EC05: 00 00 09 1F

EB13 to EC05: 00 00 47 0C

2 as little endian 32bit integer)

DI18 to DK28: 1563 (1563)

DI18 to EB13: 64028 (-1508)

DI18 to EC05: 2335 (2335)

EB13 to EC05: 18188 (18188)

The value range here is a bit large but nothing silly since 32bit values are likely to be used as offsets in larger files (such as modem.bin and related partition). If these are indeed 32bit values then it makes no sense for them to relate to the modem_delta.bin itself since the delta files are meant to be small so you would not need a 32bit range for the delta file itself.

3)

DI18 to DK28: 00 00 24 0C

DI18 to EB13: 00 00 96 0C

DI18 to EC05: 00 00 B7 0D

EB13 to EC05: 00 00 F8 05

3 as little endian 32bit integer)

DI18 to DK28: 9228 (9228)

DI18 to EB13: 38412 (-27124)

DI18 to EC05: 46861 (-18675)

EB13 to EC05: 63493 (-2043)

4)

DI18 to DK28: 00 00 7F 0B

DI18 to EB13: 00 00 E8 0B

DI18 to EC05: 00 00 E8 0D

EB13 to EC05: 00 00 DC 06

4 as little endian 32bit integer)

DI18 to DK28: 32523 (32523)

DI18 to EB13: 59403 (-6133)

DI18 to EC05: 59405 (-6131)

EB13 to EC05: 56326 (-9210)

Assuming a word size of 2 bytes instead of a double word for the conversion and taking into account signed integers I added the same hex values converted into signed word sized integers in brackets. Since this gives us negative values it adds the possibility of seek instructions or perhaps how many bytes are to be added or removed in this delta. Although possible I'll stick with my original theory of 32bit ints (DWORD)

5)

DI18 to DK28: 00 00 1B 15

DI18 to EB13: 00 00 2B 16

DI18 to EC05: 00 00 14 1A

EB13 to EC05: 00 00 61 09

5 as little endian 32bit integer)

DI18 to DK28: 6933

DI18 to EB13: 11030

DI18 to EC05: 5146

EB13 to EC05: 24841

After this we get the same sequence for all delta files irregardless of what the to and from versions are.

00 00 5D 00 00 20 00

Then you get 2 bytes followed by 8 0's remember we also saw a sequence of 8 0's at certain offsets within the files themselves.

DI18 to DK28: A4 7A = 42106

DI18 to EB13: B2 7E = 45694

DI18 to EC05: B5 8A = 46474

EB13 to EC05: 30 3F = 12351

File sizes of the delta files:

DG27 to DI07: 9216 bytes

DI07 to DI18: 4240 bytes

DI18 to DK28: 45832 bytes

DI18 to EB13: 48592 bytes

DI18 to EC05: 51560 bytes

EB13 to EC05: 24128 bytes

DI18 to DK28 and DI18 to EB13 have identical blocks here (excluding file & section headers):

- Offsets of match :

DI18 to DK28: 34394 -> 34832

DI18 to EB13: 36662 -> 37100

Length of matching block: 438

That is a pretty large matching block between delta files. Since the preceding byte sequence that also matches is also found in other delta files we can be pretty sure this is indeed a section header.

When matching DI18 to DK28 and DI18 to EC05 we find something else interesting. There is a pattern of values in both delta files at the exact same interval/offset in both files. The values in between these pattern values are different though. The pattern is too widespread to be a coincidence. The pattern values I suspect are some sort of meta-data. The pattern values occur at the exact same offsets in both these files for the length of the DI18->DK28 file. This pattern may just be random bytes who happen to have the same value at the same offset, but its worth investigating.

For DI18->DK28 & DI18->EC05 this matching sequence for the first 6 matches is:

C0

DA

C4

C0

1E

C8

As it turns out doing another match reveals a similar pattern but with different values:

DI18->DK28 & DI18->EB13:

8D

97

15

23

F1

FE

DI18->DK28 & DI18->EB13:

Start offset 139

8D, offset 451

97, offset 583, offset from with prev 132

15, offset 1045, offset from prev 462

23, offset 1154, offset from prev 109

F1, offset 1412, offset from prev 258

FE, offset 2098, offset from prev 686