The ability to run arbitrary code is very useful, especially for exploits like buffer overflows. The way to run such arbitrary code is by using what is called shellcode. Shellcode is machine language written in Hexadecimal format and is usually derived from disassembled flat binaries. Since shellcode is machine code, it is not portable and varies between Operating Systems and CPU architectures.
Writing Arbitrary Executable Code for x86 Linux Systems
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
What the hell is this shellcode they keep talking about?
The only thing I saw there are the hex values for x86 operations. That’s programming in HEX, not some made up shellcode thing.
If you grab yourself a hex editor you can make/alter any ELF/PE/whatever binary you like without all this nonsense. It’s just a pain in the backside working in hex and tracking addresses manually, that’s why assemblers were created in the first place.
I might be missing something, but I just don’t see what they’re trying to achieve here.
Shellcode is useful if you want to exploit a buffer overflow. Where buffer overflows occur there’s often an opportunity to inject an arbitrary memory location for execution. That memory location can be the start of a “shellcode” (aka “eggshell”) or as you stated a set of machine operations.
I think what he is trying to say is “why not write the program in asm directly instead of hex”, in the c-source file that is, as inline asm i suppose. Only reason I can think of for not doing that is including machine code where you can’t include asm code, or to limit the since of the source code or just to look much more elite.
With recent additions such as Exec-Shield (enabled by default in at least Fedora), buffer overflows like that won’t work anymore.
Shell code seems to be aking some executable, representing the bytes of the executable as a string and putting that string into some shell script.
In other words, we embed some binary executable in a ASCII text shell script program.
Except educating us about hacker methods, I fail to see a legal use of that technique..
Even embedding some tar archive into a shell script to create an install script, would be not useful, because this navive ASCII embedding blows up the storage size by a factor of 2 to 4.
So I really wonder why Eugenia posted that bit.
Regards,
Marc
Is this just a tutorial on how to hack or what? Doesn’t have much value it seems. Better would be an article on how to prevent situation where this code could be run.
This is useful for the sysadmin to know what happens behind the scenes when your b0x is 0wnz3d. Knowing what’s happening in the mind of the h4x0r creates ph33r, and ph33r leads towards patching your system in a timely manner, reading logs every once in a while, and enforcing good passwords.
I think what he is trying to say is “why not write the program in asm directly instead of hex”, in the c-source file that is, as inline asm i suppose. Only reason I can think of for not doing that is including machine code where you can’t include asm code, or to limit the since of the source code or just to look much more elite.
We’re working with op codes, not asm! Asm still has to be translated to machine op codes.