rofl, are people complaining because someone is offering a service for money ?
Communist Russia fell a while ago people
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 itI 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.
The code is GPL, he's perfectly free to make money off it.
O_____> enjoy
O
Now everyone have the proof for the brick code. The eMMC controller doesn't lock itself by "magic".
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.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
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)
@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.
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?
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 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)