Hacking GW multirom demo

[MadButch]

Mathieulh, in your opinion, do gateway owners also risc being bricked?

I mentioned read errors in an earlier post, but you disregarded that notion then.
Do you still stand by that? Or is there not much more known about the exact trigger?

 

[mathieulh]

Mathieulh, in your opinion, do gateway owners also risc being bricked?

I mentioned read errors in an earlier post, but you disregarded that notion then.
Do you still stand by that? Or is there not much more known about the exact trigger?

For now it still seems improbable, even though legit owners apparently suffered the issue.

There is a lot we don't understand when it comes to the triggering factor of the bricking routine. There is more than just a single check. Also I have spotted weeks ago code that seemed to be using their ASIC and yet not needed for their actual payload to run (I filled the data it uses with garbage back then and it still ran fine) I couldn't understand the purpose of the instructions back then, I had assumed it was simply some left over anti-clone protection that they ended up not using. I am starting to wonder if that's not just yet another brick code trigger (I mean, it does run on a loop in the background, waiting for the gw card to be inserted...) right now I am not entirely sure about it.

I value my 3DS units so I stopped running their code on real hardware xD

 

[Snailface]

So far I'm researching everywhere, and I do not see any page confirming your statement.
Think I'm willing to believe what iFixit and other teardown pages have shown me.

"Cite your sources." Normmatt is the source.
The sites you cite only do shallow, brief analysis intended for non-techie consumption. They don't spend the countless hours, days, weeks, wading deep into the hardware learning all of its secrets the way guys like Normmatt and Mathieulh do.

 

[mathieulh]

So far I'm researching everywhere, and I do not see any page confirming your statement.
Think I'm willing to believe what iFixit and other teardown pages have shown me.

Simply put, it's not because it doesn't appear in any official specs sheet that it's not there. You won't see any Sony official papers mentioning the KIRK hardware crypto engine on the psp, yet it's there. You won't see Nintendo papers mentioning the IOP on Wii and WiiU, yet it's there (it's a full blown ARM cpu by the way)

Vendors and manufacturers only tell you what you need (they want you to) know.

 

[profi200]

Here is another pseudo source code. And i say it again, it's only pseudo source code:

checkGW()
{
          if(crcOK)return;
          if(random)return;
          if(no_filebefore0x4444)return;
          brick()
}

That's what we aktually know. It's the second check and 0x4444 is the 04. Feb. no_filebefore0x4444() checks for the date, the first file starting with "L" is created on.

The code is from ichfly.

 

[Deleted User]

Mathieulh, in your opinion, do gateway owners also risc being bricked?

I mentioned read errors in an earlier post, but you disregarded that notion then.
Do you still stand by that? Or is there not much more known about the exact trigger?

There is a lot we don't understand when it comes to the triggering factor of the bricking routine. There is more than just a single check. Also I have spotted weeks ago code that seemed to be using their ASIC and yet not needed for their actual payload to run (I filled the data it uses with garbage back then and it still ran fine) I couldn't understand the purpose of the instructions back then, I had assumed it was simply some left over anti-clone protection that they ended up not using. I am starting to wonder if that's not just yet another brick code trigger (I mean, it does run on a loop in the background, waiting for the gw card to be inserted...) right now I am not entirely sure about it.

Mathieulh himself says he doesn't understand the code. But he claims he is knowledgeable about this whole thing. That is just too funny for words

 

[mathieulh]

Here is another pseudo source code. And i say it again, it's only pseudo source code:

checkGW()
{
          if(crcOK)return;
          if(random)return;
          if(no_filebefore0x4444)return;
          brick()
}

That's what we aktually know. It's the second check and 0x4444 is the 04. Feb. no_filebefore0x4444() checks for the date, the first file starting with "L" is created on.

The code is from ichfly.

Hum... if that's true then there is a flaw in their check, considering that when you "Format Emunand" the FAT32 partition gets formatted and the Launcher.dat file is copied to the newly created partition without a created or modified date attribute (it's literally blank)
I am wondering if that could fail their check in any way.

 

[profi200]

Maybe, but it would affect every clone user, who setup the exploit after the 04. Feb. And maybe some Gateway users too, because this runs without being checked, lol.

 

[mathieulh]

Maybe, but it would affect every clone user, who setup the exploit after the 04. Feb. And maybe some Gateway users too, because this runs without being checked, lol.

the date wouldn't matter then considering the date attributes to the files would be blank on a brand new emunand "formatted" SD card. I just wonder if that alone is enough to trigger the routine.
I'd need to look at the instructions performing that check.

 

[gamesquest1]

I'm wondering if the additional checks don't take into consideration that people would have their 3DS dates set incorrectly, judging by the fact they where meant to of been releasing a update before new year......is it not possible they set 4th February as a cut off point for how long their b2 would be getting used and after that date the code is active on 2 levels.....with gateway assuming that all gateway users would be updated in that time and the clones would be stuck with double the amount of triggers tickings against them....using the date as a multiplier for the odds of bricking as it where

 

[mr. fancypants]

Maybe, but it would affect every clone user, who setup the exploit after the 04. Feb. And maybe some Gateway users too, because this runs without being checked, lol.

whats with 4 feb?

 

[profi200]

mathieulh:
Try to make you an emulator, which output's hardware operations on a log like ichfly. That's the fastest way.

whats with 4 feb?

Then then 2 checks run instead of just one. But the date of the Launcher.dat is checked here.

 

[mathieulh]

I'm wondering if the additional checks don't take into consideration that people would have their 3DS dates set incorrectly, judging by the fact they where meant to of been releasing a update before new year......is it not possible they set 4th February as a cut off point for how long their b2 would be getting used and after that date the code is active on 2 levels.....with gateway assuming that all gateway users would be updated in that time and the clones would be stuck with double the amount of triggers tickings against them....using the date as a multiplier for the odds of bricking as it where

No, I am pretty sure it'd be so anyone running a Launcher.dat created after the date would fail the check.
Let's say for instance the clone manufacturers are late in performing their usual copy/pasta of the GW firmware and create a file after that date, the check would fail no matter what (although it'd fail the checksum already anyway).

 

[mathieulh]

mathieulh:
Try to make you an emulator, which output's hardware operations on a log like ichfly. That's the fastest way.

I did that, it's not always 100% reliable though.

 

[justinkb]

Well, unless the crcOK() check has bugs, Gateway users' execution trace would never even reach the random() check, let alone the february4() thing.

Don't really get the significance of Feb 4 anyway. Anyway got anything explanation for that? If they are using "atime", "ctime" or "mtime" equivalents on a fat filesystem as actual reliable timestamps in any way, they are pretty nuts.

 

[profi200]

Don't forget, the exploit must be started, before any "emuNAND" can be setup. So there is a higher chance of a brick on setup. And if you already have a "emuNAND" partition and just replace the Launcher.dat it can be triggered too.

If one look deeper into it, it makes not really sense. I don't know, what Gateway plan here.

 

[justinkb]

If one look deeper into it, it makes not really sense. I don't know, what Gateway plan here.

maybe the date thing is an unintended bug? Or is that unimaginable?

 

[gamesquest1]

They accepted one of the RMA's on the basis their was files with dates in 2016 or something so is it not possible the date check is a separate trigger from the checksum fail which multiplied the odds gradually as it gets further ahead in time, kinda as a backup if the integrity checks are patched.......with them knowing that the clones would be delayed a lot longer trying to find a way to update the fpga, it would stand to reason their users would be stuck with the brick code way past 4th February where as all gateway users would theoretically be on 2.0 final and wouldn't ever be on b2 once the second trigger was activated

Short sighted as my 3ds is on 2015 from changing the date for play coins etc

 

[mathieulh]

Don't forget, the exploit must be started, before any "emuNAND" can be setup. So there is a higher chance of a brick on setup. And if you already have a "emuNAND" partition and just replace the Launcher.dat it can be triggered too.

If one look deeper into it, it makes not really sense. I don't know, what Gateway plan here.

I am doubtful about the chance being higher considering the data they check is stored in ram (they aren't checking the whole file afaik, they are checking various parts of the payloads they run). I am not sure if the date attributes for the actual files get refreshed in memory, or how often that happens. They'd have to constantly read the attributes from the SD card if they forcefully kept refreshing it, that would hinder performances by quite a bit.

 

[profi200]

maybe the date thing is an unintended bug? Or is that unimaginable?

It's not just a bug. That's their second check.

I am not sure if the date attributes for the actual files get refreshed in memory, or how often that happens. They'd have to constantly read the attributes from the SD card if they forcefully kept refreshing it, that would hinder performances by quite a bit.

I'm sure the date get's updated, if you cold boot the 3DS. If one replaces the file after the 04. Feb., the chances of a brick are doubled. But if you run the "emuNAND" setup, the date get's resetted. Problem is, the most users don't need to setup "emuNAND" again, so the Launcher.dat with the actual date stays on the SD card.