Nice hack, though it won't usually work nowadays because instructions outside code segments will not be run by the operating system. You could also just use a char array as { 0xC3, 0xDD, ... } instead of using a string literal with escape codes.

Also, you're fired

Actually I did a goof off project in Windows not long ago where I composed bytecode into an array of unsigned chars and then call it. I expected a page fault, but never got one. It ran with no complaints.

It might be embedded to the code of the program, making it not complain when you run it...

Dynamically allocated. I actually allocated a huge buffer, then calculated the amount of it to use for data and the part to use for the bytecode that would manipulate said data. Insane laughter ensued.

Could have been DEP. I've upgraded my OS since then, so I can't check to see what the setting was.

If you want to do runtime x86 and x86_64 code generation properly (and yes, there's use cases for it), I would recommend using Xbyak. Nice little C++ DSL to generate machine code at runtime, complete with labels, jumping to them and all sorts of nice stuff.

FWIW: in my case I am using my own assembler library (BGBASM), where it is fairly common to basically just assemble globs of code (as textual ASM), and then call into it using function pointers.

this is also used somewhat in cases where normally inline ASM would be used, but is slightly more portable between compilers, and a little more flexible (since the code generated can be specialized based on settings at runtime or similar).


the assembler currently has x86 and x86-64 support, and also partial / mostly untested ARM and Thumb support, and misc things like an NaCl sub-mode (which aligns labels and similar), and uses an NASM derived syntax (and C inspired macro facilities).

its API is basically like begin/end pairs with a bunch of printf-like calls in between (this is what seemed to be what was most convenient for my uses FWIW).

it can also produce and accept COFF objects (also still used on Linux), and has wrappers code over some OS APIs (namely for loading DLLs and SOs). internally it uses a partly disjoint assemble and link stages, and the code is "linked" against the running program image using a big region of RWX memory.


currently there is no standalone download for it though (could put it online if anyone is interested), though AFAIK YASM can do something similar.

LLVM's JIT engine is pretty much the definitive kick-ass explosion-laden version of this concept :-)

I've never personally tested this, but http://msdn.microsoft.com/en-us/library/windows/desktop/aa366553%28v=vs.85%29.aspx indicates that VirtualAlloc or VirtualProtect with the appropriate PAGE_EXECUTE flag should allow it.

It's still horrible though. Even if there are sometimes reasons why you may want to do it, it remains horrible (just imagine trying to debug it!)