search

t0x0 / random

Random projects
MIT License
92 stars 47 forks source link

Use of CurrentBlockDataEntry.dwBlockCount #7

Open tristanleboss opened 8 years ago

tristanleboss commented 8 years ago

Hello,

I have a question about your ffutoimg python script.

I don’t understand line 104, when you seek at the location where to copy the data in the final image:

imgfp.seek(CurrentBlockDataEntry.dwBlockCount*FFUStoreHeader.dwBlockSizeInBytes)

Indeed, you use “CurrentBlockDataEntry.dwBlockCount” but, I tried with a FFU (Xiaomi Mi4) and this value is always 0 or 1. Because “FFUStoreHeader.dwBlockSizeInBytes” is always the same, the final value is always the same.

Shouldn't we use “CurrentBlockDataEntry.dwBlockIndex” instead?

t0x0 commented 8 years ago

Yes, you're correct - according to the documentation, dwBlockIndex should be used. However, on the RPi FFU file, that was unsuccessful and I had to use dwBlockCount. I intend to review this issue and determine why the RPi FFU is different than the others, or if I made a mistake somewhere else.

tristanleboss commented 8 years ago

I figured that out: your script doesn't take in consideration _BLOCK_DATA_ENTRY->dwLocationCount. This allows a block from the FFU to be copied at different location. On mobile phones' FFU, it's mainly used for the GPT which has to be at the begining of the disk and also at the end as a backup.

Indeed, initially, you should read 32 bytes:

4 for dwLocationCount 4 for dwBlockCount 4 for dwDiskAccessMethod 4 for dwBlockIndex

But, if dwLocationCount is different than 1, you need to read (dwLocationCount - 1) * 8 bytes. Indeed, you need to re-read for each additional location:

4 for dwDiskAccessMethod 4 for dwBlockIndex

For each location:

source = ImagePayloadStartOffset + _BLOCK_DATA_ENTRY->BlockCount * _STORE_HEADER->dwBlockSizeInBytes destination = _BLOCK_DATA_ENTRY->_DISK_LOCATION->dwBlockIndex * _STORE_HEADER->dwBlockSizeInBytes