Hacking 3DS unbricking progress

[Vappy]

The code is GPL, he's perfectly free to make money off it.

 

[pokefan92]

rofl, are people complaining because someone is offering a service for money ?
Communist Russia fell a while ago people

I think it's fair that gets money those who are working in the solution for the masses, not people that use the free work of others.

Well, I don't have nothing more to say. I don't want to continue this offtopic.

 

[gamesquest1]

I think it's fair that gets money those who are working in the solution for the masses, not people that use the free work of others.

Well, I don't have nothing more to say. I don't want to continue this offtopic.

anyone who uses the code even for themselves is benefiting from someone elses work, if i do actually fix any consoles and made a bit of money i would certainly offer some to the coder who made the code i used.......much the same as you should offer something to the person who is unbricking your console....the code is nothing without someone to use it

 

[bkifft]

The code is GPL, he's perfectly free to make money off it.

what he said. i even created an elololololololoterado (or something along the lines) account to voice that.

the request i made in the project readme still stands, though.

 

[gamesquest1]

O_____> enjoy
O

 

[bkifft]

O_____> enjoy
O

ASCII art is not a drawing in my opinion and this is not my email account, but none the less thanks for your effort ;P

 

[escherbach]

Now everyone have the proof for the brick code. The eMMC controller doesn't lock itself by "magic".

You still don't get it. Gateway themselves announced they were working on code to prevent sysnand updates - this would undoubtedly involve locking nand writes via eMMC controller reprogramming.

The question is - why was this code released in 2.0b2 when they stated it was too dangerous? It may have been deliberately left there as dead code - so it is never called in original Gateway firmware - and then you would have a convincing argument that clone firmware was accidentally enabling the code by editing the launcher code in a crude manner. BUT the argument doesn't work since it doesn't explain how genuine GW cards with UNMODIFIED firmware are also getting bricked.

I have no doubt that the bricks are caused by eMMC commands - but I have doubts that Gateway have a deterministic algorithm which tests for modifications and then deliberately reprograms the controller.

The fact that genuine GW users are getting bricks points to incompetently tested code by Gateway - that is causing same % of bricks with GW cards as with clones.

It's hard to know without accurate figures. If it was only 1% GW cards and 99% clones then one might argue that the Gateway checksum test is incompetently implemented so that it fails in corner cases even on genuine gateway firmware.

Congrats to the people who got this "fix" working - but a reset of the nand is not rocket science tbf - at least not once you've got the hardware interface set up (which is a nice piece of work by all involved - no mean feat)

 

[helpwith3ds]

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

Hoping a way to unbrick without a NAND dump too. There's probably others in the same boat that choose not to post here. Fingers crossed.

 

[Mr_Pichu]

I have started going through the PIC chip selection guide looking for a good fit. There are number of SD Card projects built with PIC chips. An unbricking solution could be built with an inexpensive PIC chip. For bonus points, with the addition of a microSD a restore feature could be possibly implemented.

http://www.microchip.com/forums/m530149.aspx

There are so many hungry Pichus to feed, a Pichu can't get by on being cute alone. This Pichu makes money by providing an open-source solutions consultancy, so I can buy apples for me and all my other Pichu friends.

 

[profi200]

@escherbach:

Seriously, just fuck off. You have no idea, what you talk about. To make the NAND write protected you don't need the lock feature at all and the firmware doesn't boot, if the write protection is enabled (it will just hang on boot with a blackscreen or display an "An error occured.." screen).

I don't discuss this with you here to keep the thread clean.

 

[Seqa]

You still don't get it. Gateway themselves announced they were working on code to prevent sysnand updates - this would undoubtedly involve locking nand writes via eMMC controller reprogramming.

The question is - why was this code released in 2.0b2 when they stated it was too dangerous? It may have been deliberately left there as dead code - so it is never called in original Gateway firmware - and then you would have a convincing argument that clone firmware was accidentally enabling the code by editing the launcher code in a crude manner. BUT the argument doesn't work since it doesn't explain how genuine GW cards with UNMODIFIED firmware are also getting bricked.

I have no doubt that the bricks are caused by eMMC commands - but I have doubts that Gateway have a deterministic algorithm which tests for modifications and then deliberately reprograms the controller.

The fact that genuine GW users are getting bricks points to incompetently tested code by Gateway - that is causing same % of bricks with GW cards as with clones.

It's hard to know without accurate figures. If it was only 1% GW cards and 99% clones then one might argue that the Gateway checksum test is incompetently implemented so that it fails in corner cases even on genuine gateway firmware.

Congrats to the people who got this "fix" working - but a reset of the nand is not rocket science tbf - at least not once you've got the hardware interface set up (which is a nice piece of work by all involved - no mean feat)

On Chinese online forums for 3DS roms and hacking there have been many more cases of clones bricking than original GW.I don't know if it's because clones are more popular here (they are certainly cheaper, almost Y100 cheaper.. a lot by Chinese standards).. Anyway, just browsing the first two pages you see numerous mentions of Link bricking and r4i Gold bricking...

Only 1 or 2 mentions of original GW bricking.

 

[t-master]

So was anyone able to unbrick a console bricked by an original Gateway card?

 

[escherbach]

@escherbach:

Seriously, just fuck off. You have no idea, what you talk about. To make the NAND write protected you don't need the lock feature at all and the firmware doesn't boot, if the write protection is enabled (it will just hang on boot with a blackscreen or display an "An error occured.." screen).

I don't discuss this with you here to keep the thread clean.

Gateway have been working on the code to prevent sysnand updates for months and still not got it right - they have openly posted this on their site.

So it is you who do not know what you are talking about if you think it is simple.

Don't post moronic opinions on public forums if you don't want them challenged - you're right that this thread shouldn't be about this but you and your lackeys decided to inject your nonsense (yet again) into the thread.

The fact that the eMMC controller has been reprogrammed doesn't mean it was done in a deliberate attempt to destroy people's consoles - there is the possibility it is accidental due to a bad algorithm that was not fully tested.

 

[phanteon]

as far as i understand such code is triggered based on the date of the console.
then what if i change the console's date to a time prior to 2.0b2's release?

 

[crazyace2011]

as far as i understand such code is triggered based on the date of the console.
then what if i change the console's date to a time prior to 2.0b2's release?

you could brick your console which is before the firmware was released which may trigger as being modified cause the date it was made and when its accessed is before that time. that just a theory

 

[crazyace2011]

what the fuck you guys have something against me?

no one knows what triggers the kill trigger in gateways launcher file so everyone has speculation as it seems as though my theory doesn't mean shit. all a bunch of hypocritical asses

 

[Armadillo]

I think crazyace meant, if you change your consoles date, to a date prior to the release of b2. Then the launcher might decide it's been tampered with, as the systems date will be before the creation date of the launcher.

As someone was asking what if they set the consoles date to before b2 came out, to stop the brick triggering.

 

[Mr_Pichu]

The question is - why was this code released in 2.0b2 when they stated it was too dangerous? It may have been deliberately left there as dead code - so it is never called in original Gateway firmware - and then you would have a convincing argument that clone firmware was accidentally enabling the code by editing the launcher code in a crude manner. BUT the argument doesn't work since it doesn't explain how genuine GW cards with UNMODIFIED firmware are also getting bricked.

I have no doubt that the bricks are caused by eMMC commands - but I have doubts that Gateway have a deterministic algorithm which tests for modifications and then deliberately reprograms the controller.

The fact that genuine GW users are getting bricks points to incompetently tested code by Gateway - that is causing same % of bricks with GW cards as with clones.

You raise some excellent points. I haven't considered the possibility that eMMC locking on the GW card software may be by design. While there is a clear difference of opinion on this point, the truth of the matter will eventually come out.

 

[Commoner]

You still don't get it. Gateway themselves announced they were working on code to prevent sysnand updates - this would undoubtedly involve locking nand writes via eMMC controller reprogramming.

The question is - why was this code released in 2.0b2 when they stated it was too dangerous? It may have been deliberately left there as dead code - so it is never called in original Gateway firmware - and then you would have a convincing argument that clone firmware was accidentally enabling the code by editing the launcher code in a crude manner. BUT the argument doesn't work since it doesn't explain how genuine GW cards with UNMODIFIED firmware are also getting bricked.

I have no doubt that the bricks are caused by eMMC commands - but I have doubts that Gateway have a deterministic algorithm which tests for modifications and then deliberately reprograms the controller.

The fact that genuine GW users are getting bricks points to incompetently tested code by Gateway - that is causing same % of bricks with GW cards as with clones.

It's hard to know without accurate figures. If it was only 1% GW cards and 99% clones then one might argue that the Gateway checksum test is incompetently implemented so that it fails in corner cases even on genuine gateway firmware.

Congrats to the people who got this "fix" working - but a reset of the nand is not rocket science tbf - at least not once you've got the hardware interface set up (which is a nice piece of work by all involved - no mean feat)

It is possible that the code to prevent accidental sysnand update was placed in as a function originally intended to be run through a menu icon so that the user could decide when to run it.

When the function started causing bricking issues they may just have removed the menu option and either accidentally or intentionally left the function in.

One can theorize that the code was left in just in case a sysnand update was started which would then trigger the function in ordered to try to block the update. Assuming this is the case, a rare bug could trigger a false positive which activates the function and causes the brick.

This theory should be an easy one to test for someone who has already bricked their console once and successfully repaired it. Just run a system update and if it bricks, we have our culprit. If it doesn't they can just restore and we have eliminated the possibility.

The function could also have simply been left in as dead code though. Programmers do that kind of thing frequently when they are time pressured to release before they are ready. Instead of cleaning up all the code, they just disable it so they don't waste time cleaning up code for the release, knowing full well that they will need to put it back in for the next release. In this case though some rare bug might trigger the function to run anyway even though the programmers believe there is no way the function can be coaxed into running.

 

[Vengenceonu]

Perfect timing as my Gateway comes tommorow