- Joined
- Jun 27, 2017
- Messages
- 734
- Trophies
- 0
- Location
- The Ruins of GBATemp (3DSTemp.net)
- XP
- 1,999
- Country
Thanks!This is the stupidest post I've seen on GBATemp this month. Congrats.
Another exploit for people without Flipnote StudioWhat are you trying to achieve?
Seems like all you did was figure out that the dsi is unable to view large imagesAnother exploit for people without Flipnote Studio
1. DSi Photos are signedAnother exploit for people without Flipnote Studio
1. I know1. DSi Photos are signed
2. It doesn't accept anything other than a signed photo
3. You need different code to achieve a crash
I doubt you'll make any breakthrough with that method you'd be better learning to program and learning assembly then decompile the camera app and look for any bugs in the codeAnother exploit for people without Flipnote Studio
How do you decompile a DSi app?I doubt you'll make any breakthrough with that method you'd be better learning to program and learning assembly then decompile the camera app and look for any bugs in the code
Probably with a program like ida pro but idkHow do you decompile a DSi app?
I thought someone created a DSi image signer a while back. I want to say it was Apache Thunder, but I'm not entirely sure.1. DSi Photos are signed
2. It doesn't accept anything other than a signed photo
Yes, but that's like a severely small fraction of actually exploiting DSi Camera.I thought someone created a DSi image signer a while back. I want to say it was Apache Thunder, but I'm not entirely sure.
I doubt you'll make any breakthrough with that method you'd be better learning to program and learning assembly then decompile the camera app and look for any bugs in the code
How do you decompile a DSi app?
yeah, pretty much what the first guy said.
You need to grasp the basic file formats (headers (or descriptors depending on the target), improve coding, learn assembly, learn how to gaze assembly from garbage/encrypted/images through hexadecimal, learn how to reverse engineer objects (ELF), learn ROP (a payload written in assembly where you take control of the original program), learn memory management related stuff, learn OS file handles, learn to deal with ISO IEC standards (so you get a shortcut or clues about the file you are dealing with)
edit: also learn how to reverse engineer binary blobs through IDA like, disassemblers.
An exploit works like this, take a look:
https://gbatemp.net/threads/nintendo-switch.474796/page-3
how I managed to find out that between the sea of EOF posts, I don't know lol
I thought someone created a DSi image signer a while back. I want to say it was Apache Thunder, but I'm not entirely sure.
ROP is not needed for DSi exploitation. You can just find an appropriate return address to paste either a generaltwlpayload or minitwlpayer depending on the size.
And your examples are fine fo learning how to RE code but some of them are a bit unnecessary. I just suggest looking at CTurt's write on exploiting NDS games so you can get a better understanding since some of his methods were used to exploit dsiware.
I don´t give a damn if you find them necessary or not. Having such knowledge will give a good insight when debugging / RE´ing blindly rather than relying on IDA-like debuggers. Your "exploit" approach comes from patching SDK stuff. By having a SDK symbol table traced and looking for bugs
My background comes from something like:
https://github.com/cotodevel/gbaARMHook/blob/master/arm9/source/pu/patches_to_arm.s
Besides, ROP IS necessary for any kind of exploits to be effective, even if you don´t know the SDK symbols way before.
How else are you going to takeover some code?