Homebrew Any hope for Dsi's with no DsiWare?

[Ghost]

If you have your CID, you might one day be able to bruteforce your Console ID. Then, with a hardmod, you can decrypt a NAND backup and install a DSiWare that way. Of course, the bruteforcing might take a while.

bruteforce your console ID

Are there tools available to brute force it?

 

[Oleboy555]

Are there tools available to brute force it?

no idea, I read about it in some other post, try the search feature mayeb you will find it

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

Are there tools available to brute force it?

ConsoleIDs are in this form:
08A20nnnnnnnn1nnh for DSi
08A19???????????h for some other DSi
08201nnnnnnnn1nnh for DSi XL
????????????????h for 3DS
with the "n" digits being in range 0..9 (no A..F digits). As far as I remember it took around 30 hours to brute-force the correct digits (that, doing the bruteforcing on a DSi console, it may be faster on other hardware). A tool for brute-forcing the CID would be probably more interesting (since most people already have the ConsoleID, and do only need to CID). As long as you know one of the two values it shouldn't be too difficult to brute-force the other value within reasonable time.

TAD is slang for BIN files on SD card, which isn't what you are downloading from the dsi shop. The BIN files are nice because they do also include a copy of the TMD, plus some personal data like game positions, and the ConsoleID.

 

[nastys]

The CID can be extracted by copying any DSiWare to the SD card to decrypt and analyze its footer, while the ConsoleID can be extracted using The Biggest Loser or a Raspberry Pi (or simply brute force), right?

ConsoleID and CID look similar, so brute-forcing both should be possible. We just need a tool that can suspend and resume the process, since I don't think many people would want to leave their PCs on for days.
I could try to write one, but I need to hardmod my Nintendo DSi first.

 

[Deleted User]

The CID can be extracted by copying any DSiWare to the SD card to decrypt and analyze its footer, while the ConsoleID can be extracted using The Biggest Loser or a Raspberry Pi (or simply brute force), right?

It's the other way around. The ConsoleID can be extracted via copying DSiWare to the SD card, whilst the CID can be extracted via The Biggest Loser or a Raspberry Pi.

ConsoleID and CID look similar, so brute-forcing both should be possible. We just need a tool that can suspend and resume the process, since I don't think many people would want to leave their PCs on for days.
I could try to write one, but I need to hardmod my Nintendo DSi first.

If you have the CID, you can bruteforce the ConsoleID. If you have the ConsoleID, you can bruteforce the CID. It might take months to bruteforce both, thus making it an unviable solution.

 

[nastys]

It's the other way around. The ConsoleID can be extracted via copying DSiWare to the SD card, whilst the CID can be extracted via The Biggest Loser or a Raspberry Pi.


If you have the CID, you can bruteforce the ConsoleID. If you have the ConsoleID, you can bruteforce the CID. It might take months to bruteforce both, thus making it an unviable solution.

Someone could write a tool that uses the GPGPU (OpenCL) to brute-force the required ID(s) in a reasonable amount of time, for those who have a powerful graphics card.
Unfortunately, I don't know how to code such a program.

 

[thom_tl]

Does anyone know how long TWLTool does over decryting the nand? I am looking into making a tool(no promises my programming experience isn't that good).
Edit: Also what does TWLTool return when it gets a false CID or ConsoleID? Does it chrash, return a error code or make a false decryted nand.bin

 

[thom_tl]

no idea, I read about it in some other post, try the search feature mayeb you will find it

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

Is the information about the ConsoleID from Nocash123 correct? that would simplify it a lot.

 

[The Real Jdbye]

Like I just said I don't have any DsiWare not even the browser.

I read somewhere that the browser is still on the DSi Shop.

 

[JimmyZ]

Someone could write a tool that uses the GPGPU (OpenCL) to brute-force the required ID(s) in a reasonable amount of time, for those who have a powerful graphics card.
Unfortunately, I don't know how to code such a program.

If you don't know how to code, why would you assume this could benefit from OpenCL?

Does anyone know how long TWLTool does over decryting the nand? I am looking into making a tool(no promises my programming experience isn't that good).
Edit: Also what does TWLTool return when it gets a false CID or ConsoleID? Does it chrash, return a error code or make a false decryted nand.bin

If you're trying the entire NAND to bruteforce, you're out of your mind. I don't know much, but from a quick glance at TWLTool's source code, the existing bruteforcing for 3DS TWL_FIRM is trying just 16 bytes by knowing the result should be all zero, that makes the bruteforcing viable.

But I'm not sure if there is a similar thing(known block in decrypted image) for DSi NAND, even if it's true, bruteforcing Console ID could be harder, CID is 16 bytes but only 31 effective bits(source, I'm pretty sure he meant lower 31 bits), Console ID is 8 bytes but might(this is just my assumption) have 44 effective bits(5 digits of the hex string known, 64 - 4*5), that's 8192 times longer.

Bruteforcing ConsoleID + CID then could be 2^44 = 17592186044416 times longer.

Maybe nagging TWLTool's author is the right way to go.

 

[nastys]

If you don't know how to code, why would you assume this could benefit from OpenCL?

Because similar programs do. Also, I know how to code, but I've never used the OpenCL libraries.

 

[thom_tl]

I read somewhere that the browser is still on the DSi Shop.

For me only the 3ds transfer tool.

 

[JimmyZ]

Because similar programs do. Also, I know how to code, but I've never used the OpenCL libraries.

Even if it could, it can't be 2^44 times faster.

 

[nastys]

For me only the 3ds transfer tool.

Can that be copied to the SD card?

Even if it could, it can't be 2^44 times faster.

At least it would make it faster to get one of the two keys. The CID can be extracted using The Biggest Loser or a Raspberry Pi anyway.

 

[thom_tl]

If you don't know how to code, why would you assume this could benefit from OpenCL?


If you're trying the entire NAND to bruteforce, you're out of your mind. I don't know much, but from a quick glance at TWLTool's source code, the existing CID bruteforcing for 3DS TWL_FIRM is trying just 16 bytes by knowing the result should be all zero, that makes the bruteforcing viable.

But I'm not sure if there is a similar thing(known block in decrypted image) for DSi NAND, even if it's true, bruteforcing Console ID could be harder, CID is 16 bytes but only 31 effective bits(source, I'm pretty sure he meant lower 31 bits), Console ID is 8 bytes but might(this is just my assumption) have 44 effective bits(5 digits of the hex string known, 64 - 4*5), that's 8192 times longer.

Bruteforcing ConsoleID + CID then could be 2^44 = 17592186044416 times longer.

Maybe nagging TWLTool's author is the right way to go.

Thats way to difficult for me, maybe its better getting someone who knows how it could work.

Can that be copied to the SD card?


At least it would make it faster to get one of the two keys. The CID can be extracted using The Biggest Loser or a Raspberry Pi anyway.

no it can't be copied.

 

[JimmyZ]

Can that be copied to the SD card?

This, is really a good point.

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

no it can't be copied.

so sad

 

[thom_tl]

has there been sought for exploits in the 3ds transfer tool yet, maybe a pc application which fakes to be a 3ds and then injects a app and save that is exploitable?

 

[Deleted member 424658]

has there been sought for exploits in the 3ds transfer tool yet, maybe a pc application which fakes to be a 3ds and then injects a app and save that is exploitable?

It doesn't transfer data to the DSi

 

[thom_tl]

It doesn't transfer data to the DSi

With an exploit it maybe could since it has excess to nand read(transferring to 3ds) and write(deleting games and saves from the transferred game) or load up hbmenu or fwtool or something.

 

[Oleboy555]

Is the information about the ConsoleID from Nocash123 correct? that would simplify it a lot.

yeah I quoted nocash123

its from here:

https://gbatemp.net/threads/release...ion-etc-multitool.393488/page-31#post-7329027

 

[JimmyZ]

Forget most of my analysis before. TWLTool seems to be using the term cid/ConsoleID interchangeably and use emmc_cid for commonly referred CID, and I was totally confused, looks like he is bruteforcing Console ID instead of EMMC CID despite the name 'brute_cid' suggests, EMMC CID looks not brute-able then for been 128 bits long.

About known bytes, he verified 16 bytes from offset 0x1e0, since the DSi NAND holds a MBR, that offset falls between the 3rd and 4th partition table entry, so I suppose this verification will still work with DSi.

In the end, it looks to me, OP's problem could be solved by porting the 3DS only brute force code to DSi, maybe @WulfyStylez could answer why such thing is not implemented, maybe there're something I don't know made it impossible.