A standard NAND.bin backup won't do if the NAND chip itself is borked and doesn't detect properly due to a memory controller wipe. Can you elaborate on how you plan on fixing that issue?
A standard NAND.bin backup won't do if the NAND chip itself is borked and doesn't detect properly due to a memory controller wipe. Can you elaborate on how you plan on fixing that issue?
Fixed, see my previous post
Apparently you're supposed to send some sort of Erase/reset command to the eMMC chip which will fix the issue but delete everything on the NAND in the process. Of course you'll need your NAND.bin after that to fix it. There is another way that doesn't require a NAND.bin, which is to properly unlock the eMMC, but that requires a key that ATM only Gateway knows. This is my understanding from the 3DS xl NAND backup thread.A standard NAND.bin backup won't do if the NAND chip itself is borked and doesn't detect properly due to a memory controller wipe. Can you elaborate on how you plan on fixing that issue?
Arras
You are correct. It's precisely what most think is possible.
The original purpose of the eMMC protection is to prevent someone who doesn't know the passkey from viewing it's contents.
As a backdoor, you can remove the lock with a force erase that makes you start with a fresh unlocked device (totally erased)
They also seem to have enabled the write protection.
That one is tricky. You can write protect an eMMC permanently without a way to recover.
Since you can't write..you can't disable the protection...
As gateway says they can recover your 3ds, I don't think permanent write protection is active, but people who start to experiment with the low level commands
should be aware that the command exists, and an eMMC chip isn't even usefull as doorstop.
Let's hope someone is capable to reverse the way gateway calculates it's passkey.
The eMMC CID probably can be extracted from the eMMC with the proper low level commands (even in locked state) I also read the 3ds AES encryption is used. Can another AES encryption library being used instead? I read that the gateway backups are reencrypted with other gateway specific keys, so they can't be used to reflash the eMMC. Does that means that only a backup taken with a sd card reader can be used? In such case, I doubt many people have such a backup?
You are correct. It's precisely what most think is possible.
The original purpose of the eMMC protection is to prevent someone who doesn't know the passkey from viewing it's contents.
As a backdoor, you can remove the lock with a force erase that makes you start with a fresh unlocked device (totally erased)
They also seem to have enabled the write protection.
That one is tricky. You can write protect an eMMC permanently without a way to recover.
Since you can't write..you can't disable the protection...
As gateway says they can recover your 3ds, I don't think permanent write protection is active, but people who start to experiment with the low level commands
should be aware that the command exists, and an eMMC chip isn't even usefull as doorstop.
Let's hope someone is capable to reverse the way gateway calculates it's passkey.
The eMMC CID probably can be extracted from the eMMC with the proper low level commands (even in locked state) I also read the 3ds AES encryption is used. Can another AES encryption library being used instead? I read that the gateway backups are reencrypted with other gateway specific keys, so they can't be used to reflash the eMMC. Does that means that only a backup taken with a sd card reader can be used? In such case, I doubt many people have such a backup?
So all developers of the board, who were previously categorized as "mere speculators", are now "evil clone engineers".
I am sick of these insults to the profession.
I am sick of these insults to the profession.
As to why there is an unlock code (for the bricked consoles) it would be reasonable to assume that in order to test the code the Gateway staff had to trigger it multiple times and could not justify throwing away a console each time and therefore they required a means to repair their own console bricks - hence their amazing, miraculous ability to fix a problem they claim never to have actually seen in person.
The code may have been intended as a way to scare people towards their products but the fallout problem resulting from the Normatt launcher bricks has clearly shown the problem is not with the clone hardware but with Gateway's own code and may well have scared more customers away.
At the very least more people will be wary of them in future. This is especially true given the sneaky way they made the bricking event happen in a somewhat random delayed fashion. What if their next code has a much longer delay? How can we be sure unless the source code is revealed?
Also, has anyone else taken note that they still have not clearly and directly denied writing the bricking code. If they did not as many still seem to believe why do they not just say so? Taking the 'We neither confirm nor deny' route makes them seem like slimy politicians, and makes their 'guilt' seem far more likely. Perhaps they would like to deny but don't because they are afraid some one will actually post the code in question and reveal their untruth in the matter?
Personally though, I would rather have an admission, or a clear denial.
The code may have been intended as a way to scare people towards their products but the fallout problem resulting from the Normatt launcher bricks has clearly shown the problem is not with the clone hardware but with Gateway's own code and may well have scared more customers away.
At the very least more people will be wary of them in future. This is especially true given the sneaky way they made the bricking event happen in a somewhat random delayed fashion. What if their next code has a much longer delay? How can we be sure unless the source code is revealed?
Also, has anyone else taken note that they still have not clearly and directly denied writing the bricking code. If they did not as many still seem to believe why do they not just say so? Taking the 'We neither confirm nor deny' route makes them seem like slimy politicians, and makes their 'guilt' seem far more likely. Perhaps they would like to deny but don't because they are afraid some one will actually post the code in question and reveal their untruth in the matter?
Personally though, I would rather have an admission, or a clear denial.
Supposedly 48 hours until the new v 2.0 update is released. Official email from gateway.
Attachments
If they really wanted to release it during the next 48 hours, they would have said something like: "Be patient, our 2.0 update will be here till tomorrow".
But they didn't..
But they didn't..
More like for gateway to regain the trust of the clone cards' customers.
From at least what I've seen the odds of a brick from a gateway card are incredibly tiny though not quite non-existent.
If their 2.0 launcher needs a new fw and the fw doesn't work with ~2.0b1 launcher, It'll be a dilemma...
Hope they could remove the bricker code completely, they really don't need to do that.
At least, they don't need brick consoles like they are doing now, a "regular" brick is difficult enough to people, they won't open their consoles again and again just for saving $100.
Hope they could remove the bricker code completely, they really don't need to do that.
At least, they don't need brick consoles like they are doing now, a "regular" brick is difficult enough to people, they won't open their consoles again and again just for saving $100.
Why on earth anyone would want GaryOPA to be the face of their technical support is beyond me. The guy comes across like a child in every thread he's made about this.
I don't understand that part of emuNAND being encrypted different? I thought people with NAND-SD interfaces were able to write the emuNAND extracted with the "EmuNAND tool" to the NAND of the 3DS.
I'm very indifferent to all of this, mainly because my 3DS XL is still perfectly fine *knock on wood* I'm not launching the DS Profile until 2.0, so I'm perfectly content using the blue card and playing a little Pokémon Brown until that happens.
I don't believe 2.0 will be released in two days' time, mainly because of their wording in that screenshot e-mail -- specifically their use of the words "something" and "most likely." If they were releasing 2.0, they would've done something along the lines of what LegendaryFighter said a few posts up. Gateway is known to make a huge deal of their releases, so the fact they're not doing that right now is even more reason to believe the 2.0 update is still pending, and will stay that way for a while.
I really hope I'm wrong, but I don't think I am.
I don't believe 2.0 will be released in two days' time, mainly because of their wording in that screenshot e-mail -- specifically their use of the words "something" and "most likely." If they were releasing 2.0, they would've done something along the lines of what LegendaryFighter said a few posts up. Gateway is known to make a huge deal of their releases, so the fact they're not doing that right now is even more reason to believe the 2.0 update is still pending, and will stay that way for a while.
I really hope I'm wrong, but I don't think I am.
Similar threads
-
-
-
-
-
@
Xdqwerty:
it says it only works for the original R4, R4i Gold (r4ids.cn), R4iDSN (r4idsn.com) and Acekard R.P.G. -
-
-
-
-
-
@
Psionic Roshambo:
Just give it a try, but honestly if you have a 3DS you can play DS games without a card just off the internal SD card -
-
-
-
-
-
-
-
-
-
-
-
I @ I-need-help-with-wup-wiiu:i know this isn't the place but does/did anybody have the same issue as me?
-
-
