Hacking Has anyone with a brick been able to recover?

[obcd]

I didn't really study much deeper into it. Let's say for this cases, it's good news.
Are you from dutch or french site of our country? (Sorry for the off topic)

 

[djgarf]

Possible that the trigger for the Bricking code has been in the Gateway launcher as to why Official bricks are occurring

and relates to any file on the SD card being dated 4th Feb 2014 or later
so if someone either has a file with that date on there SD card or Puts Forward there Internal clock (for play coin cheating) thus when the 3DS next saves to the SD it creates a file with the date 4th Feb or Later then a Brick could occur

possible Kill Code found

0x10410,0x10) MMC_SET_BLOCKLEN
 
0x50c1b,0) //PROGRAM_CSD
 
0x50c2a,0x0) setpass
 
0x10410,0x200) MMC_SET_BLOCKLEN

this maybe a stupid question but from that bit of code how does it know what password to use for locking
also why is it setting the block length twice?

 

[gamesquest1]

ooops looks like i would of been a possible candidate for getting a brick if thats true, my ds is in 2015 by now i think do you really think that everyone who bricked had the dates forward past feb 2014....seems a bit unlikely but you never know​

​

also does this kinda mean they might of had a set time they where planning to release the official update, leaving all the clones with the bomb after they release knowing they would not have the launcher edited in time to avoid the bomb going off​

 

[krisztian1997]

this maybe a stupid question but from that bit of code how does it know what password to use for locking
also why is it setting the block length twice?

According to the eMMC standard, you have to set the blocklen to the size of the password then if you want to send any data to write to the nand you have to set it back to the 512 bytes which is a block on the nand but the password is missing... that's why I asked for full code

 

[djgarf]

According to the eMMC standard, you have to set the blocklen to the size of the password then if you want to send any data to write to the nand you have to set it back to the 512 bytes which is a block on the nand but the password is missing... that's why I asked for full code

ah rite

that makes more sense

 

[olfa]

some ideas for emmc from others

http://yifan.lu/2014/01/11/dumping-the-vita-nand/

interesting part
<quote>
I had three SD card readers and the third one worked! I know that that reader can operate in 1-bit mode, so I took it apart and connected it to the Vita (CLK, CMD, DAT0, and ground).
</quote>
-> seems like we could use 1-bit mode with a good sdcard reader

 

[Cyberdrive]

some ideas for emmc from others

http://yifan.lu/2014/01/11/dumping-the-vita-nand/

Use Google Translate in "View Original" mode to gain access to the site if it's unreachable.
Based Roskomnadzor. I wonder how much Sony paid them to protect Russians from this highly dangerous information.

By the way, I'm not sure whether Gateway-made NAND dump can be flashed back with hardware flasher. I heard that it's encrypted and I'll post any evidence I can find here. If it's true, Forced Erase won't be of much use and bruteforcing 1 out 256^16 combinations isn't exactly exciting prospect. Hopefully password-generating algorithm will be reverse engineered.

False alarm, Gateway-made NAND dump CAN be flashed back with hardware flasher:

But i have my older firmware dumped thru Gateway and saved on my computer! I have tested the soldering points with an multimeter and everything seems good, but my computer doesnt fins my nand????

YEAHHHH! I got it working and successfully flashed back to my old 4.50 CLK was connected to pin 4 instead of 5 on my sd adapter

 

[krisztian1997]

Use Google Translate in "View Original" mode to gain access to the site if it's unreachable.
Based Roskomnadzor. I wonder how much Sony paid them to protect Russians from this highly dangerous information.

By the way, I'm not sure whether Gateway-made NAND dump can be flashed back with hardware flasher. I heard that it's encrypted and I'll post any evidence I can find here. If it's true, Forced Erase won't be of much use and bruteforcing 1 out 256^16 combinations isn't exactly exciting prospect. Hopefully password-generating algorithm will be reverse engineered.

False alarm, Gateway-made NAND dump CAN be flashed back with hardware flasher:

It can be flashed back even after gateway bricking ?

 

[Cyberdrive]

It can be flashed back even after gateway bricking ?

Not on a Gateway brick "as is", but when/if it's switched to a writable state; these posts were made before the whole Gatewaygate and they confirm that NAND dumps made by Gateway are usable for recovery just as well as ones made using hardware mod.

 

[ryuga93]

Finally!My SDHC is unbricked!The force erase code success! Thanks to krisztian1997 for the code. Now for code optimising and getting a bricked 3ds to test. Here's the serial monitor and the erase code.

static    uint8_t erase()
    {
                    uint8_t response,i,r;
                    uint8_t arg = 0x08;
                    uint8_t command = 0x2a;
                    uint16_t crc = calc_crc(mess,((command&arg)|command),CRC16STARTBIT);
                    sd_raw_rec_byte();
                    Serial.print("Starting erase procedure");
                    select_card(); // select SD card first
                    sd_raw_send_command(CMD_CRC_ON_OFF, 0);
                    if(sd_raw_send_command(CMD_SET_BLOCKLEN, 1))
                    {
                            Serial.print("IMPOSIBLE TO SET_BLOCKLEN to 1 byte\n");
                            unselect_card();
                            return 0;
                    }else{
                            Serial.print("SET_BLOCKLEN to 1 byte\n");
                    }
                r=sd_raw_send_command(CMD_LOCK_UNLOCK,0);
                Serial.println(r);
                sd_wait_for_data();
                xchg(0xfe);
                    xchg(arg);                            // ignore dummy checksum
                    xchg((crc >> 8) & 0xff);       
                    xchg((crc >> 0) & 0xff);   
                    sd_wait_for_data();
    }

 

[jochem77]

Finally!My SDHC is unbricked!The force erase code success! Thanks to krisztian1997 for the code. Now for code optimising and getting a bricked 3ds to test. Here's the serial monitor and the erase code.

I have an Arduino Starter Kit and a bs 3DS, but no experience in soldering. Can you please tell me what to do, so I can participate on finding the solution.

 

[bkifft]

Finally!My SDHC is unbricked!The force erase code success! Thanks to krisztian1997 for the code. Now for code optimising and getting a bricked 3ds to test. Here's the serial monitor and the erase code.

in which cardstate do you isssue it? in other words: after which initialization command sequence?

CMD0 until reply idle, CMD1 untill not idle, CMD13 ? or something else?

 

[krisztian1997]

in which cardstate do you isssue it? in other words: after which initialization command sequence?

CMD0 until reply idle, CMD1 untill not idle, CMD13 ? or something else?

After the ATmega wakes up, wait 80 cycles for card to wake up, tell it to reset, wait for idle response, send 0x08 to test for MMC/SD/SDHC, send ACMD41 and test if the card is ready and prepared for operations, switch to 1 byte block mode, send the erase command, send the crc, and send dummy data to receive dummy data untill we get the response, but never switch to high frequency while doing the erase command, for some weird reasons it freezes then.

 

[bkifft]

After the ATmega wakes up, wait 80 cycles for card to wake up, tell it to reset, wait for idle response, send 0x08 to test for MMC/SD/SDHC, send ACMD41 and test if the card is ready and prepared for operations, switch to 1 byte block mode, send the erase command, send the crc, and send dummy data to receive dummy data untill we get the response, but never switch to high frequency while doing the erase command, for some weird reasons it freezes then.

so CMD42 doesn't require an RCA address? it's a broadcast command? nice.

(edit: shouldn't poste before having my coffee... "RCA address".... just like MMX extension, CD disk and RAM memory....)

 

[krisztian1997]

so CMD42 doesn't require an RCA adress? it's a broadcast command? nice.

Wait, I forgot to mention that the card needs to be selected before working with it... sorry

 

[Mr_Pichu]

Someone should upload the complete set of source code files to github so this knowledge can be shared with all who need it. Cheers to the gbatemp community for coming together in this time of crisis. The scene is safer, thanks to your combined efforts. Can't wait to see if a bricked 3DS can be restored.

 

[krisztian1997]

Someone should upload the complete set of source code files to github so this knowledge can be shared with all who need it. Cheers to the gbatemp community for coming together in this time of crisis. The scene is safer, thanks to your combined efforts. Can't wait to see if a bricked 3DS can be restored.

I can do it when I receive the code from ryuga and do some testing on my SD cards, to see if the card is 100% safe

 

[bkifft]

Wait, I forgot to mention that the card needs to be selected before working with it... sorry

select as in CMD7 (with argument RCA<<16) or as a side effect of another command?

 

[krisztian1997]

select as in CMD7 (with argument RCA<<16) or as a side effect of another command?

This is from the code:

select_card() PORTB &= ~(1 << PORTB2)
unselect_card() PORTB |= (1 << PORTB2)

For selecting card I think its makes the line CS high, and for unselecting it makes it low.

 

[bkifft]

This is from the code:

select_card() PORTB &= ~(1 << PORTB2)
unselect_card() PORTB |= (1 << PORTB2)

For selecting card I think its makes the line CS high, and for unselecting it makes it low.

ahh kk, so the "single card on bus" selection. (i tend to allways think way to complicated...)

thx