Announcing RocketLauncher! The first exploit with unlocked Arm7!

UPDATE:
Looks like NoCash found an exploit that is even better then RocketLauncher:

https://problemkaputt.de/gba.htm

He titled it Unlaunch. The exploit works by exploiting a flaw in Stage2 and apparently works on all firmware versions. It requires you run the installer from a DSiWare based hax environment as access to SD/NAND is required. (thus you can't run this from Slot-1 based TWL exploit)

The flaw in stage2 is a buffer overflow involving Launcher's TMD file. If you provide a larger then normal TMD file, it will attempt to load the TMD into ram anyways (this occurs before it does the RSA check) This causes it to overwrite some code in arm9 ram causing arm9 to execute the custom payload. The full details are found in the info menus in the installer.

Note however the installer does not appear to work correctly at the moment. I'd advise you not attempt to install it from the installer. Use the manual install method instead. BUT I'd highly recommend you have a hard mod before attempting manual install. If you have had experience modifying your nand you may be ok doing this. But for safety sake I would just advise against that until the installer works properly.

(this is one reason why RL hasn't been released yet. No proper installer tools are available yet and we don't want people bricking consoles trying to install it)

The release of this exploit may impact our plans regarding RocketLauncher. I'll post more about this once StuckPixel has decided to comment on this.


Important Notice:

Do NOT visit Data Management in DSi System Settings or use the 3DS Transfer tool after installing unlaunch. You WILL brick the console. Wait until HiyaCFW is refined/released properly so that SD redirected version of Launcher can be used or when NoCash decides to implement his own version of the SD redirect patch.






Today I can finally announce a new exploit for the Nintendo DSi. I found this flaw back on May 29th. Almost a year after NoCash initially discovered a oversight by Nintendo involving the DS Cart White list which this exploit takes advantage of (Nintendo forgot to reimplement the RSA checks on it lolz). I was fudging with various things in the white list to try and get a crash. I got system menu to crash by using large values in section 3! So I contacted NoCash and a few other devs about this to investigate it and to see if it's exploitable. Well long story short it was!


Summery of the above video:

1. The exploit requires 1.4.0 firmware! Older or newer fw revisions do not work!
2. The exploit requires a flashcart that you are able to modify the internal rom it presents to the system.
3. Details on which cards will be compatible will be revealed at a later time.
4. The exploit involves a buffer overflow flaw involving section 3 of the white list.
5. This overflow occurs on arm7 thus allowing overwriting memory exclusive to arm7.
6. As a result a large enough overflow will hit the IRQ interrupt handler. This is how we gain code execution.
7. Arm9 was relatively easy to take over. Though data caching presented a minor roadblock while testing on hardware. :P
8. I currently use a modified build of nds-bootloader from WinterMute's github. You know, that portion of hbmenu responsible for booting SRLs. :P
9. Because we already gained arm7 we only had to put arm9 in the correct wait state so that nds-bootloader can do it's thing. :D
10. The exploit in theory can work from the menu once it's running. But we currently make use of the auto boot feature to ensure a stable consistant environment. Tests with a second console suggest that is the case. Note that the exception vector for arm7 seems to either be somewhere else once the menu GUI is running or the overflow hits something else causing arm7 to crash early. Currently we plan to only target exploiting the system with an autoboot rom as it's more predictable.
11. The exact machanics of the arm9 take over and how nds-bootloader is loaded may change. Currently the entire payload fits on the cart. But we may allow reading a payload off SD instead.

Credits to NoCash, Gericom, and Normmatt for help testing/figuring this out. Big credit to StuckPixel who put in most of the coding needed to make this happen. My contribution was finding the flaw and help with testing on hardware.


I will release further details as we finalize this exploit and prepare stuff that will make installing it easier.

Note you will either need a nand mod or a DSiWare based exploit to downgrade your console/install the modified white list needed for this to work. Hopefully we'll have a better solution then simply using fwtool to do this so that may be the factor that determines release date so please be patient!

When things are ready I will update this thread!
 
Last edited by Apache Thunder,

TipsPROmayB

Just a music producer roaming GBATemp
Member
Joined
Jan 9, 2016
Messages
222
Trophies
0
XP
564
Country
Croatia
It's not like there could really be anything talked about other than the tool to find the addresses for running RocketLauncher in other roms.
Apache said it's a common value in roms so I don't see how that might slow their work
 

smf

Well-Known Member
Member
Joined
Feb 23, 2009
Messages
5,413
Trophies
1
XP
4,051
Country
United Kingdom
well nothing happened in weeks, guy just asked is this dead because it seems like it's dead

Or maybe they just don't have any news or are bored giving news?

They've said they weren't going to release anything until someone wrote a file copier, so you don't need to reflash the entire nand. AFAICT nobody has bothered to do it.
 
  • Like
Reactions: siamese

JimmyZ

Sarcastic Troll
Member
Joined
Apr 2, 2009
Messages
681
Trophies
0
XP
751
Country
Zimbabwe
Or maybe they just don't have any news or are bored giving news?

They've said they weren't going to release anything until someone wrote a file copier, so you don't need to reflash the entire nand. AFAICT nobody has bothered to do it.
I remember something about waiting for safer tools, but not so specifically a file copier. Anyway I've planed to make one, but currently waiting for libnds updates.
https://github.com/devkitPro/libnds/issues/26
 
  • Like
Reactions: daxtsu
D

Deleted User

Guest
It will take a long time to develop a new safer firmware tool from scratch,
No, it won't. It's just that nobody has gotten around to doing it / we currently don't have the resources.

but FWTool is already faulty enough anyway.
No, it's not. The problem is people using faulty SD cards, or restoring a decrypted / broken NAND. Bricking while using that tool is a very uncommon phenomenon.
 

Lyrin

Annoying Weaboo Girl
Member
Joined
Jun 4, 2017
Messages
499
Trophies
0
Age
21
Website
www.reddit.com
XP
659
Country
United States
No, it's not. The problem is people using faulty SD cards, or restoring a decrypted / broken NAND. Bricking while using that tool is a very uncommon phenomenon.
And possibly using TWLTool 1.1 in the DSi Downgrade Guide package. There was someone who decrypted their nand with both TWLTool 1.1 and 1.6 getting different results.
 

sieroi

Well-Known Member
Member
Joined
Apr 29, 2015
Messages
144
Trophies
0
Age
34
XP
446
Country
I'm just glad the project exists at all. I never expected DSi CFW to become a thing in the first place- we're ridiculously lucky that someone cares enough to work on it.

The wait won't kill us.
 
  • Like
Reactions: Lyrin and CatmanFan

JimmyZ

Sarcastic Troll
Member
Joined
Apr 2, 2009
Messages
681
Trophies
0
XP
751
Country
Zimbabwe
And possibly using TWLTool 1.1 in the DSi Downgrade Guide package. There was someone who decrypted their nand with both TWLTool 1.1 and 1.6 getting different results.
"-TWL decryption now decrypts MBR and partitions (copying the rest) instead of annhilating unencrypted parts"
from TWLTool 1.6 changelog.
 
  • Like
Reactions: CatmanFan

smf

Well-Known Member
Member
Joined
Feb 23, 2009
Messages
5,413
Trophies
1
XP
4,051
Country
United Kingdom
Which version of TWLTool is best by the way? Or are they all the same?

If they were all the same then it wouldn't make sense to have different versions. I used 1.6 as it checks the CID and console id is valid. There are probably other benefits, I tend to run the latest of everything by default.
 
  • Like
Reactions: Lyrin

realWinterMute

Well-Known Member
Member
Joined
Feb 24, 2011
Messages
115
Trophies
0
XP
496
Country
If they were all the same then it wouldn't make sense to have different versions. I used 1.6 as it checks the CID and console id is valid. There are probably other benefits, I tend to run the latest of everything by default.

1.7 @ https://github.com/WinterMute/twltool/releases reads CID/Console ID from nocash info footer if present. Handy for dealing with multiple nands.
 
  • Like
Reactions: Lyrin

Valery0p

Well-Known Member
Member
Joined
Jan 16, 2017
Messages
475
Trophies
0
XP
1,238
Country
Italy
I remember something about waiting for safer tools, but not so specifically a file copier. Anyway I've planed to make one, but currently waiting for libnds updates.
https://github.com/devkitPro/libnds/issues/26
I don't know if it's useful for that tool, but you should know that godmode9 can mount TWLN and TWLP partitions from a (3ds?) Nand backup;


(and if you still want to write it by now, seeing what happened :( )
 
Last edited by Valery0p,
  • Like
Reactions: JimmyZ
General chit-chat
Help Users
  • No one is chatting at the moment.
    Psionic Roshambo @ Psionic Roshambo: https://youtu.be/g3U7tCipvdQ