Hacking Gateway Brick Poll

[escherbach]

@escherbach:
There is in fact a ARM9 core inside the SoC. That the core is not listed on 3dbrew or in docs, doesn't mean it is not there. It is hidden for a reason and the reason is, because it is the security core. If you don't believe, look in the python tools for 3DS thread. They thought they run their code on ARM11 too, but then they found out, that's not the case.

And btw i don't know, what you want to proof with just coprocessors.

Well, arm9 code runs on arm11, you're probably confusing that with the actual existence of a physical arm9 cpu. In fact the checksum code would probably be pure arm9 anyway - unless they found a use for new arm11 simd instructions in the checksum routine

 

[diffikolt]

They might do it on purpose to temporarily prevent an accidental update of the real system nand when running updates in emunand - and then reset it back to its proper value after the emunand update.

How do you know the Gateway guys created the routine solely to destroy 4.x firmware consoles around the world?

Again, they wouldn't have written the eMMC to 0 bytes--there are countless other effective methods they could have taken that are FAR less dangerous.

Also, it wouldn't be triggered in the way it is (if hash does not match, brick). This has nothing at all to do with an update--only a check to see if the .dat has been altered in any way.

I wouldn't be surprised if Gateway attempted to use this as their excuse to quell complaints, but the fact of the matter remains--no matter what they say at this point, this was intentional.

 

[profi200]

@escherbach:
What's this then?
http://gbatemp.net/threads/python-tools-for-3ds.360101/page-6#post-4886008

Please read, before you post shit.

bbl

 

[escherbach]

Again, they wouldn't have written the eMMC to 0 bytes--there are countless other effective methods they could have taken that are FAR less dangerous.

Also, it wouldn't be triggered in the way it is (if hash does not match, brick). This has nothing at all to do with an update--only a check to see if the .dat has been altered in any way.

I wouldn't be surprised if Gateway attempted to use this as their excuse to quell complaints, but the fact of the matter remains--no matter what they say at this point, this was intentional.

The trigger code has not been confirmed at all - and in fact it definitely isn't triggered on a hash check - two posters on the recent long threads have confirmed that altering random bytes in launcher.dat doesn't cause a brick. One guy did it 30 times - so unless the random number check is really weak (ie only triggers in ~1% or less of cases ) - that confirms it'snot how it works. And gateway have posted on their site that people are 100% safe even in the case of corruption on their SD card.

SO, NO, there is no "brick()" function that is deliberately executed in order to destroy 4.x consoles around the world

 

[diffikolt]

You want to blame someone, blame the people that stole Gateway's code. It's only non-Gateway devices running Gateway code that are causing bricks. The only ones at fault are the ones that made Gateway clones, and they won't be selling any more of those clone cards now anyway.

I agree that it sucks for the people who got bricked, but you should be bitching at the people who made your card, not the ones they stole the code from. If you had been using a card that the code was actually designed to run with then you wouldn't have this problem.

They'll still sell them--they'll simply use older firmware or hire a halfway competent coder to comment out the hash check or remove it entirely. Then they'll continue to steal Gateways code.

One thing we know for a fact they won't do--write their own code.

 

[Zaide]

They'll still sell them--they'll simply use older firmware or hire a halfway competent coder to comment out the hash check or remove it entirely. Then they'll continue to steal Gateways code.

One thing we know for a fact they won't do--write their own code.

No, they'll TRY to sell them. Who's going to buy a flashcart that has bricked a console in the past?

 

[escherbach]

@escherbach:
What's this then?
http://gbatemp.net/threads/python-tools-for-3ds.360101/page-6#post-4886008

Please read, before you post shit.

bbl

In that thread Bond697 doesn't list a source for his claim that it's an armv5te arm946e-s processor - more likely the code was fixed (accidentally) by changing to tried and trusted DS compiling options for the old arm9 platform - rather than the 3DS suddenly developing a new arm9 chip magically

 

[jcipher]

No, they'll TRY to sell them. Who's going to buy a flashcart that has bricked a console in the past?

People that do not know and people that doesn't agree with Gateway's tactics. If resellers stop purchasing then they could end up with unsold inventory but who knows how things will turn out. They could always use a different name too.

 

[profi200]

@escherbach:
I really give up. If you can't see the fact's everywhere, then think, what you think. I run my code on ARM9 and 11 and can see the difference (speed).

If you don't believe all the people, then it's your problem.

 

[alligatormanx]

Here is my take, It is wrong the could not brick the clone devices but they could have imposed a penalty. What if instead of bricking it updated you to the latest firmware, deleted your saves, corrupting the card itself so that you had to keep reinstalling the information on the card. I bet the card has the ability to update you to the latest firmware if it wanted to and it could probably easily delete your saves and put up a message informing you why.

A team that starts with the highest punishment should not be trusted.

 

[Cyberdrive]

I DO NOT own a flash card. Gateway never should have written brick code. They are completely in the wrong.

 

[dezmen]

Weird poll.

Gateway went a little too far bricking consoles--they should have only bricked clone devices.

Nice to see that people vote for this, showing how shitty they are. GW users bricked their devices too Good job GW, kill your devices too.

 

[escherbach]

@escherbach:
I really give up. If you can't see the fact's everywhere, then think, what you think. I run my code on ARM9 and 11 and can see the difference (speed).

If you don't believe all the people, then it's your problem.

I've explained to another uninitiated person that the build.py script targets a multi-core arm11 processor ( -march=armv6k ) - you're so far from speaking sense that you're not even wrong

http://gbatemp.net/threads/python-tools-for-3ds.360101/page-7#post-4887490

 

[Arras]

The trigger code has not been confirmed at all - and in fact it definitely isn't triggered on a hash check - two posters on the recent long threads have confirmed that altering random bytes in launcher.dat doesn't cause a brick. One guy did it 30 times - so unless the random number check is really weak (ie only triggers in ~1% or less of cases ) - that confirms it'snot how it works. And gateway have posted on their site that people are 100% safe even in the case of corruption on their SD card.

SO, NO, there is no "brick()" function that is deliberately executed in order to destroy 4.x consoles around the world

There's two checks. If the first fails, the launcher doesn't run. If the second fails, brick chance. The clone teams patched the first one but didn't realize the second existed. That's how people just changing random bits have no issues.

 

[McHaggis]

I DO NOT own a flash card. Gateway never should have written brick code. They are completely in the wrong.

Same here. I own none of the above, and never intended to purchase any either. I believe Gateway's actions are terrible.

 

[sudeki300]

has any member of the gateway team actually said or posted that they did in fact write a brick code into the launcher.dat / gateway firmware, as i cannot find any mention of this from a member of the gateway team. if any one has a link to this news please post it here................................sudeki300

 

[Technicmaster0]

has any member of the gateway team actually said or posted that they did in fact write a brick code into the launcher.dat / gateway firmware, as i cannot find any mention of this from a member of the gateway team. if any one has a link to this news please post it here................................sudeki300

I havn't heared of an official confirmation, too but they didn't denie it and I trust Profi200 and Yellows8.

 

[sudeki300]

I havn't heared of an official confirmation, too but they didn't denie it and I trust Profi200 and Yellows8.

sorry for being a bit thick and coming late to the party, but what has Profi200 and Yellows8 found. there are just too many threads of this to try and find the posts................................sudeki300

 

[escherbach]

There's two checks. If the first fails, the launcher doesn't run. If the second fails, brick chance. The clone teams patched the first one but didn't realize the second existed. That's how people just changing random bits have no issues.

Yes I've seen this claim - and it is an explanation. But one of the people posting the claim - profi200 doesn't even seem to know that gcc compiler option "-march=armv6k" targets an arm11 cpu - so credibility is lacking for me. Also, late in the day he claims it's difficult to follow the code because of obfuscation - I would have thought this would have been mentioned right at the start - Gateway would surely have to use code obfuscation or encryption to get away with such a devious scheme.

It seems more reasonable to me that they are trying to prevent accidental firmware updates on the 3DS when you exit emunand - and have come up with a technique to reprogram the eMMC which is a bit flaky.

 

[Technicmaster0]

sorry for being a bit thick and coming late to the party, but what has Profi200 and Yellows8 found. there are just too many threads of this to try and find the posts................................sudeki300

They found one code that writes the 3DS' NAND to 0 and reprogramms the eMMC and they found the code that triggers the action. But I'm not sure what else they found since I wasn't able to visit the IRC. I havn't read every thread, too