Homebrew Any hope for Dsi's with no DsiWare?

[thom_tl]

Except I've already build & upload the exe? look up a bit.

We might need more testing before spreading it, I only had one NAND dump tested.

I'l use it when i get around to hardmodding my dsi(probably a couple months because school).

--------------------- MERGED ---------------------------

Except I've already build & upload the exe? look up a bit.

We might need more testing before spreading it, I only had one NAND dump tested.

Found it would test a bit but my antivirus is acting up a bit.

 

[nocash123]

The CID would be needed if somebody dumped the encrypted eMMC with a hardmod, but without having the tools/hardware for obtaining the CID:
- with dsiware/dsicart exploits: one can usually read the CID from Main RAM
- with dsiware exploits: one can read the CID via sdmmc commands directly from hardware
- with special card readers (like raspberry's or the like): one can read it via hardmod

And for the ConsoleID:
- with datamanagment: one can export a title to SD card (requires an exportable title (browser seems to be still available in japan, but not in europe))
- with dsiware/dsicart exploits: one can get the ConsoleID from AES keyslot (with some trickery for "reading" the write-only registers)

Some people may have only the CID, or only the ConsoleID. So bruting the missing value would be useful either way around.

Oh, and two other things:

All that hype that occurred last month about having (or not having) a console with firmware v1.4 was kinda nonsense because everybody can upgrade/downgrade the firmware, either via hardmods or dsiware exploits (and one will need that hardmod or exploit before being able to install rocketlauncher anyways).

But before installing exploits or upgrading/downgrading... it would be nice to make a backup of the whole 240MByte original eMMC memory (alongside with the CID/ConsoleID needed for decrypting it). Having the backup will useful in case of bricking the console. And, it would be also interesting because most firmware versions/regions are still undumped.
One couldn't release the dump for copyright reasons, but one could post a directory tree with CRC32's for each file - allowing to see which files the different versions consisted of, to see if there have been older files pre-installed before the first firmware update, or to see if korean consoles did have a different font file, etc.

 

[thom_tl]

The CID would be needed if somebody dumped the encrypted eMMC with a hardmod, but without having the tools/hardware for obtaining the CID:
- with dsiware/dsicart exploits: one can usually read the CID from Main RAM
- with dsiware exploits: one can read the CID via sdmmc commands directly from hardware
- with special card readers (like raspberry's or the like): one can read it via hardmod

And for the ConsoleID:
- with datamanagment: one can export a title to SD card (requires an exportable title (browser seems to be still available in japan, but not in europe))
- with dsiware/dsicart exploits: one can get the ConsoleID from AES keyslot (with some trickery for "reading" the write-only registers)

Some people may have only the CID, or only the ConsoleID. So bruting the missing value would be useful either way around.

Oh, and two other things:

All that hype that occurred last month about having (or not having) a console with firmware v1.4 was kinda nonsense because everybody can upgrade/downgrade the firmware, either via hardmods or dsiware exploits (and one will need that hardmod or exploit before being able to install rocketlauncher anyways).

But before installing exploits or upgrading/downgrading... it would be nice to make a backup of the whole 240MByte original eMMC memory (alongside with the CID/ConsoleID needed for decrypting it). Having the backup will useful in case of bricking the console. And, it would be also interesting because most firmware versions/regions are still undumped.
One couldn't release the dump for copyright reasons, but one could post a directory tree with CRC32's for each file - allowing to see which files the different versions consisted of, to see if there have been older files pre-installed before the first firmware update, or to see if korean consoles did have a different font file, etc.

I don't know if a 1.4.5E directory tree would help but when i get around to hardmodding it i could try an get one.

 

[JimmyZ]

The CID would be needed if somebody dumped the encrypted eMMC with a hardmod, but without having the tools/hardware for obtaining the CID:
- with dsiware/dsicart exploits: one can usually read the CID from Main RAM
- with dsiware exploits: one can read the CID via sdmmc commands directly from hardware
- with special card readers (like raspberry's or the like): one can read it via hardmod

So the only useful case for CID brute is hardmod without access to a software MMC reader like raspberrypi, that could exist.

But how do we get the 8 bit date code and "2-3 chip/maker specific combinations"? if we have to brute the 8 bit date code too, that's (64 seconds per 0x10000000(2^28) tries) * 2 ^ (32 + 8 - 28) * (3 chip/maker combinations) about 10 CPU days, that's less attractive, might consider get a raspberry pi instead?

Anyway, this shouldn't be too much work, I might write it as well

 

[nocash123]

I don't know if a 1.4.5E directory tree would help but when i get around to hardmodding it i could try an get one.

Yes, would be great to have that and other versions. I've made an extra thread for it... please post such stuff here:
http://gbatemp.net/threads/dsi-directory-trees-from-original-firmware-dumps-preservation.481532/

But how do we get the 8 bit date code and "2-3 chip/maker specific combinations"? if we have to brute the 8 bit date code too, that's (64 seconds per 0x10000000(2^28) tries) * 2 ^ (32 + 8 - 28) * (3 chip/maker combinations) about 10 CPU days...

Oops, is that much slower?
CID with 8bit+32bit would be 1024 billion calculations, plus one sha1 calculation for each step.
ConsoleID with around 10 bcd digits, yes, that's less. Btw. did you come across cases where ConsoleID bit8-11 contains a value other than "1", or is it always that value?

The CID fixed bits are listed in gbatek DSi Console IDs chapter. You could try both, or open the console and look what chip you have in there. The month digit should be in range 01h..0Ch (or is it 00h..0Bh)? And the year should be 0Bh..0Fh for year 2008..2012, assuming that the chips won't be older than 2008. The MMC specs don't define years after 2013. For narrowing down the year... I haven't spotted any date codes on the case/chipset/mainboard, so your best bet would be that the chip must be "older" than when you've bought the console, and "older" than the installed firmware version (which won't help much if you start searching from year 2008 upward anyways).

So the only useful case for CID brute is hardmod without access to a software MMC reader like raspberrypi, that could exist.

I think a lot of people bought that Biggest Loser cartridge just for that purpose.

 

[JimmyZ]

Oops, is that much slower?

The brute force method might not be very efficient, I don't know much about AES, it's just a simple adaption of the original 3DS TWL FIRM brute code.

Btw. did you come across cases where ConsoleID bit8-11 contains a value other than "1", or is it always that value?

I only have two cases, yes they are all 1. But my DSi XL is 08202, not 08201.

I think a lot of people bought that Biggest Loser cartridge just for that purpose.

Are other dsiwarehaxes not able to do this?

twltool dsibrutecid --in DSi-NAND-enc.bin --consoleid 08A1522617110121 --cid ab6778e02d034d303046504100001500

It takes a cid input as a template and brute the 32 random bits(those bits in the input is ignored), so, you tell it the date and chip code.
In my test it took 267 seconds to get a hit at 6778e02d, that's 0x2de07867/0x100000000 about 0.179 coverage, so a full 32 bit brute would take about 25 minutes.

 

[Apache Thunder]

I think a hardmod with a rashberry pi would give you the CID pretty easily as that could be retrieved with certain EMMC commands. If you have Linux I think you could do it on any PC if you have the right card reader that gives it low level access. (some newer ones might not)

As for ConoleID, that's only retrievable from dev.kp or from an exported TAD file from Data Management. The register for it is normally write-only for normal DSiWare hax entrypoints. Any TWL mode entry point has access to the NAND CID, so getting that one isn't too difficult.

If you didn't have nand mod and managed to dump your nand via fwtool for example, you already have a means of getting the NAND CID with just homebrew running from the entry point you used. fwtool has an option for dumping that.

Assuming you aren't using an outdated sudokuhax payload. The older one before it went open source poisened the NAND CID in ram so you will not get valid reults from it from the usual memory location if running that version of sudokuhax.

 

[Abequinn]

I think a hardmod with a rashberry pi would give you the CID pretty easily as that could be retrieved with certain EMMC commands. If you have Linux I think you could do it on any PC if you have the right card reader that gives it low level access. (some newer ones might not)

As for ConoleID, that's only retrievable from dev.kp or from an exported TAD file from Data Management. The register for it is normally write-only for normal DSiWare hax entrypoints. Any TWL mode entry point has access to the NAND CID, so getting that one isn't too difficult.

If you didn't have nand mod and managed to dump your nand via fwtool for example, you already have a means of getting the NAND CID with just homebrew running from the entry point you used. fwtool has an option for dumping that.

Assuming you aren't using an outdated sudokuhax payload. The older one before it went open source poisened the NAND CID in ram so you will not get valid reults from it from the usual memory location if running that version of sudokuhax.

you just made me very confused

 

[nastys]

I think a hardmod with a rashberry pi would give you the CID pretty easily as that could be retrieved with certain EMMC commands. If you have Linux I think you could do it on any PC if you have the right card reader that gives it low level access. (some newer ones might not)

As for ConoleID, that's only retrievable from dev.kp or from an exported TAD file from Data Management. The register for it is normally write-only for normal DSiWare hax entrypoints. Any TWL mode entry point has access to the NAND CID, so getting that one isn't too difficult.

If you didn't have nand mod and managed to dump your nand via fwtool for example, you already have a means of getting the NAND CID with just homebrew running from the entry point you used. fwtool has an option for dumping that.

Assuming you aren't using an outdated sudokuhax payload. The older one before it went open source poisened the NAND CID in ram so you will not get valid reults from it from the usual memory location if running that version of sudokuhax.

A rooted Android phone and a cheap SD to microSD adapter should work too, since, I believe, most phones have low level access (/dev/mmcblkx).
This is the adapter I'm talking about:
(also useful if you have a newer Raspberry Pi or another board with a microSD slot).

 

[nocash123]

I think a lot of people bought that Biggest Loser cartridge just for that purpose.

Are other dsiwarehaxes not able to do this?

Sure, but they needed to have the CID before being able to install sudokohax (unless they had downloaded sudoku before nintendo had blocked the sd card .sav file exploit).
With the (yet unreleased) flipnote exploit most people can get the CID that way, but there are quite a lot of people whom haven't downloaded flipnote when the dsishop was still online, either because they didn't want to, or because it wasn't available in china/korea. So that people might be glad about CID brute forcing (as long as they have some other exportable title for obtaining the ConsoleID) (and as long as they are willing to do the hardmod).

Processing one date code in 25 minutes sounds nice. Then the 5x12 date codes for consoles from 2008-2012 would take 25 hours, and it might be worth spending that much time. I think it's about fast enough, but just for fun, some ideas for possible improvements (most ideas were already mentioned by other people):
Some SSL libraries use hardware acceleration for AES instead of using the CPU for it (or does your code already use that kind of SSL libraries?). Or, on the CPU, using ASM might be faster, as well as using all CPU cores. And for 3D video hardware... maybe there's already some working AES code for video cards somewhere.

Does your tool automatically increment the day/month digits? That would make it a bit easier to use. I don't know what should happen on chips from 2013 and up (if the DSi was still in production at that date at all)... maybe they started over at year "0"?

--------------------- MERGED ---------------------------

fwtool has an option for dumping that.
Assuming you aren't using an outdated sudokuhax payload.

I only knew that sudokuhax smashed some constants in the AES KEY.Y registers (apparently it was intentionally designed to be a "hack with anti-hacking features"). Anyways, if sudokuhax is smashing the Main RAM value, too, then you could still read the CID with SD/MMC commands (as you were already doing in some of the pre-release rocketlauncher versions).

 

[Valery0p]

with dsiware/dsicart exploits: one can get the ConsoleID from AES keyslot (with some trickery for "reading" the write-only registers)

This seems interesting it's easily replicable with dsiwarehax access?

 

[nocash123]

I hope so, it should work with both dsiware-exploits and dsicartridge-exploits (unless the exploit had destroyed the KEY3.X values, but I think even sudoku doesn't do that).
The general idea for "reading" is to overwrite the separate key bytes by values 00h..FFh, until getting the same decryption result as with the unmodified key (and also write some 'dummy' value to KEY3.Y.lastbyte to apply the original or changed KEY3.X values).

I GOT A LIKE FROM NOCASH! THIS JUST MADE MY DAY!

And... that made my day, thanks. Now I am feeling like a whole boygroup : )

 

[JimmyZ]

Some SSL libraries use hardware acceleration for AES instead of using the CPU for it (or does your code already use that kind of SSL libraries?). Or, on the CPU, using ASM might be faster, as well as using all CPU cores.

TWLTool used PolarSSL, I didn't touch that, it's not famous for performance but portability, I tried to turn on some ASM switches but strangely it became a (tiny) bit slower could be test bias but it didn't go dramatically faster is bad enough.
I'm thinking about using OpenSSL instead, might as well write a new tool instead of piggybacking on TWLTool, doesn't really fit in.

And for 3D video hardware... maybe there's already some working AES code for video cards somewhere.

I've never worked on OpenCL or CUDA before, really interesting subject but I really don't think I can learn it in one weekend.

Does your tool automatically increment the day/month digits? That would make it a bit easier to use.

Nope, I think it's better left for a external script to invoke this tool, more flexible I think.

I don't know what should happen on chips from 2013 and up (if the DSi was still in production at that date at all)... maybe they started over at year "0"?

I have absolutely no idea, I don't even have the CID of my DSi XL, the only test sample on my hand was downloaded somewhere as a no$gba DSi emulating package...

 

[JimmyZ]

Just finished rewriting the crypt code, using OpenSSL EVP, that should have AES-NI support.

Now let me port back the brute code.

 

[JimmyZ]

OpenSSL EVP cost 177 seconds on a 3.1GHz i5, vs 267 seconds on 2.5GHz i3m for PolarSSL, I'm really disappointed, I suppose the usage pattern couldn't benefit much from AES-NI.

Turn off AES-NI support with OPENSSL_ia32cap="~0x200000200000000", time cost goes up to 220 seconds, so I guess I'm not too wrong.

code and windows binary here:
https://github.com/Jimmy-Z/TWLbf

 

[JimmyZ]

Did some optimize, now down to 124 seconds, a whole 32bit run cost 690 seconds.

Also did some profiling:

SHA1: 185357
AES: 10227
memcmp: 6783

so apparently SHA1 now cost most of the time
actually this aligns well with openssl test results:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             68588.91k   193013.55k   414714.86k   589814.10k   688450.22k
aes-128-ecb     603484.19k  1968016.19k  3464158.63k  3798092.46k  3904755.03k

BTW this is without AES-NI, so it works really well.

SHA1: 169322
AES: 54345
memcmp: 6778

BTW2 I think multithreading is not worth it, just run multiple instance on different date codes.

BTW3 I read a bit abot OpenCL, this doesn't look like something just plug in and run, a beginner's code could easily be worse than CPU code, I might as well try some.

 

[thom_tl]

A bit of topic but here is a update from me, I was searching around on Marktplaats(the dutch equivalent of Ebay) when i found a dsi with flipnote and the browser for 20 euro's(about $23,60) which is extremely cheap so i'm going to pick it up. I'm still going to hardmod my current one for fun and archival purposes.
Edit 1: Extremely cheap compared to the prices here my current one cost me 40 euro's($47).

 

[JimmyZ]

A bit of topic but here is a update from me, I was searching around on Marktplaats(the dutch equivalent of Ebay) when i found a dsi with flipnote and the browser for 20 euro's(about $23,60) which is extremely cheap so i'm going to pick it up. I'm still going to hardmod my current one for fun and archival purposes.
Edit 1: Extremely cheap compared to the prices here my current one cost me 40 euro's($47).

Wow, that's really nice.

(That one person in the whole world who's gonna use my program just got a way out)

--------------------- MERGED ---------------------------

Console ID brute force got 3 times faster, if anyone still cares.

 

[wicksand420]

Everybody with a DSi should care, Thank you for your work JimmyZ

 

[JellyPerson]

Yes, JimmyZ. You did a good job.