4 ms·
A lot of those crashes are probably running executable code that the attacker hasn't bothered to write yet.
by p1mrx 3y ago
A lot of those crashes are probably running executable code that the attacker hasn't bothered to write yet.
- ok123456 3y agoCooperative multitasking means the chances of pulling anything off without completely crashing or hanging it is slim.
- lmm 3y agoNot really. Once you get it running your exploit payload you can put the required yields in there no problem (or just let it crash after it's finished running your payload). Worst case you might have to be a bit more careful with how you get there (sprinkle some yields in your NOP sled or something), but it's at most a speed bump, not a real countermeasure.
- ok123456 3y agoEfficient Windows 3.1 programs are like a giant FSM clockwork where each event loop task is broken into small enough chunks to yield back the processor in a reasonable amount of time. Crafting an exploit that does anything beyond crashing the program or the computer would require knowing how this was done for a particular program.
- lmm 3y ago> Crafting an exploit that does anything beyond crashing the program or the computer would require knowing how this was done for a particular program. No it doesn't. You can run your exploit code and then crash the program, same as exploiting any other program. Or you can add some minimal code on the end of your exploit payload to exit cleanly. If you really wanted to gold-plate it by having it resume the program where it had been then yes, you'd need to figure out some details, but that's not normal or necessary - classical "smash the stack" style exploiters rarely tried to unsmash the stack afterwards, they'd execute their payload and then exit or crash.