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
The way I see it, is that people have been saying for a long time that it's stupid to rely on the code of others and expect gateway to just be like "ohhh wellll it took us 2 months making emunand stable...I suppose we can just let people resell our work" if it did turn out to be intentional, it's nobody's fault but the clones, they shouldn't be just putting firmware out that they don't even understand themselves....and if they do understand it why don't they just make their own code and stop relying on gateway, the fact they released 3 attempts of making beta 2 work on their card in the space of a week pretty much proves they do zero in terms of making sure the firmware is safe and stable, wouldn't surprise me if there "testing" turned out to be " hahaha yeah the game shows up....quick upload it now! While it still works quick"
 
  • Like
Reactions: Crass
Disclaimer: Just speculating here, folks. Don't take any of this as fact.
Looks like they did it...

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.
Perhaps the clone carts weren't making a big enough dent into Gateway's sales for them to bother implementing a feature to stop/discourage clones until recently.
Perhaps this "feature" took some time to perfect so that it wouldn't accidentally brick a console running their own unmodified launcher. (This part is still speculation. lol)
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.
On the contrary, bricking consoles at random that are using a stolen/modified version of their [Gateway's] launcher and then pinning it as being the fault of the copycat team(s) would be a brilliant (shady as hell) move on their part to cut off competition. Totally feasible at the hands of a skilled team unabashedly profiteering off of piracy, too.

If it bricked consoles running modified launchers 100% of the time, you couldn't coerce the majority of the otherwise unaffected clone cart users into buying a Gateway cart without the user having to either perform a hardware mod in order to restore from backup (even an easy hardware mod will deter most users from doing so) or buying another 4.5 3DS. That's expensive. You'd likely lose a lot of potential customers. $$$
Best to make an example out of a portion of the users and let the rest scramble. :evil:
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.
Hopefully so. I'm starting to think that this is wishful thinking though...


Oh well. That's my two cents.
We'll just have to see what happens.

Edit: Suspicions confirmed for Gateway.
Wow I wish I was wrong.
 
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.


Thanks for your information.
I just quoted someone else's experience and I did see in somewhere if you are ready to write back the windows will prompt "Format or not?" message instead of "no media inserted".
B.T.W. are you sure you just fixed a blue screen NOT just downgrade from a functional higher version?
 
I ordered a GW a day before all this went down. Glad I did now. Even if it is intentional it doesn't affect me that much. I'd rather the gateway team spend their time on their product and not add any extra code that could potentially cause issues with GW users, but I would understand they'd do it. Unless any evidence gets brought forth though I'll continue to believe it was simply the work of the clone cards.
 
Thanks for your information.
I just quoted someone else's experience and I did see in somewhere if you are ready to write back the windows will prompt "Format or not?" message instead of "no media inserted".
B.T.W. are you sure you just fixed a blue screen NOT just downgrade from a functional higher version?
Of course, I downgraded from a higher Firmware version, not from this desaster. Haven't even used my Gateway in quite a while.
 
No accusation against GW, just speculation by logic.
(I'm a noob, if i'm wrong, please correct me.)
I know so called "Memory Corruption" is not a word so rare, we can see it on many kind of platforms like Windows, Mac even Wii homebrew Apps.
"Memory Corruption" could cause app crashes, OS freezes, reboots etc. of cause including "break your 3DS"(even though I think the possibility is very low).
Basically "Memory Corruption" occurs inside the system memory(RAM), and the brick thing is directly caused by damage of storage(NAND).
So how could a RAM violation damage the NAND? I think there might be the possibility as below:

Memory corruption occurred in the RAM triggered a "function" to write something to the NAND.

I won't say this "function" is intended, but look, "the clone Link's modification invoked it" then "a totally different modification by Normmatt happened to invoke it too"?
(or there are a lot of different functions could cause brick?)
There are a lot of options like freeze, crash... but the two different modifications just lead to the very same end---brick? is that just a coincidence?
Or, on the 3DS platform, memory corruption WILL cause an invalid write operation to NAND inevitably by design?

I respect GW team's work and don't like those clones, but I feel sorry for the users who encountered this problem, they don't deserve this.
Hope someone could find a solution to address this issue.
 
Well presuming that the memory corruption occurred before emunand is launched....some redirection functions may have been corrupted, resulting in the console writing data intended for emunand to sysnand instead, the nand is wrote to pretty much any time the console is turned on even if you haven't really done anything, I don't think I have heared anyone who has defiantly been bricked by the region free mod, but I think you will agree, that it's better safe than sorry...whenever you change code, no matter how insignificant it may seem it can have side effects elsewhere. Gateway haven't exactly been crappy about it, and have even said they will include region free in the next classic mode, which in my opinion is actually quite fair as they probably realise this will be used by non gateway users mainly
 
Well presuming that the memory corruption occurred before emunand is launched....some redirection functions may have been corrupted, resulting in the console writing data intended for emunand to sysnand instead, the nand is wrote to pretty much any time the console is turned on even if you haven't really done anything, I don't think I have heared anyone who has defiantly been bricked by the region free mod, but I think you will agree, that it's better safe than sorry...whenever you change code, no matter how insignificant it may seem it can have side effects elsewhere. Gateway haven't exactly been crappy about it, and have even said they will include region free in the next classic mode, which in my opinion is actually quite fair as they probably realise this will be used by non gateway users mainly

That makes sense.
But, the GW 2.0B1 did cause freeze/black screen a lot but no brick reported.

the nand is wrote to pretty much any time the console is turned on even if you haven't really done anything
I think the beta1 should do the same way unless beta2 added some particular functions that could cause brick, and those very functions are triggered by unofficial modification(s)...
 
From what I have read from some people who looked into how the launcher works, their is several checksums during the loading of the launcher, I'm not not too sure as I have no real knowledge of how it works but maybe if the gateway launcher detects an error it triggers a black screen, but then if the clones patched this function out so it would work with their code, it just carries on doing stuff even when an error occurs where the gateway would of halted loading, or retried setting up instead of just carrying on loading up a firmware dispite the redirection code not being loaded up properly....hence why it hit clones and not just everyone
 
I don't think that gateway is responsible for the bricks. If the clone teams really understood the gateway firmware, they would modify it more. They are messing around with a complex hack which they don't understand. So there is no surprise that there is a risk for a brick.
 
Yeah this is what I think they probably just saw a checksum and disabled it thinking it was there just to hinder them coping the firmware, when it was actually there to prevent any bricks with code not loading properly. Moral of the story is. Don't put your trust in people who can't do their own work in the first place
 
I wonder if this news will lead to the GW team investigating their own code/card and may delay 2.0 further. I'd rather all resources go to that instead of getting sidetracked by this issue.
 
I wonder if this news will lead to the GW team investigating their own code/card and may delay 2.0 further. I'd rather all resources go to that instead of getting sidetracked by this issue.

I would rather not have firmware that bricks my $200 console. :ha:
 

Site & Scene News

Popular threads in this forum