- Joined
- Jun 27, 2017
- Messages
- 734
- Trophies
- 0
- Location
- The Ruins of GBATemp (3DSTemp.net)
- XP
- 1,999
- Country
Homebrew Trying to hack DSi Camera
- Thread starter DRAGONBALLVINTAGE
- Start date
- Views 5,183
- Replies 44
- Likes 1
This is the stupidest post I've seen on GBATemp this month. Congrats.
- Joined
- Jun 27, 2017
- Messages
- 734
- Trophies
- 0
- Location
- The Ruins of GBATemp (3DSTemp.net)
- XP
- 1,999
- Country
- Joined
- Jun 27, 2017
- Messages
- 734
- Trophies
- 0
- Location
- The Ruins of GBATemp (3DSTemp.net)
- XP
- 1,999
- Country
Seems like all you did was figure out that the dsi is unable to view large images
1. DSi Photos are signed
2. It doesn't accept anything other than a signed photo
3. You need different code to achieve a crash
- Joined
- Jun 27, 2017
- Messages
- 734
- Trophies
- 0
- Location
- The Ruins of GBATemp (3DSTemp.net)
- XP
- 1,999
- Country
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
- Joined
- Jun 27, 2017
- Messages
- 734
- Trophies
- 0
- Location
- The Ruins of GBATemp (3DSTemp.net)
- XP
- 1,999
- Country
D
Deleted User
Guest
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.
Yes, but that's like a severely small fraction of actually exploiting DSi Camera.
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
Last edited by Coto,
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.
And yes! Mr.NbaYoh has a tool on his github repo too.
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?
Last edited by Coto,
No need to get a bit aggressive...(like geez) You can just find a return address really too. (Don't know if that's considered ROP)
And I don't need to know your background really either.
Well if you haven't idea if ROP should be used to take over code, you shouldn't be suggesting to patch payloads on return address. My background is plain ROP to take over some irq on the gba. By default, the ROP is used as I wrote above.
So don't go correcting stuff if you aren't very clear about it.
So don't go correcting stuff if you aren't very clear about it.
Last edited by Coto,
Similar threads
