Hi

I'm toying around with this TSOP48-chip salvaged from my daughter's dead Android-tablet, just for the sake of practising. I've been following all documentation I can find, all videos I can find, and I think I've got a grasp of what to look for when describing the internal structure.

However, this particular chip seems like a dead-end for me, and I'm thinking it might be broken.

See image 1:


There's a lot of patterns and the variations look good. I'm scrolling rightwards to find the vertical lines, presumably the SA. I find it at offset 1024:



However, the lines are plain straight, no variation at all. According to the docs, atleast LNB should be variant since it's not the same for all pages. So, something is fishy here.

Also, from offset 1161 and all the way to the end (4319) there's no data at all; plain gray:



I've retried dumping the chip in full two times, but the gray area appears everytime.

So, questions:

1. Am I searching for the SA at the wrong place?
2. Is the chip partially dead?

Firmware chips usually are a bit different than NAND Flash used for storage as in a Flash Drive. The filesystem could be quite different, the chip itself might keep track of what part of the NAND to access such as the OS routines, programs and different storage areas / partitions etc. you might find part of the dump holds a FAT filesystem say for storing pictures (think DCIM) or it may use a Linux filesystem.

It looks like your chip was dumped correctly, and also it looks like it was a very good dump. Looking down the vertical lines in the second picture there are no random bits showing that would mean bit errors. If you open the dump in a hex editor, do you see any ascii strings? Most firmware chips will have areas where files are stored one after the other making up the underlying OS.

To be clearer, I don't suspect you will be able to put the dump back to a disk image of FAT... and this is the goal when parsing LBN, LPN etc.

I would suggest an older flash drive with controller such as PS2251-50-F or SM3257EN Q AA   

It seems you are correct. When I did a search for string "FAT" and "Android", the cursor landed in the area below my previous dumps. And if I scroll this area very far to the right, I find this:



And there are those vertical areas I was looking for earlier. Interesting.

You say "firmware chips". Does this mean a flash like this one contains a mix of non-filesystem data and filesystem-data in the very same chip? While the other ones are pure filesystem-chips?

As I see page structure (geometry) is like this: data area 4x1024 bytes + 4x(SA with ECC), SA have 4 bytes probably, ECC you need check. It could be also Data area 8x512, it is easy to check. If SA/ECC part has 4 repeat DA is 1024, if 8 - 512. We can also see LBN at first SA part, and LPN in second.

_________________
Flash Killer - everyday new resources (pinout, XOR, ECC,config) for flash devices

@arvika: Can you tell me how you see LBN in first and LPN in second?

Upload the case to www.wetransfer.com and drop a link.
Will have a look and post explanation here.

_________________
VISUAL NAND RECONSTRUCTOR. Since 2014.

That site was very slow so I put it on my own server instead.

Here's the case + dump (872MB): http://www.ribit.se/files/tmp/VNR/Tommies.rar

Please attach high-res pictures of PCB from both sides, need to know controller model too.

_________________
VISUAL NAND RECONSTRUCTOR. Since 2014.

This is roughly how I see it. Yes depends on the device, but many IOT devices will have firmware on nand chips, some will have emmc chips with different partitions, some will have both. If there is only one processor chip that is not a MCP, but proper CPU and one memory chip it is probably all on the one chip.

@sasha: Here are photos of the board. I have unfortunately only a phone camera accessible right now (potato quality), but I hope it works.

It's OK, do you know by chance model of tablet for the record?

https://we.tl/lVFKAp0Htl
Here's a case files with solution, replace yours, open it and:

1. Physical image element - replace path to file to your dump
2. BCH element - turn power ON
3. Markers table element - open table (top toolbar) find the button OPEN at the left top corner and load markers table 0.xml, then go back to workspace.
4. Markers table element - click red button CREATE LOGICAL IMAGE.
5. Logical image element - open file system viewer from the toolbar

Now you got access to file system and files of 3Gb userdata partition

P.S. There are multiple partitions on device since it's Android, but there's no MBR/GPT looks like partition layout is stored as fixed offsets somewhere in the bootrom (don't want to dig that deep now, it's Sunday evening ).

_________________
VISUAL NAND RECONSTRUCTOR. Since 2014.

ALLWINNER A10-EVB-V1-2 REV 1.0 SCH:
https://elektrotanya.com/allwinner_a10-evb-v1-2_rev_1.0_sch.pdf/download.html

Wait for "Get Manual" to appear, then click on it.

_________________
A backup a day keeps DR away.

Played around a bit more and realized that I actually retrieved extSD card partition, not a /data one.
Just did rebuild of most partitions including /system, /cache, and /data one and found a partition layout scheme (weird one, never seen before).
Explanation will take a time...a bit nonstandard things..will try to add some info here within this week.

Got a model name, it is Softwinner EVB Crane V13.

Using VNR's Android data extractor was able to retrieve all contacts and that's basically it because device had no GSM module as far as I understand.
If you need contacts let me know.

_________________
VISUAL NAND RECONSTRUCTOR. Since 2014.

Amazing.

I haven't had the time yet to peek your case files more than downloading them, but I'm very eager to do so and see how things are done.

The tablet was fully backed up prior it died so no data is needed from it.

This just struck me: you asked for controller model, and fzabkar provided the datasheet. What info/clues does the datasheet (or knowing what controller it is) provide?

In your case I see you added both BCH (which I'm not yet sure what it is) and Pair elements. What info does the datasheet provide, letting me know when I need to use Pair, Xor, Invert, etc?

The controller model provides clues gained from prior experience. So if it was a Phison PS2251-07-V then we would know to try certain XORs, would be able to guess at likely layouts / ECC etc. Simply because we have worked with that model before.. or can further reverse the target because we know roughly what it might look like. It would be extremely rare (I have never seen it) for a datasheet to provide any of the info you mention. XOR is found by the methods dhown on Rusolut case studies, not by any data sheets. ECC and BCH I don't know, but smarter people like Sasha and Arvika can.

When the engineers are making this stuff, even they do not use most of it. We are Reverse Engineering what the controller does. The flash vendors are provided tools and firmwares from Phison for example, and the MP Tools handle some of it, but the pairing XOR, join by byte etc etc are handled by probably hardware modules in the CPU of the controller, or firmware.

I have reverse engineered to some degree some firmwares from USB flash drives based around 8 bit 8051 processors and it wasn't helpful. There is not a lot going on in these CPUs.

Individually, flash is fairly hard, once you see the solution it looks easy.. But made compoundedly harder because nearly every device is different. When a lot of people say VNR is hard, really it isn't VNR at all but the Flash itself.

Great input. Thanks HaQue.

Apparently this device was a tough one for starters. I have two pen-drives at home (one with 1 chip, one with 2 chips). I also have a really old one (128MB I think). I will scrap all these just for the sake of learning.

Since flash is so complex I surmise I have to set really low and short goals at a start, and eventually increase the challenge. I've got a big box filled with dead devices (SSD, smartphones, tablets, etc) in my workshop that's been donated by my customers and that's been untouched for years until the day I invested in VNR. And that day has come, so now everything is up to me.

Sasha provided some great Youtube-links to VNR-users' videos, these will add up for a good reference manual.

I haven't been this eager to learn new things since I was pre-teen (I'm past 40 now), and I tell you; it's great. I feel alive again.

Now I finally got some time to investigate, but as soon as I open your case VNR hangs. I cannot click anything anywhere in the GUI, not even "minimize" or the top-right cross to close the program. Everything is 100% unresponsive.

If I hard kill the process using task manager, restart and open my own case, it works. But if I open your case, it hangs again. Also, if I open my own case and try to quit the program, the GUI becomes unresponsive as in your case.

Oops I sent you case file made by my beta version, looks like that's the reason.
Will redo it in a while

_________________
VISUAL NAND RECONSTRUCTOR. Since 2014.

Reuploaded, try this one:
https://we.tl/6CaFOikX99
Unpack and rewrite case file in case folder.

_________________
VISUAL NAND RECONSTRUCTOR. Since 2014.