Homebrew Any hope for Dsi's with no DsiWare?

  • Thread starter Thread starter thom_tl
  • Start date Start date
  • Views Views 20,152
  • Replies Replies 102
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.
If I understand correctly the verification area wich is all 0 on the 3ds also exist on the dsi but in a different location?
 
nah, (at least in europe) if a dsi formated without anything go to the dsi shop, the only thing there is the 3ds transfer tool
 
  • Like
Reactions: CatmanFan
If I understand correctly the verification area wich is all 0 on the 3ds also exist on the dsi but in a different location?
DSi had 3 partitions, so 0x1e0 might not work, but 0x1f0 should work with 000000000000000000000000000055aa.

My DSi is 1.4.5E and I don't have any DSiwarehax nor the solder skill for hardmod, currently waiting for ugopwn, so I can't test my assumptions.
 
Last edited by JimmyZ,
Again, I read a bit more, it seems NAND encryption on 3DS TWL and DSi are a bit different, on 3DS TWL only the lower 31 bits of Console ID is used, while on DSi the whole 64 bits are used, this makes brute-forcing decisively less viable, this might be the reason @WulfyStylez didn't do it in the first place, sorry for giving you false hope.
 
Last edited by JimmyZ,
Last edited by JimmyZ,
Update again, did some test with a NAND dump I got somewhere, it only took about 65 seconds through 0x10000000 tests on single thread, so might not that bad after all.

if it works, credit goes to @WulfyStylez
Thank you, Did you know the ConsoleID of the nand backup before? And is the bruteforced one correct? I currently am not in the location to hardmod but once I will attempt it I will use this. Last question what is the clockspeed of your CPU since that limits the attempts you can make within 65 seconds?
 
Thank you, Did you know the ConsoleID of the nand backup before? And is the bruteforced one correct? I currently am not in the location to hardmod but once I will attempt it I will use this. Last question what is the clockspeed of your CPU since that limits the attempts you can make within 65 seconds?
The Console ID of the NAND image I got is 08A1522617110121, I modified TWLTool to make it brute between a designated range, it brute from 08A1522600000000 to 08A15226ffffffff and took 93 seconds to get a hit at 08A1522617110121, CPU used is i5-3210M 2.5GHz.

Based on this rate, you can brute the 08a15* range in roughly 45 CPU days, or a little more than ten days with a 4 core CPU.

And based on nocash's BCD assumption, the time cost could be down to no more than one hour, a BCD loop need to be implemented though.
 
The Console ID of the NAND image I got is 08A1522617110121, I modified TWLTool to make it brute between a designated range, it brute from 08A1522600000000 to 08A15226ffffffff and took 93 seconds to get a hit at 08A1522617110121, CPU used is i5-3210M 2.5GHz.

Based on this rate, you can brute the 08a15* range in roughly 45 CPU days, or a little more than ten days with a 4 core CPU.

And based on nocash's BCD assumption, the time cost could be down to no more than one hour, a BCD loop need to be implemented though.
What if it would be modified with CUDA or opencl so it can run on thousands of threads?

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

What if it would be modified with CUDA or opencl so it can run on thousands of threads?
Edit1: What is a BCD Loop?
Edit2: If you had to search all of the possibilities within the 08a* range how long would it take since i have no indicatation of it being 08a15* or 08a20* or something?
 
Last edited by thom_tl,
What if it would be modified with CUDA or opencl so it can run on thousands of threads?
Edit1: What is a BCD Loop?
I guess it's not worth the effort if it's already down to less than one hour.
Basically you loop from decimal 0~9 instead of hex 0~f.
 
Edit2: If you had to search all of the possibilities within the 08a* range how long would it take since i have no indicatation of it being 08a15* or 08a20* or something?
ARITHMETIC! if you loop from 08a00 to 08aff that's 0x100 = 256 times longer then.

Or you can try 08a20 08a19 08a15 according to nocash, that's only 3 times longer.
 
Since this tool does not utilize the GPU nor anything else apart from the CPU, RAM and HDD, it shouldn't reach 550 W unless you have a really inefficient processor...
It was more kinda a metafor since even 3 hours on full power will take a significant amount of power.
 

Site & Scene News

Popular threads in this forum