[nocash]

Just found the CID (the eMMC/NAND chip id which is used as "dsi console id", needed for eMMC decryption). It's stored in Main RAM at 2FFD7BCh, and it's in reversed byte order, ie. the "APF00M" string is stored as "M00FPA". It appears to be only 120bit (without the crc7 byte), followed by a 00h-byte (or maybe it's just a garbage byte). Ie. it looks like this:

dd ss ss ss ss 03 4D 30 30 46 50 41 00 00 15 00

with dd/ss being date and serial number. It can be dumped even with exploits like cooking coach (which doesn't allow to access the eMMC I/O ports, and thus doesn't allow to read the CID directly from hardware - but reading it from Main RAM works).

Computing SHA1 on the CID should allow to initialize the AES_CTR for eMMC decryption. Of course, the AES_KEY values are still unknown. But after all, it's a step towards working decryption without needing main memory hacks, and even without needing irc or icq or what that hacker-space is called.

The eMMC boot sectors are encrypted differently, so it might turn out that the decrypted partitions don't contain any useful stuff for the understanding the DSi's boot process. Anyways, I would be glad just to know if the partitions are useful or not.

 

[nocash]

Here's some test program. It's showing two pages, containing the first & second half of the AES register region (with IV value and keyslot values). That memory is usually read-only, but it's fully write-able (including for allowing 8bit STRB writes), which is almost as good as read-access (ie. one can change single bytes to values 00h..FFh, and check which of those values is producing same results as the original unchanged value).

The screenshot shows the second test page, running with Cooking Coach exploit:

Unfortunately, most of the keyslots are destroyed (overwritten by 32bit ARM opcodes), which has been more or less expected for games that aren't "requesting" the keyslots to left intact via flags in cartridge header.

The interesting bytes for eMMC decryption would be those at the bottom of the 2nd page (040044E0h..040044FFh). It's quite possible that the Sudoku DSiware exploit did have eMMC access (and would thus allow to view the eMMC keyslots).

Aside from the AES values, the bottom 3 lines are showing some I2C registers:
BPTWL is the LED controller
CAM(78) is one of the Aptina cameras
CAM(A0) is one of what is assumed to be alternate cameras from unknown manufacturer
Would be interesting if anybody finds a DSi that shows I2C values different as in the screenshot!

 

[emuNandroid]

Unfortunatly, this test program just hangs with a top black and bottom white screen on boot. Maybe binaries need to follow the devkitpro format? (ie https://github.com/devkitPro/nds-hb-menu ) Standard binaries purposefully don't work in SudokuHax (anti-piracy)

I also can't answer your PMs for some reason. (same with you jimmsu if you're reading - check no-intro forums)

 

[nocash]

I also can't access https sites with my computer. Dunno how devkitpro binaries (or sudokuhax binaries) differ from standard binaries. The top black and bottom white screen sounds as if the ARM9 code was started okay, and as if it would hang on ARM7 side before getting any text displayed, uninitialized usr/svc stack maybe?
If you want to, you could try to edit the included source code (and assemble it via no$gba Utility menu). Or, can you start "dslink.nds" via sudokuhax? If yes, then you might be able to wifi-upload aes-test.dsi via "dslink.exe".

 

[nocash]

Here's a screenshot from somebody running the test with sudokuhax. It does have something in keyslot 3, but that values don't seem to allow eMMC decryption (unless I was doing something wrong).

And the decryption myth claims that the last two words of Key3_Y should be set to 202DDD1Dh & E1A00005h, which doesn't match up with the screenshot (of course, that could explain why one needs to set that words manually, doing so doesn't help though).

This guy http://hackmii.com/2011/08/final-dsiwarehax/#comment-7672 claimed that
"My dev.kp/syscerts dumper app is rather unreliable on Sudokuhax
v1.0 for whatever reason,(works fine on v1.1)"
and that would suggest that sudokuhax has everything needed for filesystem decryption.

But from my current tests, the sudoku keyslot doesn't seem to work for eMMC decryption. Or are there different ways for using sudokuhax? Like booting it from eMMC with eMMC keys available, and booting it from SD card without eMMC keys available?

 

[Normmatt]

Thats because keyslot3 was corrupted by sudokuhax to prevent people from decrypting their nands. Those two words should be 202DDD1Dh & E1A00005h. The initial ctr is the sha1 of the nand cid.

Heres my results:

 

[nocash]

Thats because keyslot3 was corrupted by sudokuhax to prevent people from decrypting their nands.

The DSi hackers are doing anti-hacking hacks? Sweet. After all, we don't want other people to hack their consoles. Or people spreading copies of their Health and Safety information all over internet.

Heres my results...

Ah, okay, then it looks easy.
40044E0h-40044EFh is another unique per-console value.
40044F0h-40044FFh is same on all consoles.

For that 40044E0h-40044EFh value, the middle 8 bytes are quite apparently same as the first four & last four bytes, XORed with some constant. So one would only need to know the first four & last four bytes. The values in the 2nd screenshot are resembling what was reported to be found in Port 4004D00h-4004D07h (18 .. A2 08). Maybe that is that PROM with console ID that the dsibrew people were talking about.

Do you see a copy of that first & last four bytes anywhere in RAM (like at 2FFxxxxh maybe)? Or do you see any of that bytes resembling your other ID values (the TEF barcode, the MAC address, the Nintendo WFC ID, or the eMMC CID)? Or does sudokuhax allow you to read Port 4004D00h-4004D07h (on ARM7 side)?

If there's no other way to obtain that bytes, the Cooking Coach exploit (not sudokuhax) does seem to leave the first 4 bytes at 40044D0h-40044D3h intact, so with some maths, one could compute 32bits of the 40044E0h-40044EFh area, that would leave only 32bits unknown, which could be probably found via brute-force within a few minutes, or hours at worst.

 

[nocash]

Heres my results:
[BPTWL: B7 00 00 5A 5A 5A 5A 5A]

Never seen such values. What kind of mainboard is that from? And what kind of BPTWL chip does that mainboard have?

The BPTWL is the small square chip (U6), left of the NDS cartridge slot, seen when removing the bottom cover (no need to disassemble the mainboard or lcd screens).

Btw. left of that chip, there should be another barcoder sticker (either that, or a black-ink stamp on other mainboards) (additionally to the TEF barcode on the bottom cover).

 

[MinterWute]

Here's one from a DSiXL as well. The chip is tiny though I need to see if I can get a decent picture of it though, my eyes really aren't up to reading the print on that.

 

[nocash]

Here's one from a DSiXL as well. The chip is tiny though I need to see if I can get a decent picture of it though, my eyes really aren't up to reading the print on that.

Oh yes, that chip has really tiny text. With a magnifying glass, sunlight, and at best viewing angles, I could barely decipher mine to say BPTWL in the upper line. Scanlime has made a good picture of her BPTWL chip, but one may need real good camera hardware to do that.

Anyways, if it's having the same kind of tiny text, that's maybe indicating that it's the same manufacturer. Apropos, this webpage http://electronics360.globalspec.com/article/3685/nintendo-dsi-handheld-game-console-teardown has somehow identified the BPTWL chip as "NEC Analog IC". No idea how/why it was identified as so. The part about "Analog IC" is nonsense, but maybe some chip versions are actually having some "NEC" markings on them (or maybe that was nonsense, too).

When reading the first byte from the BPTWL from I2C index 00h, values so far are:
33h - original DSi
BBh or B7h - DSi XL
And, the firmware contains some code that checks if the value is in range 00h..20h, and, if so, then it uses bigger I2C transfer delays. So chips with value(s) in range 00h..20h seem to exist, too (though maybe in prototypes only).

---

I've doing the maths stuff that converts the "E0 BB F1 03" values at 40044D0h-40044D3h from my screenshot to the corresponding values at 40044ECh..40044EFh. Result is either "25 01 A2 08" or "25 01 E2 08" (depending on carry-in from unknown bits; the "A2" value is more likely than "E2" since all other known DSi's (except DSi-XL) are having "A2" in that place, too).

So, only the four bytes at 40044E0h..40044E3h are missing before I can touch my eMMC memory. Four bytes would be 4 billion combinations, but the values seem to be always BCD (going by above screenshots), so there might be only 100 million combinations actually used.

I have gathered some serial/barcode values from some people. But couldn't see any relation to the 40044E0h..40044EFh port setting yet; except, that they are both decimal/BCD, but with different digits. Would be interesting to compare them from consoles with "nearby" barcode numbers (eg. something like TEF123000100 and TEF123000101).

Btw. the first letters of the barcode aren't always same. For DSi they can be TEF or TEH (and possibly further values). For DSi-XL they can be WEF or WW. The 2-letter variant might be for USA, and 3-letter for Europe. Official 'specs' are:
http://www.nintendo.com/consumer/repair/where_to_find_dsi_serial.jsp
http://www.nintendo.com/consumer/repair/where_to_find_dsixl_serial.jsp
http://www.nintendo.com/consumer/repair/where_to_find_3ds_serial.jsp
(TWnnnnnnnnn for DSi, WWnnnnnnnnn for DSiXL, and CWnnnnnnnnn for 3DS)

Did anybody ever use that http://www.nintendo.com/consumer/repair/ site? I haven't tried, but one seems to need to register, and then one can possibly enter the barcode (following above instructions), and then... I wonder what happens then!
Either they are supplying full service manuals and schematics... or they are just telling something like "click here to order a replacement battery for your console model"... or "contact trained service personnel for battery replacement" ; - )

 

[MinterWute]

Oh yes, that chip has really tiny text. With a magnifying glass, sunlight, and at best viewing angles, I could barely decipher mine to say BPTWL in the upper line. Scanlime has made a good picture of her BPTWL chip, but one may need real good camera hardware to do that.

Managed a decent pic

Don't know how helpful this is - all I can find is random chinese companies offering to sell whatever it is.

Here's the one from the DSi as well.

Did anybody ever use that http://www.nintendo.com/consumer/repair/ site? I haven't tried, but one seems to need to register, and then one can possibly enter the barcode (following above instructions), and then... I wonder what happens then!
Either they are supplying full service manuals and schematics... or they are just telling something like "click here to order a replacement battery for your console model"... or "contact trained service personnel for battery replacement" ; - )

They just give you reference numbers and give you details of how to ship your console to a Nintendo repair center.

 

[nocash]

Nice. Then it's "BPTWL, KG07K" for Dsi (as so scanlime's photo).
And "BP UTL-1, KG08" for DSiXL (or probably some other revision for Normatt's I2C values).
Only the character after the "K" is hard to get, could be G or 0 or Q, but I suppose it's G.

And the two round dots, might be the manufacturer logo? Best I could find is the Seiko Instruments Inc logo: SII O'
But the size of the O' dots doesn't match too well. That O' logo seems to exist only "virtually" as webpage/document logo.
In fact, for whatever reason, I couldn't fine ANY photos of Seiko/SII chips in internet. Except for a few ones, without visible logo or part numbers on them (which might hint that SII tends to use very tiny/invisible text layers, too).

Funny that there are companies selling that chips. I knew that there are companies offering old-stock stuff, including chips with pre-programmed firmwares for obscure hardware on them which are hardly useful today. I wonder where they got DSi chips from, maybe from broken consoles, or sorted-out chips from nintendo.

The BPTWL registers are described here, http://problemkaputt.de/gbatek.htm#dsii2cdevice4ahbptwlchip and pin-out is here http://problemkaputt.de/gbatek.htm#auxdsichipsetpinouts

---

I've been trying to search my missing four bytes for 40044E0h-40044E3h. Good news is that the DSi hardware could scan 8-digit BCD combinations in about one hour (maybe much faster when optimizing the software) (and using a PC would be faster than the DSi). Searching 8-digit HEX combinations should be 40x slower, but it would be still possible within reasonable time.

Bad news is that it didn't work out yet. I've tried all BCD combinations, and the first 28000000h HEX combinations without match. The test was done assuming that eMMC offset 1E0h..1EFh contains values from two unused 00h-filled partition entries; maybe that assumption was wrong. Knowing how the decrypted MBR in first 200h bytes should look like would be nice.

A complete test case would be also nice. I would only need the 40044E0h..40044EFh values, the CID value, and the encrypted and decrypted content of any 10h-byte eMMC section (and the address of that section, which should be 10h-aligned, of course).

 

[nocash]

Ah, on 3dbrew.org, the equivalent 3DS chip is called "Renesas Electronics UC CTR".
The two dots on the BPTWL and BP UTL-1 photos are in fact matching the the logo on Renesas Electronics chips (better than the SII logo). Some Renesas chips have only one dot. Or two dots horizontally, vertically, or diagonally arranged - not sure if it's really meant to be logo - but it's somehow characteristic for Renesas.
What I've learned is that it's very easy to find Renesas chip photos in internet, but almost impossible to find Seiko chip photos.

 

[nocash]

Okay, I found a 240Mbyte "nandxor" file, a port 4004D00h dump, and several CID values from some person. Fortunately (one of) the CID values matched to the nandxor file, and also matched to the port 4004D00h values. So I could now calculated the content of that nandxor file by software; which also means that one doesn't need to waste 240Mbyte of disc space on storing those XOR values.

And, that has confirmed that I didn't make any fundamental mistakes in the "AES_IV=SHA1(CID)+addr/10h" formula. At least one thing that I've got right! The CID is meant to be in the same format as stored in RAM at 2FFD7BCh (dd,ss,ss,ss,ss,03,4D,30,30,46,50,41,00,00,15,00), ie. it's only the upper 120bits of the CID value (without the CRC byte in LSB), and then it's zero-padded to 16-byte size (with 00h in MSB). The first 16bytes of the 20byte big-endian SWI SHA1 output are then used as little-endian AES_IV value (ie. the endianness is the "wrong" way, which is no problem, and it's allowing to pass the SWI SHA1 result directly to the little endian AES_IV register (plus little endian CTR index), without needing to reverse the byte order by software).

Alongsides, this has also confirmed that port 4004D00h contains a console ID value. The words at 4004D00h and 4004D04h are directly copied as-is to 40044E0h and 40044ECh, and the same values are also copied (XOR by constants) to 40044E4h and 40044E8h accordingly. That info isn't useful in practice because the usual exploits don't allow to read 4004D00h, but it's nice to know what that I/O port is good for. For most other I/O ports we did at least have some idea what hardware feature they'd be related to, but until now, 4004D00h has been some kind of total mystery.

Unfortunately, I don't have any encrypted or decrypted data corresponding to the above "nandxor" file, it's containing only the XOR values, but no data. So I do still have no real idea how the decrypted MBR should look like. There are probaly some 00h-filled or FFh-filled areas at certain locations, but just guessing around isn't fun - not when it takes some hour(s) per guess : - /

 

[nocash]

Okay. Got it. I've been running the test over night, checking all 4 billion combinations, even unlikely non-BCD ones, and large values with non-zero MSBs. The test completed after about 30 hours, without success.

Then I tried the set of working values, computed the corresponding 40044D0h..40044D3h bytes, and pretended that I wouldn't know the 40044E0h..40044EFh bytes (reproducing the same situation as for cooking coach users).

Running the test on that values reached a match after a few minutes, so I knew that I was doing everything right on software side. Which almost made me gave up; assuming that the my eMMC dump or the CID value that I had found in RAM were corrupted.

But finally I got my eyes on a decrypted MBR. And know what? The damn thing has three partitions! So the bytes at 1E0h..1EFh which seemed to be the most likely definetly zero-filled area wasn't zero at all, crap! The third partition is very small (only 209.5Kbytes), and it's left unformatted, so people must have thought that it isn't worth mentioning (if anybody has ever had discovered it at all).

Knowning that only the 4th partition entry is left blank (followed by the usual 55h,AAh mbr id bytes), it's been easy to find the missing 32bits of my console byte in a few hours. One of it's hex-digits appears to be always "1" on all (five) known dsi and dsi-xl consoles, and the other digits are all in bcd-range; if that holds true for all other consoles, then there only 10 million possible combinations, and the DSi hardware would be fast enough to find the value in about 6 minutes (or less).

NB. aside from the three partitions, there are also two odd small gaps (between 1st+2nd and between 2nd+3rd partitions).

So anyways, I could now read & write my eMMC file system. Whatever that is good for. Maybe, if I run out of disc space, I could save backups of my source code on the DSi (though I don't know if it's really recommended to use the DSi as backup media).

 

[nocash]

Hummm, while writing some documentation for the Console IDs, I just noticed that the whole 64bit Port 4004D00h value can be also found as 16-byte ASCII string in the encrypted footer of "Tad Files".

As far as I know, "Tad Files" are dsiware games stored on SD cards, so the Tad footer can be probably decrypted via the "dsi srl extractor" source code, which would be somewhat negating my past days efforts ; - )

That way, it should be possible to obtain the 4004D00h value even without using exploits on real hardware. I couldn't see the CID in the Tad header/footer though - but the CID could be obtained quite easily via exploits (or by wiring cables to the eMMC chip as last resort).