Hacking GW Team warns against modified launchers

  • Thread starter Thread starter sonic2756
  • Start date Start date
  • Views Views 44,536
  • Replies Replies 239
  • Likes Likes 2
So flashcard companies are now bricking devices to prove a point?

God Bless America handheld hacking scene.

Yellows8, neimod etc. please consider releasing the exploit atleast now?
No. There's exactly zero evidence that anyone was intentionally bricking 3DS consoles. What we do know for a fact is that the most recent firmware release for the 3DSLink and R4i was broken beyond a doubt, and it wouldn't be surprising to find that their releases prior to that didn't quite work as intended, either.

If there was some sort of time bomb built in to any launcher which modified Gateway's work, every single person using a clone cart would be reporting a brick. As in, a lot more people, even in this small community. You could argue that it was only built into the two most recent GW beta releases, but that would be hard to prove given how shaky 3DSLink/R4i firmware has been all on its own during that period.
 
As far as I can tell, any claims about deliberate sabotage from Gateway team causing this issue are unsubstantiated by any evidence.

I'm not sure what the motivation of those who are claiming this (willy-nilly) is, but I can take a few guesses, none of which reflect well on those accusers.


You are right on that account, so far, until the actual code causing the issue is found, we cannot claim the bricks to be intentional.
For now all I have found is a lot of checksums that seem at first glance not to do anything when hashes mismatch, though obviously they are here for a specific purpose, so far it's only speculation from my part that this may have something to do with the bricking, and as I've said, I could be wrong about this.

I would know for sure if I had more time to look into this issue, but I am rather busy with work lately so I won't be able to seriously mess with IDA until at least a week from now.
 
No. There's exactly zero evidence that anyone was intentionally bricking 3DS consoles. What we do know for a fact is that the most recent firmware release for the 3DSLink and R4i was broken beyond a doubt, and it wouldn't be surprising to find that their releases prior to that didn't quite work as intended, either.

If there was some sort of time bomb built in to any launcher which modified Gateway's work, every single person using a clone cart would be reporting a brick. As in, a lot more people, even in this small community. You could argue that it was only built into the two most recent GW beta releases, but that would be hard to prove given how shaky 3DSLink/R4i firmware has been all on its own during that period.

This is true. Until somebody comes up with solid evidence that there was any code in the launcher that is capable of bricking a 3DS, 3DSLink/R4i very well might be to blame for breaking GW's launcher and releasing it to the public in its broken state. But for now, I don't think we can even blame them until there's evidence. All the reports I've seen so far are either from 3DSLink/R4i users.
 
No. There's exactly zero evidence that anyone was intentionally bricking 3DS consoles. What we do know for a fact is that the most recent firmware release for the 3DSLink and R4i was broken beyond a doubt, and it wouldn't be surprising to find that their releases prior to that didn't quite work as intended, either.

If there was some sort of time bomb built in to any launcher which modified Gateway's work, every single person using a clone cart would be reporting a brick. As in, a lot more people, even in this small community. You could argue that it was only built into the two most recent GW beta releases, but that would be hard to prove given how shaky 3DSLink/R4i firmware has been all on its own during that period.


If there is any code causing the bricks, one could argue the people that set it in motion would be clever enough not to have it trigger all the time as to increase confusion.
That said, so far this is speculation. There is for sure something causing the eMMC corruption, it's only a matter of time before someone finds precisely what.
 
Wait, has anyone succeeded to restore then NAND with a backup?
If it is fixable, it could be a good lesson to learn or it would be a "punishment" which really hurts.
I read a thread in some Chinese forum, a guy said that he failed to restore because Windows says "no media inserted", that guy has soldering experience and asserts the connection is correct and he had changed over 2 types of card reader.
Couple days after the BSOD wave but no one report the successful restore yet, can't understand that.
 
j9d1iyw.png


Please :(


Either way, this whole business sounds shady as hell...
 
If there is any code causing the bricks, one could argue the people that set it in motion would be clever enough not to have it trigger all the time as to increase confusion.
That said, so far this is speculation. There is for sure something causing the eMMC corruption, it's only a matter of time before someone finds precisely what.
Exactly. The whole idea is a bit ludicrous altogether if you think about it. If Gateway had the ability to stop modified launchers from working, why would they put a time delay on that? They would just not work or brick from day one, thus stopping 3DSLink/R4i/any other competition from ever creating carts in the first place. Gateway would be the only game in town and everybody would be paying them, and them only, to play ROMs.

In contrast, at best, half of the people with bricks will be able to restore their systems using a backup NAND. And then half of those will go right back to the clone cart they were using before or a different clone cart. If this was all a part of some grand strategy from Gateway, it was very poorly thought out beforehand. Which leads me to believe that the chances of this being proven as fact are zero to none. It's wishful thinking on the part of the 3DSLink/R4i team to believe they can pin this on a malice from Gateway that we've never seen before. It's simply an unintended consequence of bad coding when attempting to adapt Gateway's launcher for their hardware. The error may exist in the Gateway beta firmware and has simply been exacerbated by 3DSLink/R4i's coding, or it may be something entirely of their own creation. As you said, we'll have to wait for greater minds to find the exact source of the issue.
 
IF (and a very big if) gateway does this on purpose, it is stupid and a brilliant move. Brilliant in a way they found a way to protect their problem, but stupid because they are narrowing their own market. The exploit can only run on a specific firmware, and if they are killing 3ds's with that firmware it would be incredible stupid. They should have put a timer on killing the fake cards or something, so those users end up buying gateway anyway.

but what I also can be the case:
gateway put some anti clone code in their launcher (that is maybe why there are more cheksums), with just the intention clone teams can't just copy the launcher (not bricking). Now the clone teams just copied the launcher and patched some of the code which went terrible wrong, causing memory corruption and bricking the 3ds's. In this case it isn't gateway's fault but the teams who are patching it wrong.

anyway, i am curious what is gonna be the case here.

are there any known cases which would brick gateway 3ds's?
 
Wait, has anyone succeeded to restore then NAND with a backup?
If it is fixable, it could be a good lesson to learn or it would be a "punishment" which really hurts.
I read a thread in some Chinese forum, a guy said that he failed to restore because Windows says "no media inserted", that guy has soldering experience and asserts the connection is correct and he had changed over 2 types of card reader.
Couple days after the BSOD wave but no one report the successful restore yet, can't understand that.
No idea how the error message is for Windows, as I'm coming from OSX, but your OS shouldn't recognize the Firmware NAND, as it's not formatted in any way it can recognize. So "no media inserted" sounds about right. He just needs to find where the card is "mounted" (if there is such a thing on Windows) and write the image he backed up earlier raw. On OSX/Linux you can use dd, the programs the Windows folks use are mentioned in the nand flash dump (3ds xl) thread somewhere. There are other threads on here where people successfully wrote back their Gateway backup, you might have to swap some bytes, though. I've personally written back my own 4.5 backups successfully several times now.
 
I'm not sure what the motivation of those who are claiming this (willy-nilly) is, but I can take a few guesses, none of which reflect well on those accusers.

You have to admit it's pretty suspect. It doesn't even seem possible that Normatt's tiny patch could cause memory corruption, so why would Gateway explicitly mention not to use even that?

Even still, it doesn't really make any sense that Gateway would intentionally brick anybody's device. Any news of bricking in the flash card scene is going to be a real turn-off for a lot of people. Also, if I was a Gateway owner, I'd be pretty pissed if it came out that they were playing God with 3DS consoles. Firstly, there's the dangers of incorrectly implementing something like that; a false positive in the brick-if-modified routine could cause harm to your own customers. Secondly, the devices you're harming are owned by (arguably) innocent consumers, many of them wouldn't even know that the card they bought is a clone of a Gateway. You're not teaching them that they should have bought a Gateway, you're teaching them that Nintendo was right and they really shouldn't trust any unlicensed hardware or pirate games in the first place. So, yeah, it makes no sense for Gateway to do something like this unless they're really stupid.
 
  • Like
Reactions: orcid and ground
It doesn't even seem possible that Normatt's tiny patch could cause memory corruption, so why would Gateway explicitly mention not to use even that?

that statement makes very little sense: changing even a single bit in any executable code could potentially cause memory corruption.

have you done any technical review on this region-free patch? if not, stating it's definitely harmless is a) dishonest and b) unhelpful.
 
Selling flashcards to play backup games is a business of very high morals. It makes game developers so rich that they all ride Ferraris or Maseratis.


Gateway team would never do anything so immoral such as deliberately bricking end user's 3DS in an attempt to teach their "so-called" competitors a lesson.
 
Selling flashcards to play backup games is a business of very high morals. It makes game developers so rich that they all ride Ferraris or Maseratis.


Gateway team would never do anything so immoral such as deliberately bricking end user's 3DS in an attempt to teach their "so-called" competitors a lesson.

thanks for your great contribution to this thread.
 
As far as I can tell, any claims about deliberate sabotage from Gateway team causing this issue are unsubstantiated by any evidence.

I'm not sure what the motivation of those who are claiming this (willy-nilly) is, but I can take a few guesses, none of which reflect well on those accusers.
Note how, as said above, tons of checks have been found all over the Gateway launcher to check if it's been modified and no one knows what they're for yet. We DO know that it doesn't prevent it from working (as the clones and region free patch work), but they probably do SOMETHING. Bricking is pretty much the only thing I can think of that it would do.
 
Note how, as said above, tons of checks have been found all over the Gateway launcher to check if it's been modified and no one knows what they're for yet. We DO know that it doesn't prevent it from working (as the clones and region free patch work), but they probably do SOMETHING. Bricking is pretty much the only thing I can think of that it would do.
Clones use unmodified Gateway executables? Or isn't it more likely that they removed these checks?
 
Clones use unmodified Gateway executables? Or isn't it more likely that they removed these checks?

Obviously they use their own Launcher.dat, which is a slightly modified gateway Launcher.dat to begin with, as to what exact changes they made. I am not sure considering I haven't looked at their own payload (I never cared much about clones cards)
 
Clones use unmodified Gateway executables? Or isn't it more likely that they removed these checks?
Note how it's still not known for sure what that code actually does, but it functions just fine. Said clone companies are lazy and the less work they have to do, the better. If it works with those checks in place, why remove them? They probably had no idea this was going to happen. As mathieulh said, the actual code that does something if the check fails is apparently pretty well hidden/disguised. It would be interesting to at least check whether the checks are there to make sure though. Unfortunately I can't do that myself.
 
Note how it's still not known for sure what that code actually does, but it functions just fine. Said clone companies are lazy and the less work they have to do, the better. If it works with those checks in place, why remove them? They probably had no idea this was going to happen. As mathieulh said, the actual code that does something if the check fails is apparently pretty well hidden/disguised. It would be interesting to at least check whether the checks are there to make sure though. Unfortunately I can't do that myself.
That is even more speculation.
 

Site & Scene News

Popular threads in this forum