ROM Hack Loading the DS profile exploit (or other launchers) using Gateway Go

[TheHomesk1llet]

Right now I'm in the middle of arranging some tools that can be used to install and launch your totally legit, legal 3DS backups. The first thing that I absolutely cannot start anything without is the exploit used in the gateway website. I considered the possible methods of running the launcher.dat file from the website, and here's what I think so far:

First, and most importantly, the website exploit does not use the DS profile at all, or even install the DS profile exploit, which means you have to use the website. Now that we know this, here's what I think is going on with the exploit itself...

1. The exploit is capable of running a launcher.dat file on the SD card, probably by a buffer exploit. However, it can't just run any valid launcher.dat file, it HAS to be the gateway launcher.dat file.
2. Gateway launcher.dat files are encrypted by gateway. If you try to run a homebrew launcher.dat file using the website exploit, the exploit will not work. This is because the exploit recognizes that the loader you are trying to execute is not a valid Gateway loader. This causes you to be kicked back to the home menu with no changes applied.

So if it's encrypted, we can just emulate the encryption, right? Wrong! There are tools out there that can simulate the Gateway encryption on a launcher, but the exploit still won't launch the launcher from the SD card. This is probably due to filesize, but I'm not entirely sure. The exploit has some way of knowing that the loader you are trying to execute is not gateway-official, and prevents it from launching.

Now, we also know that you can run ANY launcher using the ROP loader .nds file on a flash cart. However flashcarts are not always an option for people, or people prefer a softmod over buying a flashcart (like me). The ROP loader has a couple different loading options, one of which being able to load encrypted files, and the other being to load unencrypted files. The one on the web loads encrypted files only, which means that if you want to load a CFW, be it the original or Palantine, you can't do it.

Now, my question is this: Is there currently a way to reverse the gateway go exploit to allow the execution of unsigned/homebrew launchers? Or, even better, is there another exploit that does not require the use of a flash cart? I'm on 4.x, of course.

Answers are appreciated greatly.

 

[Falo]

The new launcher.dat is a combination of multiple launcher.dat's.
The main reason for this is, to support multiple firmware version.

The old launcher.dat is still at 0x0 - 0x9000 and works exactly like the old ds profile exploit.

You can't use the homebrew launcher.dat with the go exploit, because the new launcher.dat's are at a different memory location.

Firmware 2.0: 0xA000
Firmware 2.1-3.X: 0xE000
Firmware 4.0-4.X: 0x12000
Firmware 5.0-7.0: 0x16000
Firmware 7.1-9.X: 0x1A000
Firmware Unknown: 0x1E000 (sorry my mistake there is no unknown fw ^^)
all of them are 0x4000 byte

Each browser payload loads a different launcher.dat to this memory location: 0x08F10000
and then it uses a new "Add" Encryption instead of using the aes-cbc.

int *buffer = 0x08F01000;
int key = 0;
 
for (int i = 0; i < 0x1000; i++)
{
    key += 0xD5828281;
    buffer[i] += key;
}

After doing this, a new exploit (Ninjhax/gpuhax) is used to get arm code execution.

Yifan Lu has done the reversing work here, google "Reversing Gateway Ultra First Stage (Part 1)" if you want to know more.

 

[Bug_Checker_]

The new launcher.dat is a combination of multiple launcher.dat's.
The main reason for this is, to support multiple firmware version.

The old launcher.dat is still at 0x0 - 0x9000 and works exactly like the old ds profile exploit.

You can't use the homebrew launcher.dat with the go exploit, because the new launcher.dat's are at a different memory location.

Firmware 2.0: 0xA000
Firmware 2.1-3.X: 0xE000
Firmware 4.0-4.X: 0x12000
Firmware 5.0-7.0: 0x16000
Firmware 7.1-9.X: 0x1A000
Firmware Unknown: 0x1E000
all of them are 0x4000 byte

Each browser payload loads a different launcher.dat to this memory location: 0x08F10000
and then it uses a new "Add" Encryption instead of using the aes-cbc.

int *buffer = 0x08F01000;
int key = 0;
 
for (int i = 0; i < 0x1000; i++)
{
    key += 0xD5828281;
    buffer[i] += key;
}

After doing this, a new exploit (Ninjhax/gpuhax) is used to get arm code execution.

Yifan Lu has done the reversing work here, google "Reversing Gateway Ultra First Stage (Part 1)" if you want to know more.

Yes and to add to that there also part 2 from Yifan , a couple of pastebin pastes and smea blog on ninjhax. All good starting points/resources.

 

[TheHomesk1llet]

Sorry, I thought I had posted my reply to this. Thanks for the links.

So basically, we're stuck waiting until someone reverses the exploit so that we can run any launcher using a similar exploit? Or is there another way that doesn't require the purchase of extra hardware? I doubt it, but it's worth asking.

 

[imXeno]

So can't we just replace the code for example at 0x12000 with a homebrew launcher.dat that runs cfw (or anything else)?

 

[Falo]

So can't we just replace the code for example at 0x12000 with a homebrew launcher.dat that runs cfw (or anything else)?

Nope you can't, different exploits and different memory locations.
I'm working on a ROP compiler in C#, so far so good, i can compile an identical ROP as gateway, including encryption and obfuscation (except register junk).
But now i'm at a point (the arm11 payload) where i really need RAM dumps to continue...
After fixing some bugs i may release it open source for others to continue.

 

[hackotedelaplaqu]

Nope you can't, different exploits and different memory locations.
I'm working on a ROP compiler in C#, so far so good, i can compile an identical ROP as gateway, including encryption and obfuscation (except register junk).
But now i'm at a point (the arm11 payload) where i really need RAM dumps to continue...
After fixing some bugs i may release it open source for others to continue.

Back in 2013, this Launcher.dat was released for ram dumping.
Don't now if you can use this with go exploit.
[Edit] Of course not but you may build your own ram dumper from reversing this.

 

[TheHomesk1llet]

Nope you can't, different exploits and different memory locations.
I'm working on a ROP compiler in C#, so far so good, i can compile an identical ROP as gateway, including encryption and obfuscation (except register junk).
But now i'm at a point (the arm11 payload) where i really need RAM dumps to continue...
After fixing some bugs i may release it open source for others to continue.

I'm guessing that you need your own ram dumps, right? If not, people would be more than willing to provide ram dumps for your cause.

 

[Falo]

I would need multiple ram dumps from different fw versions.
But i'm stuck for now, i can't get it to work.

what i tried do to:
Build Browser ROP -> identical to Gateway, except junk register -> fail, crash to home menu
Build Browser ROP -> load decrypted launcher.dat -> fail, it goes black for 1 second then crash to home menu
Build Encrypted Launcher ROP -> fail, system crash, hard-reset needed...
At this point i'm thinking that there are some checks in later stages to prevent this or i made somewhere a mistake...
If i would know the memory address of IFileWrite on 9.2, i could write a basic ram dumper...

Well anyway here the current compiler + source: (C#, Visual Studio 2010)
https://www.dropbox.com/s/3iis18p521faiep/GatewayCompilerv1.0.7z?dl=0
NOTE: this tool is useless to the end-user, it's only useful for developer.

All what you have to do is put the new launcher.dat into the data dir, my tool will decrypt it and generate lots of files.
It's not just a compiler, it also generates debug files from rop chains to auto-analyze them.
The basic setup would then allow you to replace fwXX_arm11payload.bin with your own code, but since it's not working...

 

[imXeno]

I would need multiple ram dumps from different fw versions.
But i'm stuck for now, i can't get it to work.

what i tried do to:
Build Browser ROP -> identical to Gateway, except junk register -> fail, crash to home menu
Build Browser ROP -> load decrypted launcher.dat -> fail, it goes black for 1 second then crash to home menu
Build Encrypted Launcher ROP -> fail, system crash, hard-reset needed...
At this point i'm thinking that there are some checks in later stages to prevent this or i made somewhere a mistake...
If i would know the memory address of IFileWrite on 9.2, i could write a basic ram dumper...

Well anyway here the current compiler + source: (C#, Visual Studio 2010)
https://www.dropbox.com/s/3iis18p521faiep/GatewayCompilerv1.0.7z?dl=0
NOTE: this tool is useless to the end-user, it's only useful for developer.

All what you have to do is put the new launcher.dat into the data dir, my tool will decrypt it and generate lots of files.
It's not just a compiler, it also generates debug files from rop chains to auto-analyze them.
The basic setup would then allow you to replace fwXX_arm11payload.bin with your own code, but since it's not working...

I would say there's a filesize-check somewhere and it prevents you from running your own code (even if the difference is just the junk register - filesize is not the same).

 

[Falo]

I would say there's a filesize-check somewhere and it prevents you from running your own code (even if the difference is just the junk register - filesize is not the same).

Nope impossible, the size is the same ^^.

I did take care to make an exact copy of the original rop (except register junk), and that means i'm using the exact same gadgets in the same order with the same values. The output is completely identical to gateways's rop, even the memory locations for decrypt key, lr stack jumps and filesize.
I did also copy their junk gadgets and padding values... and my compiler does compile all 5 firmware versions...

Here a comparison: original browser rop vs my browser rop:

 

[imXeno]

Nope impossible, the size is the same ^^.

I did take care to make an exact copy of the original rop (except register junk), and that means i'm using the exact same gadgets in the same order with the same values. The output is completely identical to gateways's rop, even the memory locations for decrypt key, lr stack jumps and filesize.
I did also copy their junk gadgets and padding values... and my compiler does compile all 5 firmware versions...

Here a comparison: original browser rop vs my browser rop:

Anyway, there must be something that blocks loading own stuff.

 

[Deleted User]

I would need multiple ram dumps from different fw versions.
But i'm stuck for now, i can't get it to work.

what i tried do to:
Build Browser ROP -> identical to Gateway, except junk register -> fail, crash to home menu
Build Browser ROP -> load decrypted launcher.dat -> fail, it goes black for 1 second then crash to home menu
Build Encrypted Launcher ROP -> fail, system crash, hard-reset needed...
At this point i'm thinking that there are some checks in later stages to prevent this or i made somewhere a mistake...
If i would know the memory address of IFileWrite on 9.2, i could write a basic ram dumper...

Well anyway here the current compiler + source: (C#, Visual Studio 2010)
https://www.dropbox.com/s/3iis18p521faiep/GatewayCompilerv1.0.7z?dl=0
NOTE: this tool is useless to the end-user, it's only useful for developer.

All what you have to do is put the new launcher.dat into the data dir, my tool will decrypt it and generate lots of files.
It's not just a compiler, it also generates debug files from rop chains to auto-analyze them.
The basic setup would then allow you to replace fwXX_arm11payload.bin with your own code, but since it's not working...

I think Gateway's Launcher.dat has some sort of file verification in it. I decrypted the Launcher.dat, removed the decryption code from the web exploit, and ran it. It flashed the bottom screen black then white like normal, signalling that its running as normal, but it stays like that and the menu never comes up. Since the code loaded should be identical to how it normally is (all I basically did was move a step), the only thing I can think of is that its checking to see if the file on the SD card has been modified from the original Launcher.dat in a later stage.

 

[NCDyson]

unless it uses a hash or checksum of some sort to verify that it's an official gateway launcher... but I assume you check for that. I'm guessing gateway doesn't want people using their 'sploitz. jerks.

 

[Deleted User]

unless it uses a hash or checksum of some sort to verify that it's an official gateway launcher... but I assume you check for that. I'm guessing gateway doesn't want people using their 'sploitz. jerks.

I am saying it probably uses some kind of hash or checksum in a later stage. If the exploits they use are discovered through reverse engineering, though, then they could be freely used for just about anything.

 

[TheHomesk1llet]

You know what, I'm so sick of all the 3DS scene elitists that say "Yeah, we have full kernel access. No, we're not going to release it to anyone outside of our circle. I'll make a deal to everyone here:

If someone can point me in the right direction (IE what languages/programs to learn, and even the basics on how the internal structure of the 3DS works so I don't have to reinvent the wheel), I will drop everything I am currently doing and dedicate all of my time, and yes, ALL OF IT, to creating, reverse engineering, whatever it takes to create a public, fully accessible userland exploit that will allow you to run any and all 3DS launchers. I will make it free and fully available to everyone. Hell, if it gets enough support, I'll even develop a toolkit filled with everything you could ever dream of.

No, I'm not joking. This shit has gotten me fucking heated.

It looks like there are some really intelligent people here, so I'm sure I can depend on their support.

After I have all of the necessary information to start, leave the rest to me. Again, all I need is the basic workings of the 3DS, and if the reversing of the go exploit is successful and made fully public, I'll build on that, too, and create something even better.

 

[krisztian1997]

I am saying it probably uses some kind of hash or checksum in a later stage. If the exploits they use are discovered through reverse engineering, though, then they could be freely used for just about anything.

Smealum made its own launcher.dat to use with the GO explot, so its posible to do it, he also posted the code for the ROP.

 

[Falo]

Smealum made its own launcher.dat to use with the GO explot, so its posible to do it, he also posted the code for the ROP.

He doesn't use any of the later stages, all what his launcher.dat does is patch the dlplay app to allow region free through ns:s.
What we want is ARM11 and ARM9 kernel access and not just a region free trick...

Note: his launcher.dat only works on 7.1-9.4, if you try to load it with 2.0-7.0 it will only crash the browser applet.

 

[krisztian1997]

He doesn't use any of the later stages, all what his launcher.dat does is patch the dlplay app to allow region free through ns:s.
What we want is ARM11 and ARM9 kernel access and not just a region free trick...

Note: his launcher.dat only works on 7.1-9.4, if you try to load it with 2.0-7.0 it will only crash the browser applet.

Ohh... I though that you were having problems loading a launcher.dat using the ROP from the go exploit, sorry.

 

[imXeno]

hah, I would like to learn something too if..

If someone can point me in the right direction

I'm now developing in C++, nothing special.

Note: his launcher.dat only works on 7.1-9.4, if you try to load it with 2.0-7.0 it will only crash the browser applet.

Because there's no code for older firmwares, am I right?