Another weird machine you might find interesting (nothing to do with ROP though): the CIC "lockout chip" in the Nintendo Entertainment System. It's a very low-end microcontroller. What makes it interesting are two features: 1. The PC doesn't count linearly. Apparently to reduce cost, they used a shifter instead. So the addresses it will execute (without jumps) are 1, 2, 4, 8, 16... If it reaches 0 (and I think 127?) it will be stuck there. 2. The same chip exists in console and cartridge. They both send signals to eachother and expect a corresponding reply (sort of challenge response). To do this the two ROMs must execute in perfect lockstep so that one reads precisely when the other writes. The programs are carefully structured to ensure both sides of each branch take the same number of cycles. The ROMs are out there, I don't remember where, but probably on nesdev?
ROP and gadgets were developed much earlier than 1997 and were broadly used at least in 1984. May be earlier. Some microcomputers of the days used ROM-based firmware for external devices or even the operating system. The ROM-based code was somewhat "priviledged" - major address bus bits, corresponding only to the ROM region were used to map some ports or even buffers to the address space. User code was placed in the addresses, that locked out hardware specific things so there was no direct control over them. But "gadgets" found and executed in the ROM via stack modification made direct hardware ports and buffers hacking possible. I personally used this to make Sinclair ZX-Spectum TR-DOS system do things, original firmware could not do. Also it was buggy, never updated and this was the only way to make some thing work anyway.
A similar exploit can be used to dump the Nintendo DS BIOS. Only code within the BIOS region can read it, but you can just craft a stack frame and jump blindly into the end of a function that will just read an arbitrary address and return.
That's right, it's a common technic in console hacking, especially the old ones with little to no RAM. The same goes for embedded hacking. My point was to let people know that smart hackers were there decades ago. I hope it'll motivate some one to dig deeper and surpass the ancestors, not just become on par =^_^=
Actually, TR-DOS mapped it's ROM over the main ZX-Spectrum firmware just in the moment CPU jumped to specific address range that had no executable code in it (there was a font or text resources, I do not recall now). So the firmware was "visible" only for itself. A common technic of the days. Nowdays iit s common to trick a device with a request, supposed to return some data, but force it to return a part of firmware dump or something. Hope we will see something like that here too/
I just learned about the existence of ROP while I was studing for my operating system exam this week and now this video pops up. What kind of wizardry is this? Perfect timing :)
Very much looking forward to your ROP video! I'm curious to what extent American Fuzzy Lop and/or other fuzzers can be used to generate weird machines.
This is why bounds checking is critical, especially for any input. ROP vulnerabilities sometimes happen when a programmer doesn't take the time to secure their program design, OS security features can't prevent insecure programs.
@@alexisramirez2007 what exactly do you think you can't do with rust? ( at the very least the user interface part of every application should be rust with bindings to whatever assembly/C is required)
@@TimLF You have a point, I mostly program Linux applications with C and ASM for security challenges or niche pet-projects. I have neglected exploring practical languages for applications, such as rust.
If you have dependent types you can make the lack of bounds checking a compile time error. For simple cases where the size of the array is static, the compiler can just do the bounds checking at compile time instead of requiring you to write it. This means you don't have to pay for bounds checking if you don't need it. Also, these bounds checks don't have to happen at access time. You can check the size of an array at the start of a function with a check and the compiler can use that single check for all your accesses. This technique has no runtime overhead (unless you are counting insecure applications which don't bounds check dynamic sized arrays)
Hey, I don’t really have a preference. Thanks for even considering it! Whatever you prefer - I explain my thoughts with both systems in a Video you can also find on the Patreon page or my channel. Please watch that first :)
Those gadgets and code snippets are already inside the program. We did not inject those. We just use/abuse them to construct our own programs. Shellcode would be, if we create assembler code, get it via input into the program‘s memory, and jump to it. But I think you should checkout the basics of buffer overflows in the binary exploitaion playlist first :)
That is really mindblowing LiveOverflow. So you basically exploit a program in that way, that you can create a whole programming language upon this fucked up environment ? That just insane ! That's twisted insane..... No Words for that :D Oh, by the way a philosophic question: " Is not every machine a weird machine ? " I bet you can abuse any program, hardware, microcontroller in a way nobody thinks of.
What if your compiler also is a weird machine in itself...and the produces outmout a weird machine in itself as well.... Its weird machines all the way down..
Hii Everyone.. How to download "Hopper Disassembler for mac free full version" I have been searching for crack of it, but didn't get yet.. So Is there any way to get it free or otherwise I have to purchase it.
@@LiveOverflow I am student, I don't have additional Resource of Income, Can you please help me out, any how?? And I need that software for Binary Exploitation..
@@LiveOverflow Yaa, I am using Ghidra, but I am beginner for CTFs And Hopper's Interface is more convenient than Ghidra. THANKS for your all videos and knowledge. It's all worth to watch. I am following your channel For CTFs. Again Thanks you so much.
