Firmware Talk

[than3-bits]

I ran across your slideshow by chance (without the talk), so its unclear if this was addressed. If these were addressed verbally, please feel free to disregard this post and close the issue.

The process you outline only really works for NOR SPI interfaced memory. There is a growing number of cheap large managed-NAND chips that utilize flash translation layers for wear leveling in place of NOR SPI, and they are packaged using many of the same footprints.

As a result of the memory type differences, the dump you get from these may not actually be viable for bootstrapping recovery depending on the implementation (i.e. the dump may be larger than the chip size, or a number of other off-looking situations such as a pages being repeatedly copied multiple times to avoid an erase on the page, or non-standard MSR calls needed to alter service areas (i.e. corrective coding).

It may not immediately be clear this is the case if you cannot identify the chip or its various parameters (no markings, or available datasheets), and many people getting started in this don't make a distinction between NOR & NAND.

If you choose to do an update of this talk at sometime in the future, you may want to include something about the differences between NOR, NAND, and managed-NAND for firmware dumping. There's a Micron paper, and a number of good blogs related to DFIR with NAND if you haven't delved into this area. j-michel.org had a few posts (a post and a QA) that contained some useful background dated 2014.

Also, as feedback, it might be cool to briefly mention some common gotchas (like the Ch341a 1v8 adapter from amazon occasionally pulsing its data lines at 5v). Forming and relaying proper methodology to avoid needless damage is important.

Additionally, sometimes that SPI interface is in a really inconvenient place as well, where it may require multiple diss-assemblies/reassemblies to get to or debug; it would be a cool project idea if there was a way to add a connector extension to solve that issue without breaking or compromising the circuit. A lot of people aren't that confident in their electrical/radio knowledge to modify those type of circuits for fear of causing excessive EMI that might get someone in trouble, or damaging the equipment (from slow charge buildup, induction, or potential case/ground shorts).

[AkechiShiro]

Hi @than3-bits,

Thanks a lot for your feedback, as all the points were not addressed verbally, I'll try to improve on all these and also will see the j-michel.org posts to investigate more on NAND/NOR/managed-NAND, I wasn't aware fully well of all these details, and I do have a lot to improve and still a lot to learn on this field but the quality of information I found sometimes is scarce?

I'm not sure if you're referring to this, partly ? : https://youtu.be/jVKl3GuazEs?si=beRh1Hydo4lsnq1Z&t=1693

I think this is the blog post : https://www.j-michel.org/blog/2014/05/27/from-nand-chip-to-files

If you also know the links to the answer question blog post, if not I'll try to have a look at all of them, there is a lot of interesting information that I need to read through.

I was told by someone knowledgeable that there were differences but the talk seemed to have a lot of information and seemed technical enough for where I gave it, I wasn't presenting it at a very technical conference.

I heard about the gotchas of CH341A but I've never used one due to their bad reputation for dumping firmware.

It is also true that SPI interface can be in a really inconvenient place, where probing seems barely possible/impossible and it is necessary to desolder/resolder and there are probably risk of damaging, yes, I haven't touched upon this, designing a connector extension to solve that issue would be the best solution.

About the EMI, I think that I need to do more investigation on this subject as some components/boards are more sensible than others, but I haven't had any bad experience yet, but I try to be careful about that, everytime I'm touching a board.