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:

Attachment:

bitmap0.png [ 276.13 KiB | Viewed 6888 times ]

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:

Attachment:

bitmap1.png [ 258.92 KiB | Viewed 6888 times ]

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:

Attachment:

bitmap2.png [ 96.17 KiB | Viewed 6888 times ]

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

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.

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.

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 ).

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.

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.

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.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum