Unfortunately I haven’t taken the time to document the work I’ve been doing on the 3DS lately here, even though it’s been pretty extensive. Normally, I’d try to cover things chronologically, but since I decided to reveal a new exploit today, it kind of takes priority as there’s a lot of stuff I need to clear up. To start off, here’s a video showing ssspwn in action :

What it is, what it isn’t

If you’ve read my (now really old and outdated) article on 3DS hacking, you’ll recall that for a number of reasons, hacking the console happened by chaining multiple exploits with one another. The most widely used hack (used by flashcart teams, myself and a number of other people) reliies on not one but two completely distinct exploits : the mset DS user settings exploit, which gives us arm11 usermode ROP capabilities, through which a FIRM vuln is exploited to obtain arm9 code exec. This last part was fixed with firmware version 5.0, and it’s the real critical part : while there’s a pretty high number of games that could potentially be exploited through saves to do usermode ROP, it’s useless if you don’t have another exploit to chain that gives you code exec capabilities. This is where ssspwn comes in; it essentially replaces the FIRM exploit we had on 4.5 and lets us execute arbitrary code. That’s why the video looks similar to the one I’d done when I got 4.5 code exec : the first stage exploit used is the same, just fine tuned to work on 6.3.

What does that mean ? Simply that because the two exploits are completely separate, there’s no reason to believe that just because the mset bug was fixed in 7.0, so was ssspwn. That’s right; ssspwn has yet to be plugged by Nintendo, and could in theory give us code exex on latest firmware version. This isn’t the case yet because we haven’t really looked for a new entrypoint, but that’s the next step.

To release or not to release

Generally speaking, the thing that’s been stopping me (and others) from releasing working exploits has been the fact that they might be used for piracy. Fortunately, that should not be a factor in this case, as by its very nature, ssspwn can not by itself allow piracy. That’s right, it’s the sweet spot that gives us just enough to get awesome homebrew code running in arm11 user mode, but not enough to break the system bad enough to let anyone do whatever the hell they want. As such, I personally have no qualms with releasing the exploit into the wild.

You might be wondering why there isn’t a download link available yet. The reason for that is that, as I mentioned, ssspwn has yet to be fixed. In my opinion, it would be dumb to burn such a nice vuln on just 6.3 when we know full well that we should be able to use this on 7.x, and possibly even 8.x+ with some work.

Plan of action

Now, while I don’t think it’s a good idea to release this publicly just yet, I do think it would be a good idea to get it into the hands of devs with consoles still on 4.5-6.3 so we can make progress creating 3DS homebrew development tools. We’ve been making tremendous progress as it is, but we could do much more with some more talented and motivated developers. As such, I want to share this with as many reputable and available devs as possible so that they can work on making things ready for the (hopefully) upcoming 7.1+ release.

Do note that I don’t have a developer-friendly version ready just yet, but I will let everyone know as soon as I do.

Other thoughts

This is, in my opinion, the best shot we have at making a successful and accessible 3DS homebrew scene happen. I’m going to try not to fuck it up. That means that unfortunately the number of devs I’ll feel comfortable sharing the current iteration of ssspwn with will be rather limited, in an effort to avoid premature leaks. Even then, there’s a good chance this whole thing is a bad idea and that it’ll lead to the vuln being plugged before we ever get a chance to exploit it on latest system version. I’m choosing to trust people, and I sincerely hope it’s not something that will backfire.

On another, more personal note, this is my first own big boy exploit I unveil so I think that’s pretty cool.

Sorry it’s been a while since my last post; I was really busy in November and December and basically got no 3DS work done back then. Fortunately though my schedule’s cleared up quite a bit since then and I’m happy to say that I’m back on track and making some fairly good progress. Let’s start with a little video I uploaded last night :

For those of you too lazy to watch the video (you know who you are…), it shows me booting into redNAND mode on 7.1 from 4.2 (works on 4.1-4.5 ofc) and running a homebrew game contained within its own little channel, complete with custom icon and banner. It also gives some other stuff.

This video is a glimpse at what I want for the up and coming 3DS homebrew scene, ie a way for people to make their own homebrew applications and install so that they’re directly accessible from home menu. This has a number of advantages over running code “on the bare metal” as some are already doing. For one thing, it means that homebrew code will be strictly limited to user mode code, the same way commercial games and applications are, which drastically lowers the likelihood of anyone’s (*cough*GW*cough*) code accidentally bricking your console. For another, it means that our code will be able to interface with every service provided by the 3DS’s OS; it’ll make stuff like FS, wifi and GPU access much easier. And of course, it just looks cool having your own channel in the menu, and being able to return to menu and switch between games instantly is a nice plus.

For that goal to become a reality, we basically need two things : a way to create new channels and a way to install them. I’m proud to say that I’m taking steps to make creating channels possible, by starting ctrulib (whose code is freely available on github). The idea is to make interfacing with 3DS services easier, by providing functions designed to do so and example code to understand how they’re used. Of course it’s not much at the moment; very few services are implemented and the examples don’t necessarily use them in exactly the way they were meant to be used. Nevertheless, it already provides the basics; enough to do basic interactions with NS, the HID module for user input and the GSP module for VRAM and later on GPU access. It’s very much a work in progress and will only keep growing. yeti3DS is an example of what can be achieved with ctrulib at the moment; not much, but a pretty cool start if you ask me. yeti3DS’s code is also available on github.

Now the thing is, there is at the moment no public way to install new channels, which means that even though you can just clone the ctrulib repo right now and compile it, you probably won’t be able to run what it produces. The reason for that is, basically, that I don’t have an installer ready. That’s the next big step for me and I’ll have to ask you to be patient. There is a fair bit of work involved and while I do expect to have an installer POC ready within the next couple weeks, there’s no telling how long it’ll take to get a safe package ready for mass consumption; users have already suffered through enough bricks, I’d rather my software didn’t add to the list.

So sit tight ! We’ll have nice 3DS homebrew soon enough. Feel free to ask any questions you may have (other than ETA requests), I’m not sure how clear this post was. (I’m pretty tired…)

Unfortunately, I have not had any time to work on 3DS stuff in the past couple weeks. That’s ok though, as I did get a lot done before starting my hiatus (and I started writing an article about my 3DS work). Mostly, I was able to get NAND redirection working on my 3DS. Getting that done was not actually that hard a task. Really, what it took to get it running was a bunch of code analysis and reverse engineering. Not necessarily an easy thing to do, but since we did already have some information on how NAND and SD are accessed thanks to the (light) documentation present on 3Dbrew and the fact that it works in ways very similar to how it did on the DSi, it was really little more than a matter of time until we got it working.

NAND redirection in action. I’m calling it redNAND because I like silly names, but you don’t have to.

If you follow me on twitter, maybe you know that I bricked a 3DS while working on this. As far as I can tell, what happened is that while I’d gotten my NAND redirection code working for reading (as the 3DS did boot by loading all its data from my SD), I had not actually located and hooked the NAND writing code properly. Because of that, I guess the 3DS overwrote something it shouldn’t have on NAND, and somehow that broke everything. I don’t know for sure exactly what happened as I haven’t repaired that 3DS yet (simply reflashing an old dump to NAND *should* be enough to get it going again), but I think it has to do with game notes. My theory goes that because I had never gone into game notes before dumping my NAND (I’d just done a system reset to undo the potential side effects of a previous bad NAND write), the files which were supposed to contain its data had not been created. Because of that, going into game notes would create those files, which would normally be fine, but because it would be using the FAT table from my NAND dump while writing to my actual NAND, obviously things would go wrong and it would and up messing stuff up. Not 100% sure about this as there are some discrepancies in my theory (iirc the console crashed before it got to the point where it would show the game notes initialization message), but so far that’s the best explanation I’ve got for what happened. Either way, redNAND seems to be running very well at the moment; obviously we’d need more than just the few of us who have it running atm to test it before an actual release, but I’ve used it on my 3DS for a number of hours while playing pokemon and so far no problem.

One of the less alarming side effects of messing with the 3DS’s NAND like a reckless idiot.

Which brings me to pokémon, and pokéhacking (yes, that’s a word now). I’d like to start by saying that I’m not in any way a “pokéhacker”; I did what I did for fun and because people were curious, and I was all too glad to be able to help out in finding out some secrets. Overall I’d say it was a positive experience. I wasn’t expecting for something so simple to make such a big impact, and frankly it’s a little frustrating that now a large chunk of the messages I get are from people who want to buy hacked pokémon from me. I was also disappointed in the reaction of some “hardcore pokéhackers” (because apparently, I was expected to share the game’s full decrypted code… which obviously wasn’t going to happen). But what can you do, live and learn I suppose.

For the unitiated : shortly after I got redNAND up and running on my 3DS, I got ahold of a copy of pokemon Y. As I was now able to run it on my console while running my own unsigned code in the background, which meant I could not only take in game screenshots, but also make full ram dumps. Being able to dump RAM in game meant being able to see the game’s code, some of its ressources, but also of course it meant being able to analyze it to create cheats. Now, I *really* wanted to capture a mew for no appropriate reason so I decided to make a cheat that would allow me to do so. That wasn’t actually very hard. It stood to reason that the possibly encounterable pokémon in a given area would have to be stored somewhere in memory. With that in mind, I started asking around to see if anyone knew of such structures in previous games. That’s how I ran across Kaphotics, who confirmed my intuition by graciously providing encounter tables from previous pokémon games. From there, I listed the pokemon I’d encountered in my area, wrote a python script to search through my ram dump to find an adequate-looking structure, and that’s how I found the encounter tables. Nothing too exciting in and of itself, but it allowed me to spawn unobtainable pokémon, and the rest is history.

Now, here’s to hoping I’ll have time to further my 3DS plans soon !

As you may have noticed, my web page has been through a number of changes during the last couple of weeks. First change you’ll notice is the website is now in english. I had been wanting to put up a couple of articles related to my work for some time, and I figured it would be better to write them in english for them to reach as broad an audience as possible. Because of that, it only made sense to switch the entire devblog to english. Rest assured, you can still write comments in french if you want to, but future posts and articles will all be written in english.
You’ll also notice I changed the theme for something a little more modern. Not overly so, it’s still a very simple layout. I’m not happy with everything about it at the moment so there will still be a few changes here and there in the coming days/weeks, but nothing major. (not a fan of how article titles are rendered at the moment for instance).
Finally, as I mentioned above, I’ve started writing a number of short articles related to the work I’ve been doing for the last couple years. They’re all very much WIP at the moment, but more complete versions should be up soon enough, so stay tuned !

pas trop le temps/envie d’entrer dans les détails pour l’instant, mais c’est quand même quelque chose d’un peu gros donc je poste.

il y a quelques jours, après quelque temps à bosser avec ichfly et normmatt, j’ai réussi à faire tourner mon propre code non signé sur ma 3DS ! donc ces jours-ci c’est là dessus que je bosse, plein de RE dans tous les sens. pas de release pour le moment parce que c’est vraiment pas prêt, mais à terme j’espère que ça permettra à un peu tout le monde de faire tourner du homebrew en mode 3DS. seul truc c’est que ça ne fonctionne que sur la version 4.5 du firmware, mais bon ça reste pas trop mal…

plus d’infos dans la description de la vidéo :