Hacking WARNING - Gateway team bricks card ON PURPOSE!

  • Thread starter Thread starter crediar
  • Start date Start date
  • Views Views 178,434
  • Replies Replies 518
  • Likes Likes 21
Status
Not open for further replies.
some of these posts are completely unrelated, instead about nand dumping soldering leading to bootrom errors.

No, they aren't. Read again.
More posts:
http://gbatemp.net/threads/help-wit...r4i-deluxe-3dslink.360502/page-3#post-4883307
http://gbatemp.net/threads/help-wit...r4i-deluxe-3dslink.360502/page-3#post-4883496
Should be enough for now.

Under 30 posts on each of those accounts. And yours is rather low too, how odd...

Yeah I'm one of them MT shills, how did you not know?
 
Under 30 posts on each of those accounts. And yours is rather low too, how odd...

How does the post count had anything to do? I relay more on an old account with little post count but that theirs post did contributed in some way that a relative new account with a high post count but which most posts are unuseful or do not contribute to the discussion...
 
Except that non-pirates who used neimods launcher.dat to play legitimate games region-free are also affected.

So you are saying that Neimod created Gateway clone?

nope, not the clones, they are damaged by this news too. the third, new player on the flashcard scene.


I think you guys are confusing Normmatt with Neimod. Normmatt made the region-free patches not Neimod (totally different person, infact he is anti piracy).
 
Since people don't quite know how to read, the "bricking code" doesn't care about the sum of your Launcher.dat, it checks the sum of ARM9 payload in memory. Granted its being loaded through a large ROP chain and rather unstable exploits, think about about this. There have been about ~30 reports of bricked consoles from clone cards (due to bricking only happening when a random number generator says so). Out of ALL of the times people have booted their clone cards since the latest firmware, there have been ~30 (reported) bricks.

Now think about the odds of the ARM9 payload originating from an unmodified GW launcher not matching the intended sum, and the odds of the "bricking code" deciding to check the payload the one time your payload doesn't match.

Just my two cents.
 
I think you guys are confusing Normmatt with Neimod. Normmatt made the region-free patches not Neimod (totally different person, infact he is anti piracy).

I said Neimod, because Justinkb thinks, that those developers made up that "brick on purpose" theory.
 
No, they aren't. Read again.
More posts:
http://gbatemp.net/threads/help-wit...r4i-deluxe-3dslink.360502/page-3#post-4883307
http://gbatemp.net/threads/help-wit...r4i-deluxe-3dslink.360502/page-3#post-4883496
Should be enough for now.

Yeah I'm one of them MT shills, how did you not know?

you seem to be missing the point entirely. the point is not whether or not these bootrom errors are occuring, it seems pretty clear they are indeed occuring with the clone card firmwares.

if you are arguing for the existence of these errors, please get out of this thread ;-)

the claim being made here however is much stronger than that, namely that this is a cynical, malicious move from Gateway, instead of a consequence of the complexity of producing (by GW) and adapting (by cloners).
 
  • Like
Reactions: Huntereb
Since people don't quite know how to read, the "bricking code" doesn't care about the sum of your Launcher.dat, it checks the sum of ARM9 payload in memory. Granted its being loaded through a large ROP chain and rather unstable exploits, think about about this. There have been about ~30 reports of bricked consoles from clone cards (due to bricking only happening when a random number generator says so). Out of ALL of the times people have booted their clone cards since the latest firmware, there have been ~30 (reported) bricks.

Now think about the odds of the ARM9 payload originating from an unmodified GW launcher not matching the intended sum, and the odds of the "bricking code" deciding to check the payload the one time your payload doesn't match.

Just my two cents.


Mathieulh just debunked it:

Hum... actually they have a sanity check I forgot about within their ROP chain as they perform a checksum before the payload runs and the bricking happens, so it cannot run a corrupted payload from a Launcher.dat, thus the code causing the brick cannot run as-is from the original Launcher.dat file if that one was to be corrupt.


sha256_update(0x002B3344, 0x002B3924, 0x00000BAC);


So GW team has a sanity check that will not brick if you have a corrupt SD. That looks good to me.

I think that is beginning to explain why only clones are getting affected... GW Engineers are professionals xD
 
  • Like
Reactions: tyons and condiczek
Well, I got a fix... just buy the games, a game costs a lot to develop and not only money, but time. Sure I'm inside a hacking forum but we should be hacking to support the platform not getting paid games for free. If Gateway were a homebrew card, then this would be unacceptable. But they are only thief's who sell "Tools" to steal stuff(you get what I mean...) if you buy a gun from a murderer you cannot expect to get out of there alive. Stop crying over stuff like this! AND support the developers instead.

And if you don't have the money to buy a game, why did you waste your money on a console? I'm sure there is something better to put them on in that case.
 
  • Like
Reactions: kmno and Rob Blou
the claim being made here however is much stronger than that, namely that this is a cynical, malicious move from Gateway, instead of a consequence of the complexity of producing (by GW) and adapting (by cloners).

It hardly seems like a consequence when it started happening all at once, how long again? after the firmware was released. Also if I'm not mistaken, there were reports from people who tried to flash their NAND backup back and failed (obv. there could still be other reasons for that)
 
Since people don't quite know how to read, the "bricking code" doesn't care about the sum of your Launcher.dat, it checks the sum of ARM9 payload in memory. Granted its being loaded through a large ROP chain and rather unstable exploits, think about about this. There have been about ~30 reports of bricked consoles from clone cards (due to bricking only happening when a random number generator says so). Out of ALL of the times people have booted their clone cards since the latest firmware, there have been ~30 (reported) bricks.

Now think about the odds of the ARM9 payload originating from an unmodified GW launcher not matching the intended sum, and the odds of the "bricking code" deciding to check the payload the one time your payload doesn't match.

Just my two cents.

Nobody cares.

The suggestion that the respected Gateway team would put code in their firmware which deliberately reprograms the eMMC controller so the nand can't even be reflashed (via usual hardware methods posted here and elsewhere on the internet) is RIDICULOUS and very likely UNTRUE

I still await a disassembler dump of the little bit of code which reprograms the eMMC controller - that would prove me wrong.
 
Hum... actually they have a sanity check I forgot about within their ROP chain as they perform a checksum before the payload runs and the bricking happens, so it cannot run a corrupted payload from a Launcher.dat, thus the code causing the brick cannot run as-is from the original Launcher.dat file if that one was to be corrupt.

sha256_update(0x002B3344, 0x002B3924, 0x00000BAC);

Would you care to explain what this means in an easiest way, please?

Are you saying that, if the original/unmodified Gateway's launcher happens to get corrupted while being on the SD card, the brick can't occur due to this "sanity check"?
 
Mathieulh just debunked it:

So GW team has a sanity check that will not brick if you have a corrupt SD. That looks good to me.

I think that is beginning to explain why only clones are getting affected... GW Engineers are professionals xD

No. You could still have a corruption (or modification) in the ARM9 payload that runs afterwards and which is the one checked to decide between {} and {brick();}.
 
The suggestion that the respected Gateway team would put code in their firmware which deliberately reprograms the eMMC controller so the nand can't even be reflashed (via usual hardware methods posted here and elsewhere on the internet) is RIDICULOUS and very likely UNTRUE

The Chinese pirate device maker would never do anything malicious to put their competition at a disadvantage. I promise!
 
It hardly seems like a consequence when it started happening all at once, how long again? after the firmware was released. Also if I'm not mistaken, there were reports from people who tried to flash their NAND backup back and failed (obv. there could still be other reasons for that)

how about, instead of jumping to an insane, unfounded conclusion, think of the more logical thing... R4i clone team who has no skill themselves and only steals others' work just fucked up with their latest couple of firmware releases? They rushed their release and then rushed the fix too, it seems.
 
Would you care to explain what this means in an easiest way, please?

Are you saying that, if the original/unmodified Gateway's launcher happens to get corrupted while being on the SD card, the brick can't occur due to this "sanity check"?


Yes, exactly.

No. You could still have a corruption (or modification) in the ARM9 payload that runs afterwards and which is the one checked to decide between {} and {brick();}.

GW checks the ARM9 payload before running it, so no this is not possible
 
  • Like
Reactions: tyons and condiczek
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum