Morning Charles,
byte b={0xb8,1,2,3,4,0xc3}
print hex call @b
Not possible with your DEP turned on: access denied exception.
Hi Paolo,
Machine code is freeely runnable/writable is it stands in the heap?
how can Oxygen generate and run machine-code?
Also, in NewLISP, I saw examples of dynamically generated (and executable) machine-code too.
No, machine code doesn't reside in the heap. The memory image of an executable file is (very roughly and generally) divided into 4 parts:
-- program header that stores pointers to and sizes of program code, data, and resource sections of the program in the process memory;
-- code section(s) proper marked by the OS as non-modifiable (read/execute-only) memory areas;
-- data section(s) proper marked by the OS as modifialble (readable and writable) but non-executable memory areas; and
-- optional resource section that carries various icons, images, menus, dialog templates, strings etc. that the program may need for its purposes.
Apart from that, the program loader reserves two big chunks of memory that the program can use additionally outside its data section(s) in case it needs to create and destroy dynamic objects or pieces of data:
-- stack;
-- heap.
The stack is generally used for passing function parameters and allocating temporary pieces of data local to these functions. The heap is used to create both global and local dynamic objects such as arrays, strings (actually arrays of bytes), compound structures, and class instances. Both of these chunks are also usually marked as modifiable (readable and writable) but non-executable.
As you see, each process memory piece has a strictly predefined purpose and an associated expected behavior. Most user programs fit very well into this pattern but not all. Such programs as just-in-time compilers e.g. like OxygenBasic, FBSL, LuaJIT and some others will also need memory to dynamically generate and write additional executable code into. In this case the developer may use the VirtualAlloc/VirtualProtect/VirtualFree WinAPI's with a required set of readable/writable/executable attributes. These API's create and destroy additional data or code sections with an arbitrary mixture of attributes in the process heap chunk.
Unfortunately, this is exactly what most of the existing virii would do too for their malicious and destructive activities. Therefore, anti-viral software is taught to sniff unusual attribute combinations (mainly such as concurrent writable
and executable attributes), and to also monitor the VirtualAlloc calls.
Since anti-viral protection is considered more important than presumption of the developer's innocence, a lot of less intelligent AV packages (abundant as such sites as e.g. the notorious VirusTotal.com) invariably flag JIT compilers as suspicious/malicious software. Hehe, and it is a serious challenge to outsmart the VirusTotal.com bunch of shitcode AV software to avoid false alarms.
OTOH more intelligent packages with well-developed heuristics engines such as e.g. Kaspersky, Norton, Ezet and a few others would
never flag a JIT compiler suspicious.
So there are 3 conceivable ways to break this vicious circle for a JIT compiler project:
-- hire a guru that's smart enough to disguise your "suspicious" activities against the stupidity of shitcode AV's;
-- disclose your sources to the world and pay off the VirusTotal.com gang to include your JIT compiler on their exception list; and
-- subside forever to the turtle pace of fully interpreted code which
does not create writable/executable sections in the process heap at all.
Obviously, "Mr Burger from PicoLisp" has chosen behavioral pattern number 3 from this list.
My own indisputable option is however
pattern number 1.
