l_oliveira, I had a 7371 nand dump (identically dumped more than twice) that ibuild refused with:
ERROR: Data in block 785, page 0, plane 0 is corrupted.
ERROR: Unhandled exception.
Means that dump has became corrupted at the mentioned block. ibuild detect that by checkling for mismatching sector contents data with the ECC.
I got ibuild to accept it by opening it in 360 Flash Dump Tool v0.94, going to the config editor,
clicking edit config, then without making any changes clicking save config and saving it with a
different name. The new "copy" extracted fine with ibuild. Maybe others with this type of error
could try this as a "fix" unless I'm overlooking a noobvious reason not to?
What you did was make the program regenerate new ECC data for the dump.
Is it a fix ? For making the corrupted dump itself usable, no.
For a attempt on making files within the dump extractable, yes. Go for it.
I did notice something though, when I compared the files that ibuild extracts to the Flash
Tool v0.94 freeBOOT friendly versions of the files, I see that ibuild provides the encrypted version
of odd.bin, while Flash Tool (in the freeBOOT/data folder) gives us the decrypted one. Does it not
matter since the first 16 bytes of odd_enc.bin and odd_dec.bin are the same?
All files dumped by ibuild will be in their decrypted form. XEX files will be still encrypted with the normal XEX encryption, though.
Security files will be plain text (fully decrypted).
If files are appearing in a way they look like encrypted, they are in fact corrupted and the CPU key is incorrect.
Which version (enc or dec) should we really be using for freeboot, or does it not matter?
If you use flashtool to extract an SMC from XBR or XELL image, take the smc_dec.bin file, rename it to smc.bin and toss on the data folder of the 9199 build directory.
Again, all files being used with ibuild should be on their decrypted form.
P.S. Sorry for the long post