Hacking 3DS unbricking progress

  • Thread starter Thread starter krisztian1997
  • Start date Start date
  • Views Views 376,679
  • Replies Replies 1,233
  • Likes Likes 32
Status
Not open for further replies.
They really should give them for free, they got people's consoles bricked, they should pay for the fix....I doubt it though....probs sell it for a nice fat profit.....same should apply for gateway users who got bricked....gateway should supply the fix to them for free
 
3ds XL only?

Finding one of the pins on 3ds is much harder, so you cant make a pogo pin setup to do that...

They really should give them for free, they got people's consoles bricked, they should pay for the fix....I doubt it though....probs sell it for a nice fat profit

with my or bkifft's code on it. good job bkifft with that code, now lets hope that my code works too and someone can reverse engineer the launcher and find how the password is generated
 
  • Like
Reactions: gamefan5
Now everyone have the proof for the brick code. The eMMC controller doesn't lock itself by "magic".
 
Well all that aside let's not turn this thread into another flame war.......both sides where in the wrong, atleast there is a fix :D
 
Now everyone have the proof for the brick code. The eMMC controller doesn't lock itself by "magic".
Any progress with the bricking code or you gave up trying to reverse engineer it ? The way how the password was generated would be the most helpful thing right now, then we could help angryrusiankid to unbrick his console
 
The problem is, the AES engine and CID is used to generate the password and the key is stored in the Launcher.dat.
 
Finding one of the pins on 3ds is much harder, so you cant make a pogo pin setup to do that...

Can you not use the pins on the other side of the mobo?

CLK:

3dsDump2.jpg
 
The problem is, the AES engine and CID is used to generate the password and the key is stored in the Launcher.dat.
The key used for locking the eMMC is stored in the launcher.dat ? and if the internal AES engine is used to generate the locking key, then all what we can do is to force erase...

Can you not use the pins on the other side of the mobo?

CLK:

3dsDump2.jpg

Do you think that it would be posible to touch that pin with a pogo pin ? it looks so super small
 
^Not trying to show you down but I think it's technically possible. We will still have to use a little bit of solder though.

Making that small circle bigger by applying some solder might do the trick. Actually, I think there are conductive stickers available, that too, in circled sizes.

Btw, congrats to you guys for achieving this! Welldone!
 
^Not trying to show you down but I think it's technically possible. We will still have to use a little bit of solder though.

Making that small circle bigger by applying some solder might do the trick. Actually, I think there are conductive stickers available, that too, in circled sizes.

Btw, congrats to you guys for achieving this! Welldone!

Or without solder by using some pins like those but smaller ones http://dangerousprototypes.com/wp-content/media/2013/02/IMG_1796.jpg, but this will work only if my code works on arduino, otherwise you will need a raspberry pi and its gonna be harder to make an solderless unbricker
 
One more question regarding NAND dumps: I believe it was profi who said that the dump generated by Gateway's (and the other's) Launcher.dat is actually altered in some way, and therefore can't be used as a replacement to a "real" dump. However, I think somebody else also said they used a dump generated by Gateway's code, and it worked just fine. So.. what is it, now?
 
One more question regarding NAND dumps: I believe it was profi who said that the dump generated by Gateway's (and the other's) Launcher.dat is actually altered in some way, and therefore can't be used as a replacement to a "real" dump. However, I think somebody else also said they used a dump generated by Gateway's code, and it worked just fine. So.. what is it, now?

The NAND dump used for EmuNAND has a different encryption, however the dump generated by the "NAND backup" option is just a copy and can be used to reflash the 3DS NAND.

I don't fully understand the purpose of having different encryptions, I also recall users saying that they managed to inject a regular NAND backup to the emuNAND "partition" and it was successfully loaded by GW's launcher.
 
The NAND dump used for EmuNAND has a different encryption, however the dump generated by the "NAND backup" option is just a copy and can be used to reflash the 3DS NAND.

I don't fully understand the purpose of having different encryptions, I also recall users saying that they managed to inject a regular NAND backup to the emuNAND "partition" and it was successfully loaded by GW's launcher.

Alright, thank you for the information.
 
That shouldnt matter at all, the protocol isnt native to the raspberry ^^

I know, but according to the standard there is no SPI support in the latest eMMC controller... using 1bit mode is much harder than the SPI mode
 
Nevermind me.

Good job guys, hope mine gets bricked so I can use my raspberry for anything besides a streaming box xD
 
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum