Hacking WARNING - Gateway team bricks card ON PURPOSE!

[juins]

1/billion??? serious thats the whole fuss??

anyway, I just use the 3.s FW because the save files from 3.2 are not compatible with 3.3

Really? 3.3 savefiles arent compatible with 3.2 and viceversa?

 

[juins]

1/billion??? serious thats the whole fuss??

anyway, I just use the 3.s FW because the save files from 3.2 are not compatible with 3.3

Really? 3.3 savefiles arent compatible with 3.2 and viceversa?

 

[mr. fancypants]

yes i tested it with bravely default and the save was corrupted

 

[hiron]

You are all missing the point, it's not the launcher.dat file itself that is checked, but parts loaded from it. For instance the main bricking code will check the hash of the ARM9 payload in memory, which on its own can be corrupted even though the SD card is not. (You are loading this through an exploit, itself loading through a large ROP chain, that's hardly what one could call a safe and fully controlled environment)
Why do you think even gateway 2.0b2 won't load 100% of the time?

Ahah so its more dangerous then initial thought for even GW users? Atleast thats what I get out of it.

 

[KazoWAR]

Don´t blame GW team, they are protecting their work, blame other clones who doesn´t test "their" firms and only wants easy money...
They will not save you

but, a bad sd card, corrupted file download, fuck, even buggy code will cause this to trigger on a real GW card. Bricking the console is never a good idea. it would be better to do some of the stuff listed below.

• Corrupt ROM data on microSD card.
• Cause loader to go into a infinite loop (AKA FREEZE);
• Delete Launcher.dat and then power off the system.
• Show a message of some kinda before doing any of the above.

the list can go on, but you get the idea. there are many ways to stop your code from running on wrong firmware without bricking someone's fucking console. fuck maybe they never herd of your shitty card and got the r4 one because its a brand they recognize.

 

[escherbach]

OK - I want a disassembly of the arm code that does the actual eMMC reprogramming - shouldn't be too complicated if they are just setting a few registers to zero.

Forget the rest for now (random number test, checksum) - just THAT piece of code would be enough evidence for me.

I want the address offset too btw.

Otherwise those german guys are bull-shitting

 

[minexew]

but, a bad sd card, corrupted file download, fuck, even buggy code will cause this to trigger on a real GW card. Bricking the console is never a good idea. it would be better to do some of the stuff listed below.

Sure, but none of those would send the message that "clone cards are dangerous", which I assume was Gateway's intent.

 

[inuyasha555]

Sure, but none of those would send the message that "clone cards are dangerous", which I assume was Gateway's intent.

Exactly. They'll simple message the team and hope they find out what's wrong and remove it. Bricking it shows that you buy clone carts, you deserve what's coming to you. Especially if they steal others work.

 

[Viaggiatore]

Quoted because some people cant read or understand...

You are all missing the point, it's not the launcher.dat file itself that is checked, but parts loaded from it. For instance the main bricking code will check the hash of the ARM9 payload in memory, which on its own can be corrupted even though the SD card is not. (You are loading this through an exploit, itself loading through a large ROP chain, that's hardly what one could call a safe and fully controlled environment)
Why do you think even gateway 2.0b2 won't load 100% of the time?

I just checked my MD5, it is different then the one I saw here, mine is 793daccb186f329085bdce76cb61f390. I wonder from where my launcher.dat is coming from, maybe the one you have after having prepared the SD for emuNAND is different? I checked the one it's inside the zip from GW site and that one is correct. Oh, so far so good with the 793daccb186f329085bdce76cb61f390 one... go figure. So I guess this confirms what you wrote, launcher.dat MD5 is not checked at all.

EDIT: option 2, maybe this means not bricking code in launcher.dat?

 

[alirezay]

what if they failed to make multirom and just released mtcard and they want to sell more by doing this?

 

[Joe88]

The fear mongering in this thread with no proof

 

[justinkb]

Every second the "evidence" - that should be trivial to share - is withheld, strengthens my suspicion that this is a clever ploy from MT card team, which would then necessarily contain several well known members of these forums. We know from earlier occurrences that some of them, while skilled technically, aren't too bright (photographing and sharing on flickr evidence of facilitation of piracy) when it comes to keeping their illegal activities a secret.

 

[hiron]

Sure, but none of those would send the message that "clone cards are dangerous", which I assume was Gateway's intent.

So its ok to potentially brick their own users just to send a msg to the clones? Guess its the same for gw and clones. Money above everything else huh?

 

[feebmc]

For Mathieulh, people have clearly missed the point here that it is extremely unlikely that the rop chain is going to get randomly corrupted (at an SD level) and still function. The question is how stable is the payload? We know that the prior Gateway version wasn't particularly stable (it crashed in the past though at an early stage, which should have been safe) but the new one hasn't caused any obvious issues and I suspect it was introduced in this beta due to the perceived stability of the payload from the gateway team. That being said I don't have the ability to do memory dumps and try and evaluate whether the Payload is stable or what the odds are of it randomly loading to the point that it is still corrupted but functional enough for the exploit to work?

I get the feeling that it is extremely low and the Gateway team have spent a long time working on this hence the delay in the final 2.0. Does anyone with the actual ability have the time to speculate on possible ways that the ROP chain could load to the point it is functional and the user has no idea but still fails the hash and runs the risk of bricking.

I have to say I hope that in the next version the Gateway team make the anti-clone check a bit more advanced (although I am making assumptions they haven't put in or considered certain safety checks that would make the odds of a legit gateway payload bricking, like winning the lottery).

 

[minexew]

So its ok to potentially brick their own users just to send a msg to the clones? Guess its the same for gw and clones. Money above everything else huh?

Dude don't ask me.

 

[BMinkie]

The fear mongering in this thread with no proof

thank you all these ppl are fucken nuts

 

[minexew]

Every second the "evidence" - that should be trivial to share - is withheld, strengthens my suspicion that this is a clever ploy from MT card team, which would then necessarily contain several well known members of these forums. We know from earlier occurrences that some of them, while skilled technically, aren't too bright (photographing and sharing on flickr evidence of facilitation of piracy) when it comes to keeping their illegal activities a secret.

And where's your proof of that?

 

[Wisenheimer]

Don´t blame GW team, they are protecting their work, blame other clones who doesn´t test "their" firms and only wants easy money...
They will not save you

You know, there is a reason why it is illegal in most places to set booby traps. Innocent people often end up getting hurt. In this case, if it is true, the company is basically selling a product to their customers without their consent or knowledge that it contains a booby trap to vandalize their $200+ hardware product that could be set off by a bad electrical connection or a stray high-energy photon.

If they were in the US, you can bet that not only would they be held liable in civil court for damaging their customers' property (assuming the accusation is true), but there exists the possibility of criminal vandalism charges and prison time.

There is a huge difference between anti-piracy measures that shut down the software (anti-piracy being ironic, since the primary intent of the Gateway team seems to be to enable piracy, not legitimate home brew) and anti-piracy measures that damage customers' property.

 

[minexew]

...
Does anyone with the actual ability have the time to speculate on possible ways that the ROP chain could load to the point it is functional and the user has no idea but still fails the hash and runs the risk of bricking.
...

Mechanical card reader glitch during the loading of ARM9 payload? Dunno, just an idea.

 

[Deleted User]

For Mathieulh, people have clearly missed the point here that it is extremely unlikely that the rop chain is going to get randomly corrupted (at an SD level) and still function. The question is how stable is the payload? We know that the prior Gateway version wasn't particularly stable (it crashed in the past though at an early stage, which should have been safe) but the new one hasn't caused any obvious issues and I suspect it was introduced in this beta due to the perceived stability of the payload from the gateway team. That being said I don't have the ability to do memory dumps and try and evaluate whether the Payload is stable or what the odds are of it randomly loading to the point that it is still corrupted but functional enough for the exploit to work?

I get the feeling that it is extremely low and the Gateway team have spent a long time working on this hence the delay in the final 2.0. Does anyone with the actual ability have the time to speculate on possible ways that the ROP chain could load to the point it is functional and the user has no idea but still fails the hash and runs the risk of bricking.

I have to say I hope that in the next version the Gateway team make the anti-clone check a bit more advanced (although I am making assumptions they haven't put in or considered certain safety checks that would make the odds of a legit gateway payload bricking, like winning the lottery).

Not only that.

All this time Gateway 2.0b2 was out, we heard of how many bricks so far? I mean really confirmed that were not R4i shills? Considering the number of Gateways out there and this little amount of noise from ACTUAL GW USER BRICKS that says something. The noise is coming from R4i and 3DSLink users. I'll let the statistics speak for themselves.

Also, as GW Team says, they test their Launcher.dat THOROUGHLY. I mean wouldn't you if you had (supposedly) bricker code in there? You dont want to hit legit customers and from the little to no noise we hear from GW customers.. I think their code is pretty safe all things considering.