When you say "keep trying wire combos", do you mean that you physically rewire the pads up to 24 times? ISTM that varying the line-to-bit assignments ought to be done in the software.

In fact why does the user need to experiment at all? AISI, most of the pinout discovery for Data bits 0-7 could be automated within the software by trying up to 28 combinations of 2 bits. This corresponds to the total number of different ways in which the READ ID command (90h / 00h) could be wired.

_________________
A backup a day keeps DR away.

@fzabkar: Assuming that you get real ID from your reader as ID 86 84 24 5F then this fact add 90h filtering to this operation

LINE: 0 -> DATA: 1,DATA: 2,DATA: 6
LINE: 1 -> DATA: 0
LINE: 2 -> DATA: 3
LINE: 3 -> DATA: 1,DATA: 2,DATA: 6
LINE: 4 -> DATA: 4
LINE: 5 -> DATA: 5
LINE: 6 -> DATA: 1,DATA: 2,DATA: 6
LINE: 7 -> DATA: 7

It's becouse we know that 90h is in fact real HEX 0x90 since chip answer in reader for this command.

@HaQue: We are using in fact LINE - we are using LA Board where we solder to each Login Analyzer input line a wire from pad..... .maybe in this only theoretical sample we working on HEX but in real case we connect to each input of LA diffrent DATA so after you solder to LINE1 to unknown DATA after decoder you can get "Your LINE 1 is DATA 6"

_________________
Best regards,
Boguslaw Rzepka,
Multi-COM Ltd., Poland

Why not ...

LINE: 4 -> DATA: 4, DATA: 7
LINE: 7 -> DATA: 7, DATA: 4

_________________
A backup a day keeps DR away.

I understand your point. If we will use own Reader this can be done as you write by issuing Commands to "catch" correct one... something like Bruteforce but we are not making new hardware. Idea is to use existing hardware as VNR, PC3K, NR + LA without need to buy additional tools . It will be software decoder. In such cae user will need change FF cable from GoldPin without need to resolder anything if he is connected to board like this:





Becouse Line4 in this is unique if we will use 90h. Let's look to this case without 90h filter - you will got 3 options



adding 90h command (in this fact reader answer so 90h=90h) filter results to give 100% match at LINE4 and 100% match at LINE7



In this particular case (Intel) once you got like this you can run any ONFI reader and decode correct lines from there to give correct ONFI answers.....

_________________
Best regards,
Boguslaw Rzepka,
Multi-COM Ltd., Poland

Wow. So all these expensive tools expect the user to find data bits 4 and 7 by repetitively rewiring his jig until he gets some kind of flash ID? Then the user has to manually decode this ID and rewire his jig again until he gets the right output?

ISTM that all the pinout discovery and rewiring could be done in software within a second. Brute forcing bits 4 and 7 would require only 28 iterations at most. Finding the remaining 6 bits should be easy, as your online decoder tool demonstrates.

The data could then be dumped by passing each byte through a software "transform".

BTW, I'm assuming that there is no instance where the wrong command would have data destructive consequences.

_________________
A backup a day keeps DR away.

depending on the software. FE for example does not have this function available. I don't know about the others. I would be making an intermediate board where I could just swap jumpers, and really would not take more than an hour at most. This kind of case is very rare.

I see your point about the software but the focus is on other things. really is a LOT in flash to consider, I guess problems will be worked on and software solutions created as they are needed. LA pinout discovery is not (publicly) talked about much at all.

Thanks guys, this brings me to a related question: I would like to buy a flash reader (PC3K flash, FE, ...), but I would like to develop algorithms like pinout discovery on top of it. Until now those commercial tools seemed to be too closed so that I could only use them as a tool, but not enhance them or build my own tools on top of them. So I thought that I would likely have to develop my own flash reader instead to be able to develop my own algorithms with it. So is there any flash reader on the market with an SDK, an API or a documented driver interface that I could develop my own software against?

no & yes, the chips are multipurpose just like everything else.. there are plenty of cpu/controller/asic/fpga dev/proto boards that have the ability, and some have some rudimentary source code. even a USB interface chip can do it. The part would be to learn using data sheets how to read memory at a base level using command/clock/data signals.

be warned, there are many different chips with varying read methods. More being reversed each week. There are a few parts to this, each with their own characteristics to make your life difficult. each also not really dependent on each other, or even closely related to each other.

breaking it down into some kind of set of challenges:

- pinout discovery. this wont help you with anything but reading to a dump, even then you might need more..

- reading criteria. things like voltage levels, extra VCC pads, speed of reading, commands to read or "setup" commands, knowing page sizes, if blocks are masked..

-page, block geometry, ecc, sector/page updates, bad columns, cut pages/blocks/crystals, chips with 2 different crystals (196GB chips for example)

- wear levelling, whitening, XOR, proprietry schemes

IMHO you could make a quicker impact by helping an existing team such as Rusolut who have some of the best people dev'ing flash, instead of spending what will be years developing to get only to where they are now (best case).

If you think this is just a case of developing some algorithms, then I believe it is grossly underestimated whats involved.

I say this with the utmost respect for your vision, but also experience in the complex nature of flash in general.

Why make yet another reader where you will need to be adding support for each chip constantly? You would need to collect 100's of devices as having the device and dumping, and working on your is really the only way you can add support to your tool for said device.

remember, on the outside a flash drive looks the same, on the inside you don't know what it is. even the exact same PCB, NAND and Controller can have wildly different data structures. Case in point the verbatim store-n-go which has been selling for years. without exaggeration, 100's of different internal configs


if anyone thinks I am exaggerating the complexity, and task of a single person creating a meaningful flash tool.. I would love to debate it.

BTW, I had this exact vision a few years ago.

FT2232H NAND flash reader:
http://spritesmods.com/?f=had&art=ftdinand

libFTDI - FTDI USB driver with bitbang mode:
https://www.intra2net.com/en/developer/libftdi/

_________________
A backup a day keeps DR away.

someone has been working on improvements to Jeroens work and created this: https://github.com/bkerler/NANDReader_FTDI, Though I class this as abandoned.

I still think working with an existing team would be quite benificial

Bit-banging a TSOP-48 NAND Flash with the RPi:
https://www.raspberrypi.org/forums/viewtopic.php?t=16775

_________________
A backup a day keeps DR away.

The code there is terrible, some fixes are at https://github.com/skypiece/rpi-tsop48-nand/blob/master/rpi-raw-nand-v3.c

I would rather use a better device, along the same Idea as https://www.xilinx.com/support/documentation/application_notes/xapp354.pdf, but not as old from 2002! and a FPGA, not a CPLD (internal memory constraints)

if you google around you may hit some source code https://www.latticesemi.com/en/Products/DesignSoftwareAndIP/IntellectualProperty/ReferenceDesigns/ReferenceDesign04/NANDFlashController

but I still think it a monumental task

Are you referring to programming an FPGA or CPLD?

Otherwise, reading the flash using an Arduino or Rasperry Pi should be straightforward, but assembling the data would be a monumental task. Also, the problem with bitbanging is that it is software intensive and consequently very slow.

ISTM that, if pinout discovery requires 1 hour of labour, then it would be worthwhile automating the procedure with a cheap tool.

_________________
A backup a day keeps DR away.

No, I am talking about producing a new tool that can read flash comparable, but with "better" features than what is already provided by the 3 main vendors (I am dismissing Flash Doctor by Salvation Data for obvious reasons)

if you pick a certain flash part, and concentrate on that one, and develop your tool for that one... then yes you could probably knock something up, but the subsequent adding support for other chips, testing etc would blow out time and money significantly. Regardless of what ONFI tried to do, there is no standard config that will read NAND chips

US$83

https://www.ebay.com/itm/ProMan-Professional-programmer-repair-tool-copy-NAND-FLASH-chip-data-recovery/221826359924

_________________
A backup a day keeps DR away.

Depends what you want to do, if your looking for an API, SoftCenter IMHO is the best but I'm bias. I use it frequently for reverse engineering NAND and developing custom tools.
My only gripe with SS is that it's timings aren't as flexible as I'd like, some chips are VERY strict when it comes to timings and SS doesn't handle them well.
If your looking to build one up from scratch, FPGA is the way to go, forget about bit banging..

_________________
Recover My Flash Drive

I have created a seperate thread in the Research/Development section now, since researching flash readers got a bit too offtopic: https://forum.hddguru.com/viewtopic.php?f=13&t=38911