digitalsecurity / imx-nand-tools Goto Github PK

from init_bch:

• This initialization can take some time, as lookup tables are built for fast
• encoding/decoding; make sure not to call this function from a time critical
• path. Usually, init_bch() should be called on module/driver init and
• free_bch() should be called to release memory on exit.

ecc_correct is calling init_bch for every page

in ecc_decode there's a try: block around .correct()

if i throw print(e) in except block i get: 'bchlib.BCH' object has no attribute 'correct'

As written throws an error in main():

--- a/imxtools/imx_nand_info.py
+++ b/imxtools/imx_nand_info.py
@@ -40,7 +40,7 @@ def main():

 # Override offset if provided
 if args.offset is not None:
     # Accept decimal and hexadecimal offset values

•    if args.offset.lower().startswidth('0x'):
  

•    if args.offset.lower().startswith('0x'):
         offset = int(args.offset, 16)
     else:
         offset = int(args.offset)
  

Hi
Great work found it very interesting!

I am currently working with a 512mb nand dump from an I.mx7, as expected the dump is greater that the nand advertised capacity.

According to the manual for the i.mx7 page 1207 "The FCB data structure is protected using a 62-bit ECC" and the info tool fails to find an FCB, kinda expected if it's encrypted, ecc referring to elyptic curve as opposed to error code correction. Hex editor text search also fails to find an FCB.

I can remove the oob, extract the ubi using binwalk and the images using ubireader but fail to extract files with similar error in your video.

The nand page diagrams are same as your presentation 2kb main and 64b consisting of 4 x 512 main with associated parity.

The fcb block has 1 x 32b metadata section, 8 x 128b data sections and 8 parity sections, if 62bit ecc is error code correction not encryption, 8 sections ÷ 62bit, doesn't go?

Knowing the above and knowing UBI is present in the dump, is there a away to analyse the dump to ascertain some FCB constructs, given the location of the UBI#'s in dump to enable the files to be extracted.

If 62bit protection ecc is encryption, I am assuming the ecc key is in the internal storage of the i.mx7 or at best the boot loader code on the nand!

I am hoping the developers have been lazy and used an "out the box" config :)

Time to dig deeper me thinks :)
Any hints/tips would be appreciated...
Regards
Robert

The default offset is often 4, but thatg is rejected as invalid. Suggested patch below.
diff --git a/imxtools/init.py b/imxtools/init.py
index 72330d5..eb1f711 100644
--- a/imxtools/init.py
+++ b/imxtools/init.py
@@ -198,7 +198,7 @@ def find_fcb_offset(content):
"""
try:
index = content.index(b'FCB ')

•    if (index > 4):
  

•    if (index >= 4):
         return (index-4)
     return -1
  

  except ValueError as exc:

Hi Damien,

Interesting and great work.

I manage to dump a Nand (MT29F1G08ABAEA WP) from a Computer-On-Module TX28-4130 from Karo Electronincs which is based on NXP i.MX287 chip. I used your tool imx-nand-info and it shows the following results below picture.

And then I used the nand-convert but it has errors and did not convert the file.

I’m not sure if its my installation of the tools issue or the tool is not compatible with my dump. I’m beginner in using Linux and wanted to start learning. Thanks.

Regards,
Derrick