4 ms·

There is an easier way to produce sophisticated second stage shellcode than simply writing it in C and compiling it? There are certainly more tedious ways to w

by brl 18y ago

There is an easier way to produce sophisticated second stage shellcode than simply writing it in C and compiling it? There are certainly more tedious ways to write shellcode such as hand crafting position independent assembly code like it's 1997. Also, there are some failed experiments like writing a crippled C --> shellcode compiler in Python, but I'm not aware of anything that is simpler and more general than userland exec. You write the loader once and you're good to go (at least until Ulrich Drepper breaks your loader by refactoring ld.so).

tptacek 18y ago
Meh. You're probably right; being able to simply compile a Mach-O binary and load it over the network is more convenient than, say, proxying system calls or basic blocks like Mosdef.
- brl 18y ago
  > proxying system calls Locally calculating what needs to be on the remote stack then transferring it all across the network to a tiny 'syscall server' is very nice conceptually but turns out to have huge flaws in practice. The commercial implementation of this idea which you might be thinking of was completely replaced years ago by an executable that still executes individual system calls, but it accepts an XDR marshalled RPC protocol instead of raw bytes to place on the stack. This executable is statically compiled (well it has no library dependencies to begin with) and installed into memory with a very crude implementation of userland exec :)
  - tptacek 18y ago
    Mosdef was never just raw system call stack frames, but if you ask me about commercial syscall proxies, I don't think of CORE Impact; I think about BMC/BladeLogic, which provides a "remoted cygwin"-style interface built on syscall proxying. Again, you're right that just being able to compile and run an oblivious application is nicer than having a good remoting implementation; however, most exploits just use remoting. (I'm actually prepared to concede that this is a big win, since you're closer to shellcode development than I am.)

by brl 18y ago

tptacek 18y ago

Meh. You're probably right; being able to simply compile a Mach-O binary and load it over the network is more convenient than, say, proxying system calls or basic blocks like Mosdef.

brl 18y ago
> proxying system calls Locally calculating what needs to be on the remote stack then transferring it all across the network to a tiny 'syscall server' is very nice conceptually but turns out to have huge flaws in practice. The commercial implementation of this idea which you might be thinking of was completely replaced years ago by an executable that still executes individual system calls, but it accepts an XDR marshalled RPC protocol instead of raw bytes to place on the stack. This executable is statically compiled (well it has no library dependencies to begin with) and installed into memory with a very crude implementation of userland exec :)
- tptacek 18y ago
  Mosdef was never just raw system call stack frames, but if you ask me about commercial syscall proxies, I don't think of CORE Impact; I think about BMC/BladeLogic, which provides a "remoted cygwin"-style interface built on syscall proxying. Again, you're right that just being able to compile and run an oblivious application is nicer than having a good remoting implementation; however, most exploits just use remoting. (I'm actually prepared to concede that this is a big win, since you're closer to shellcode development than I am.)