Binary Pull

[lospheris]

I have a raw binary pull of one of the flash chips, if that would be helpful for your project.

[lanmarc77]

Hi, I would really like to take a look at it. How was it extracted? Wiring madness?

[lospheris]

I pulled it with a XGecu T48, and the accompanying NAND adapter. The NAND that's on there is actually 8 bit so It's not too bad. The adapter I used has a ZIF socket, so I used my hot air rework station to get it off, then put it in the ZIF socket. I can see what I believe is the firmware start but binwalk isn't recognizing the filesystems anywhere, which is a bit weird I feel like.

What's the best way to get it to you?

[lanmarc77]

Ah I see. Thanks for the effort. If binwalk can not find a file system it might very well be that the firmware is not simply storing the data as bare fat32 but makes some translations. Might be encryption (unlikely) or some additional data frames to take care of bad sectors. I have some documents here from the SDK of the SOC that might shed some light.

I suggest using any one click hoster and add encryption. My public key is attached. LanMarc77PubKey.txt You can encrypt the file with the following command: gpg --encrypt --recipient-file LanMarc77PubKey.txt --output encrypted-file.gpg < plainfile.zip

[lospheris]

Here is the link: https://dropmefiles.com/OKMpc

SHA256 e71d2a84352cfdbe1e2ee77e28fd715d54630d65765f8f26b0b386171d501300 playaway.gpg

[lanmarc77]

Got it. It will take me a while to check what I can figure out. But thank you again. Might I ask what type of Playaway this was? An old segment model or the modern Playaway Light with the graphics screen?

[lospheris]

It's a newer model with the graphics screen.

[lanmarc77]

Findings at first glance: I stripped away the 64bytes spare to get a pure data image. The following addresses are based on this stripped away image. The start of the flash corresponds with what the datasheet states is needed for the processor to operate. I can find NCBs, LBLDs and DBBTs. Starting 0x2C0000 I can see the first boot image. Its length is 0x3C0000 bytes. Followed at 0x680000 by the second (identical) boot image with the same size, followed at 0xA40000 by the third (identical) boot image. I can only speculate why there are three identical images but this layout corresponds what I have read out using the SCSI tools. My assumption is that this is some kind of OTA/rollback feature. One factory default, on currently working image, one to keep the version from before. As this device has probably never made use of this all three sections have identical content. Now the interesting puzzling part. At 0xE00000 a structure appears with identifier pamxsyhp and a size of 2k a lot of unused space and then followed by 34 structures also 2k each but ID pamxenoz. Reverse the identifiers... and: physxmap and zonexmap. This is most likely a mapping from logic sectors that the OS via USB sees and physical sectors of the flash. I could also find an MBR at 0xDCE1000 followed by a FAT32 FSINFO block. But the data is all over the place because the (yet) unclear mapping and is most likely the reason binwalk could not find the FAT32 partition. It might very well be that this mapping also implements wear levelling features.

[lospheris]

I stripped the 64 bytes off the pages myself and see the structure you're talking about. Binwalk still gives unreliable results (I hadn't stripped the excess bytes when I sent it) so I think what you said about the FAT32 Makes sense. I'm also seeing those 3 firmware copies. I think OTA/Rollback is the most reasonable answer for what's going on there. I can't think of why else that would be.

Good catch on the physxmap, and xonezmap. I guess the 2K sizes do make sense considering that's a page size, and they didn't seem to be hurting for space.

[lanmarc77]

Did you take an image via USB? This would help to cross reference physical and logical sectors.

[lospheris]

I didn't, but I can solder it back in and see about grabbing a capture from there too.

[lanmarc77]

If it is not too much to ask, then I would really appreciate if you could do this. You would then need to solder a USB connection as shown in the repo readme. Once connected to the PC the player should register as mass storage device. Ideally you do not mount it but just take a dd image from the bare device as this might not change any metadata of the file system structure. Thank you very much.

[lospheris]

Alright, I'll have to grab both from USB and a bare binary pull from my second one because I bricked the one I've been working on somewhere along the way. I probably botched it while soldering.

[lanmarc77]

Collateral damage in research like this is almost impossible to avoid. At least the devices are cheap to get. Important is that I get a fitting dump of the file system and the flash content otherwise I can not compare the sector numbers.

[lospheris]

yeah! It happens, luckily they aren't too expensive but I think I got what you need. It is a different book though.

https://dropmefiles.com/Cm1Cl 79cc752edaa50eb1290de578332fb0a95d546fec0c2e3f462988ec18ea143ed1 playaway.gpg

[lanmarc77]

Got it. Yes this is what I needed. Thank you.

[lanmarc77]

I got a huge step forward. There was an issue that I am still unsure why. I understood the maps and how they hold physical and logical sectors. Still the issue is with the spare sectors. It was indeed very good that you have not removed them. Usually there are 16bytes every 512bytes or 64bytes every 2048bytes. Your dumps contain 9bytes for three 512bytes and then the missing 37bytes for the last 512bytes of the page. Additionally there is vital information in the spare bytes. Specifically a correction of the order of a set of 64 pages. E.g. in your second dump the partition start is in the dump placed before the MBR. The MBR must come first. But the spare data has some kind of ID and a counter that shows that these pages should be reversed.

Is this something that might come from the way your program might save the dump?

[lospheris]

I don't think so. I'll check though. The software my reader uses is xgPro and I haven't had trouble with it before. The opensource alternative currently doesn't support nand so it's pretty much what I've got haha.

[lospheris]

Something pretty weird is happening. The chip is reading as mostly blank now. I did two pulls when I pulled the one I gave you. Both CRCs and SHA256s matched, but now it's blank around byte 0x825. That being said, I don't see any options that could be causing the behavior you're seeing. Are the blocks you're seeing out of order the same between the two images?

Since I have a pull now, I might write it back to the chip and solder it back in to see if it works.

[lanmarc77]

I attach pictures of enders game dump. In red the identified spare areas. It is very good to see with the FAT entries as the values supposed to be counting up and thanks to the USB dump could be verified. Part of the spare area (sometimes) an identifier value of a page set of 64 pages (purple) and a page order number within set set (blue).

Here is an example of where the sorting marked via the spare areas is vital: And the very next page which actually should come first:

but it does not come first by the order within the dump. But if you look at the blue values you can see it is supposed to be reorderd. Maybe you can open that dump in the editor of that program and check if within that editor if it does get reordered or not. My current thoughts are that this is the programs behaviour. And as long as the program takes care of the translation and you only work with that program you would not notice anything.

[lospheris]

The hex editor is not the highlight of the software unfortunately, but I was able to find the entry near 0x06d51050. Here is a screenshot, and unfortunately, it looks like the data in Xgpro looks the same as you see, and I see in imhex.

[lanmarc77]

Ok. Then we take this for the truth then. As I understood how to deal with this I will write my helper scripts accordingly and will document this state.

[lospheris]

We might be able to double check if you get the scripts worked out. If we could use your scripts to get the data so it's mountable in linux, add or remove some files, run in through a script to put in back in the original format, write it back to the nand, and I'll solder it back in to see if the new files are there in USB. It's a bit cumbersome but it might tell is if it's the software or if it really is that way.

[lanmarc77]

I think this would at least verify if we understood the 3x9+37 bytes and their meaning. If they really exists on the nand chip in this order and with this content is then still unclear as we use the same program (and programmer) to program the chip which could transparently remove or change them. I must admit I would find that very unexpected though if a program is that sneaky. To really verify we would need a different programmer from a different company with a different program for readout. This would convince me.

[lanmarc77]

More insights. The flash layout dump is ok. I found in the chapter of the hardware ECC of the STMP processor a description how the layout has to be for the hardware ECC to work correctly: This shows the layout I figured out by looking at the raw data. So your program and programmer do not seem to make any adjustments to the data.

[lanmarc77]

I just uploaded my documentation and the helper scripts here: https://github.com/lanmarc77/playaway/tree/main/flashdumptools

[lospheris]

Were you able to mount the image after you extracted it? It will mount the image as a MBR partitioned drive but the filesystem itself won't mount.

[lanmarc77]

I used the following command to create a loop device of the bare image: losetup -r -P -f -b 2048 H27U1G8F2B@TSOP48_enders_game.bin.filesystem -r read only -P scan the file and create a device for any partition found -f find the next free loop device -b blocksize of the image file

Then I could mount the filesystem from /dev/loop0p1 which was created from the partition scan. Most important in that command is the block size which is 2048. Most SD cards and SSD have 512.

[lospheris]

I wasn't doing the -b 2048 which I should have been, that's totally my bad. However, it still didn't mount for me. I tried mounting with a couple different options for -t, and even just leaving it blank to let mount try to figure it out. I can mount other fat16 partitions from another project but this one keeps giving the following error.

I'll mess around with it some more and see if I can figure out what's up. I'm not amazing with FAT16, or honestly any directly manipulation of filesystems but I'll look into it and see what I might be doing wrong. Interestingly though, the first 1536 bytes of p1 are showing up blank for me. I'm not sure if that's normal but it struck me as a bit strange.

[lanmarc77]

Ok. No problems on my side. Ender is FAT16 and Dorothy FAT32. Can you post the output of extractFileSystem.pl? If you used the same flash dumps for extraction that you sent me the following sha values should come out of it:

1010eff158da216a05e935f79bb44c02f47a6853c5c17fc0a7cb8cebeba879a6  H27U1G8F2B@TSOP48_enders_game.bin.filesystem
64ab756af75e2bafa27d93d41aacf6d537c91e5ea39133e5b386ac7d65590df3  H27U2G8F2C@TSOP48_playaway_dorothy_must_die.BIN.filesystem

[lospheris]

The sha values map but my linux vm summarily refuses to mount them. It's clear it something on my end, so I'll have to figure it.

[lanmarc77]

It might be that the partition scan did not work correctly. You can use a manual method to skip the MBR and create the loop device directly. The following should work:

losetup -b 2048 -o 2048 /dev/loop0 H27U1G8F2B@TSOP48_enders_game.bin.filesystem

-o the offset in bytes from where after the loop device will start

And then directly mount /dev/loop.

[lospheris]

I got it working with a similar command earlier this evening. Interestingly, your comment about the MBR was right on the money. Here is what it looks like when I map the entire image to a loop device.

Here is what it looks like when I map just the fat16 partition.

I haven't had a chance to dig down into the MBR but it's making me think that something might be up in the MBR somewhere, or that something is up on my VM.

[lanmarc77]

Mhm..my two cents to this would be to check how the MBR is actually using CHS vs. LBA addressing. If I remember it right it was in the old days that the remaining first cylinder was supposed to be reserved so that the first partition starts with the second cylinder. This is really ancient but could explain the mounting behaviour. It might work on my Linux as my software might be more recent and be able to handle this differently.