Understood, but I would appreciate if you didn't actually press things like know your ABC(s)
Homebrew Trying to hack DSi Camera
- Thread starter DRAGONBALLVINTAGE
- Start date
- Views 5,190
- Replies 44
- Likes 1
I never go pressing people. I learn as much as everyone. And if it works, hey, amazing
But you should not correct someone that already succeeded, if you haven't.
But you should not correct someone that already succeeded, if you haven't.
"ROP is not needed for DSi exploitation"
Dude, ROP is the base to takeover. ROP allows you to takeover code from data aborts (if the game routine is set to treat the source abort), reach exception vectors to load later stages, or even buffer overflows by injecting stuff to heap. If you say "patch the return address", well you learnt to reverse engineer and exploit some routine. But then suggesting that ROP is not required is far from the truth.
ARM:
Let's say you found an entrypoint. You generate a payload through C -> ASM. How would the relative address from the current instruction in the ROP code be enough to reach, say the outter 32M of scope? would a branch with link (in ARM), be effective there? what if not?
ROP code as a "trampoline"
Dude, ROP is the base to takeover. ROP allows you to takeover code from data aborts (if the game routine is set to treat the source abort), reach exception vectors to load later stages, or even buffer overflows by injecting stuff to heap. If you say "patch the return address", well you learnt to reverse engineer and exploit some routine. But then suggesting that ROP is not required is far from the truth.
ARM:
Let's say you found an entrypoint. You generate a payload through C -> ASM. How would the relative address from the current instruction in the ROP code be enough to reach, say the outter 32M of scope? would a branch with link (in ARM), be effective there? what if not?
ROP code as a "trampoline"
(I know the familiarization of ROP)
No the, "But you should not correct someone that already succeeded, if you haven't."
What's with the succeeded stuff about?
EDIT: You don't know my accomplishments to actually make a statement saying I didn't succeed.
Like what do you mean by that
Last edited by ChampionLeake,
You tried to correct me. I showed ROP code. You said it wasn't necessary for DSi exploitation.
I gave you a good reason to use ROP if the map was far, but still exploiteable.
And now you push questions?
I don't give a fuck if you are an exploiter, researcher or whatever, don't come here saying ROP is not necessary for DSi related exploits, since ROP is like the base for exploitation.
I gave you a good reason to use ROP if the map was far, but still exploiteable.
And now you push questions?
I don't give a fuck if you are an exploiter, researcher or whatever, don't come here saying ROP is not necessary for DSi related exploits, since ROP is like the base for exploitation.
I don;t care about the ROP part. Where did the successor part come from? Was it really necessary to say that without knowing another person's achievements? that's why I asked where did that term come from.
You're getting so defensive from something small like a mistake. You're treating this whole ROP thing like it's your whole life. You really didn't have to get defensive.
EDIT: To answer your question, you can use shellcode really for execution. And I don't remember if the DSi has W^X but with jumping I have to agree with ROP somewhat is involved in it.
Last edited by ChampionLeake,
I am the least "achievement guy" you can find out there, I do love machines and inventor related stuff. But you came by saying rop was not necessary for DSi, you suggested simply tracing an exploit, and patch the LR of the already taken code.
You said I did not know about your work, I know about your work, it's impressive.
But saying that ROP is not necessary, well that is not true.
Stack pivoting would be preferred there. If the source exploit isn't coming from the outside, (such as a memcpy or strcpy that got his string ending character modified), then a ROP code is 99% ensured to exist to take over code.
So i'm not "offensive". But your background really misses the whole ROP point. (not reverse engineering bugs) but rather exploiting the
https://en.wikipedia.org/wiki/Instruction_scheduling
path a binary comes default with
You said I did not know about your work, I know about your work, it's impressive.
But saying that ROP is not necessary, well that is not true.
Stack pivoting would be preferred there. If the source exploit isn't coming from the outside, (such as a memcpy or strcpy that got his string ending character modified), then a ROP code is 99% ensured to exist to take over code.
So i'm not "offensive". But your background really misses the whole ROP point. (not reverse engineering bugs) but rather exploiting the
https://en.wikipedia.org/wiki/Instruction_scheduling
path a binary comes default with
Let's clear some things up here. ROP is *not* required for DSi exploitation. ROP is the hacker's answer to DEP, aka Data Execution Prevention. The DSi's processor does *not* use DEP. In that case, if you have a buffer overflow, you can simply put your shellcode in the buffer you overflow, then redirect program execution by overwriting something important. That might be a return address or vtable pointer, etc. but that's not ROP, you aren't programming anything, really, just redirecting execution to your shellcode. I suggest you learn and understand before spreading misinformation.
ROP is the default method to takeover code, what the fuck does DEP have to do here? DEP is just hardware/software protection region mechanisms.
shellcode is just the packaging of your usual ROP code. So that counts as misinformation from your part.
The DSi has a MPU, used to prevent writes from certain regions. To protect payloads running at, say, vectors. MMU extends that so you have physical memory mapped to virtual memory, a way to page memory very efficiently, disregarding any heap/memory related issues such as fragmentation. And to isolate memory between processor modes
ROP is Return Oriented Programming. It's *required* on 3ds, switch, etc. because the .text section (where code usually lives) is Read Only, while the data sections (.rodata, .data, .bss, etc.) are marked as read/write but not executable. What I've just explained is how DEP works. ROP is where, rather than programming in straight assembly, you use bits of code already in the .text segment (since it's read only, and the only area that's executable) and the stack (which holds return addresses among other things) and you put a chain of return addresses (which can be arbitrary addresses in the program; essentially you can jump anywhere within .text and expect anything there to execute.) That jump to snippets of already present code just before return instructions. These bits of code (called gadgets) can then be combined to do other tasks. This is entirely different from for the DSi. While ROP is possible, it's much harder than just writing some assembly for a specific task, overflowing the stack, heap, etc. and in doing so, placing your code there, then using a single return, or jump (from i.e. a vtable) to get the program to jump into your code there. The DSi MPU is not configured to make the stack/heap/etc. non-executable, as such, they're configured as RWX (all sections mentioned.) So you can overwrite .text and jump to arbitrary code within .data, .rodata, etc.
EDIT: also, I didn't really fully read your post. Shellcode and ROP are nothing alike.
Last edited by dark_samus3,
I can say it can be used but
With shellcode, you just write your program
Sometimes with limitations, but that's still easier
Also if you have a constant code addr then it really isn't needed since no XN is present.
the MMU does that yes. But DEP is misleading, I could say MMU page tables. DEP is x86 specific? i dunno.
MMU behaves in ARM cores likely as "DEP", but if I weren't to know how gbaemu4ds works I wouldn't know about MMU/MPU things.
Also, as part of ROP code, you need to raise from userland to kernel. And this is where ROP code comes in handy. (2nd stage payload), an "exploit" to reach kernel level. So yeah, ROP IS neccesary in your example lol
so ROP here takes over MMU memory already assigned by a process, so you gain control. Privilege escalation... but for that ROP is still needed. because ROP does everything, and that was my point. If you add ROP to an exploit, you just need to figure out how to do privilege escalation
Last edited by Coto,
DEP is a generic name for making the stack and data sections not executable. ARM's specific name for it is XN/NX (eXecute Never or Never eXecute, whichever way you want to say it) but the concept is the same. Anyway, most of what you've said here is basically gibberish. I suggest a CTF like microcorruption. Get some experience
Not to mention.... You realize the DSi has no kernel, right? Really, do some research. Learn some assembly and basic architecture.
Last edited by dark_samus3,
The DSi has no kernel, but the MPU has half of it, just the page tables removed. Otherwise it would be an MMU. Also, the "kernel" for you is just the highest processor state, where the memory management unit has no effect (highest privilege). As you'd run PSR bits 0x1f in ARM mode, MPU enabled, then exceptions would be ignored.
But you did knew that right?
I'd say you are talking trash / gibberish, or adding an extra extra definition for ROP.
ROP is just Return Oriented Programming, which is NOT skipping the subsystem protection zones, i'd say that term was added later on, it's just gaining control of the program through executable memory it wasn't meant to, using ROP gadgets. And by the latter, it does not necessarily mean, from a subsystem with region protected mechanism. But just a system that could *just* run ROP code it wasn't meant to.
Wikipedia has ROP code by running exec. code in memory the memory management unit has protected, and not meant to, and a way to run ROP gadgets in sections not protected. That's wrong.
http://www.security-faqs.com/what-is-rop-and-how-do-hackers-use-it.html
Code:
They used a technique called ROP as I spoke of before. The whole point of ROP is to allow a normal program to run and then the attacker takes over the space right before the return point in that same program. This usually happens in the stack portion of the memory. A program is usually broken down into sections called functions when it is loaded in memory and these sections are stacked on top of each other. The program follows the list of instructions until it either hits a portion that tells it to go to another part of memory or it hits the return portion. When the program executes, right before you get to the return point in the function, the attacker places a little bit of machine instruction into the prior memory space and there you have your exploit.
Last edited by Coto,
*Sigh* alright, here. I'm stuckpixel. (I can verify this for you if you like, but whatever) I hate pulling rank, but I'm tired of this argument. I've exploited the DSi. I wrote the exploit code for rocketlauncher. We use 0 ROP and the people you originally started this argument with have also used 0 ROP in their exploits. Do some basic research first. I've clearly outlined things. Anyway, no, kernel is not the highest state, it's just not there. The DSi has no OS and thus is always running in the highest processor state. You can directly control the MPU easily. The MPU has essentially nothing to do with things, though. As I mentioned before, it's configured such that everything is RWX. That means: put code in any place in memory and jump to it somehow to win. That's called shellcode. We use it for rocketlauncher. I've already outlined ROP, what it is, and why it's necessary. Stop spreading misinformation.
I am not spreading misinformation. You found exploits by reverse engineering bugged code and made your way through ROP. But my bet on ROP (as I wrote that irq patch handler for gba) still counts as ROP. But not as an exploit, but just plain, old, simple ROP.
https://blog.trendmicro.com/trendla...ulation-risky-understanding-meltdown-spectre/
So pretty much the missing page table bits from a MPU (turning the system into a MMU system) would allow the DSi system to have "kernel", but that's just a processor state with managed memory.
Last edited by Coto,
I didn't write any ROP. ROP is jumping to bits of code that were already there (so, for example, Launcher code that's loaded into memory.) and using it to form a "program" that does what you want. I've already outlined this, but you obviously didn't listen. I don't jump into any of launcher's code, I don't use anything but a single return. That's not programming with ROP, that's redirecting code execution. Huge difference. I use that single return that I control to jump into shellcode. This code is code I wrote directly, and I control all of it. I don't need ROP because I can just plain inject my code, then jump to it. Anyway, the meltdown and spectre link is hilarious; they're for sidechannel analysis, which has nothing to do with ROP. Linking to it as "evidence" that you're right just shows how little you know. Again, I did 0 ROP. I used shellcode. Learn the difference. Do a CTF, like microcorruption, to help yourself understand, because you clearly don't. Yes, you are spreading misinformation, you've spewed all kinds of gibberish that makes 0 sense all over this thread, then pointed to that and said "look, I'm right!" you can sit here and say all the things you want to make yourself look smart and right, but it doesn't actually make you either of those things. I really highly suggest doing some actual research rather than linking to unrelated articles, pulling in information from different architectures, and just plain ignoring information in my posts. It's all google-able, but you seem to want to seem smart rather than be right. In any case, I'm done with this waste of a time conversation.
Similar threads
