So many things is wrong in that sentance...When I was in 10.3 version i backed up my nand.bin with gateway ultra.
yeah thats pretty much what i said , if you have the plaintext of the specific offset off the file you intend to fix then you can make an xorpad but for most people who brick they almost certainly wouldn't know exactly what it was they flashed to brick nor where the 3DS would have stored it on the nand, plus with some bricks being caused by the installation of o3ds titles on a n3ds or vise versa i doubt anyone truely could be bothered trying to map out/predict where exactly a bunch of system titles would be stored, basically as a theoretical thing sure there is a certain level of possibility, but practically for the kinds of people who screw up their sysnand and haven't even made a nand backup i would take a leap and say it would be way too much effort with no promise of resultsActually, it's possible (although troublesome) to do more than this, simply because of a weakness in the 3DS encryption scheme.
Thus, if you can predict BOTH the sector where information is stored, and can cause the 3DS to store known values there (or otherwise know the expected data), you can update it. Here's why (just XOR'ing both sides by the same value to get to next lines):
- NAND is divided into well-known partitions
- Each sector of each partition will have a constant XorPad
- The data stored in that sector is OLDDATA ^ XORPAD
- If you want to store new data in that sector, result will be NEWDATA ^ XORPAD
Put another way, the XORPAD is exposed when the sector and expected data are known:
- X ^ X == 0
- oldEncryptedSector ^ UpdateXor == newEncryptedSector
- OldData ^ XorPad ^ UpdateXor == NewData ^ XorPad
- OldData ^ UpdateXor == NewData
- UpdateXor == NewData ^ OldData (no XorPad value needed)
Thus, if you know post the sector number where the information is stored, and the cleartext data, you can trivially update it. Since the firmware partitions store everything at a known offset, the XorPad can be reconstructed.
- OldEncryptedData ^ XorPad == ClearData
- OldEncryptedData == ClearData ^ XorPad
- OldEncryptedData ^ ClearData == XorPad
In contrast, the CtrNand partition uses a FAT16 file system, allowing files to be stored in nearly any sector. Thus, it's much harder to RE the xorpad using only the encrypted data (+ analytics on expected data + which bits change when), especially where the file system operations are not easily controlled from user-mode apps.
There is no need for a video. Native_Firm wasn't updated.It's reported to work with the 10.6 but has anyone here tried it? Can you make a video demonstrating it works with the latest update i.e. 10.6? In your free time of course.
There is no need for a video. Native_Firm wasn't updated.
I listened that it bas been patched, am I wrong ?http://yls8.mtheall.com/3dsbrowserhax.php , you can bypass it now...
"Where" did you listen because it's not and this fix was discovered yesterday...I listened that it bas been patched, am I wrong ?
Thx for answer
It work love u my dear !"Where" did you listen because it's not and this fix was discovered yesterday...
I have a bicked 3ds wich I don't know what firmware. When I turn it on the blue light flashes, but no screen and no sound.
Could I use this to modify a early firmware?
Probably 2.+
I meant 9.2U sorry...So many things is wrong in that sentance...
https://www.reboot.ms/forum/threads/downgrade-3ds-11-0-to-9-2-using-hardmod.2403/(Necrobump, sorry)
Would be in theory possible to use this method to "downgrade" from 11.0 to 10.7 and then use the regular method?