Actually, the execution itself isn't slow at all. It jumps to the allocated memory and executes it.
As I said. I said that assembly was slow, not the code itself.
And yes you can jump to an address outside the allocated memory, as long as you safely return.
That's not the point. Did you know that if you move a CALL 0x401000 to a different place in memory, it will call somewhere different and most likely crash? It's a position-dependant opcode.
Use OllyDbg to find the address of ZwRaiseHardError, and try to get the process to raise a hard error. (Try it in some other language to see what it looks like). Once you have the address, try to call it from your program (since it's in NTDLL, it won't change addresses between processes unless you update your system). I assure you that it will call somewhere completely unrelated, and raise.... a soft error.
These limitations I wrote are just because of my lack in programming time. They will be removed in further versions.
Then why release it now, and not wait until later? Also, why four variables? You could very easily allow for allocation of one more.
You can use all Intel x86 opcodes.
Except position-dependent ones?
dec eaxAnd this is just an example.
...did you read my whole post?
Second, you're using a Borland dll , which is actually illegal without asking permission or including licenses.
Actually, I compiled it with a free version of Borland's compiler, and it is a runtime DLL - necessary to distribute with all Borland C programs. If it were illegal to distribute, it would make it illegal to distribute any program compiled in Borland C.
I've added SetOwnValueA,GetAdressValueA .. to make it easier to hold variables without making use of pointers. That's already pre-assembled in the DLL.
By the way, an "A" on the end of a function name conventionally means "ASCII version" (as opposed to W, "Wide (Unicode) Version"). It is not used as an identifier, which could much more easily be used by an argument, instead of copy-and-pasting code everywhere.
My Dll is made to execute the same opcodes a couple of times with different "variables".
If you're going to assemble instructions at run-time, well yes, then it's slow.
So you mean your DLL is not slow so long as you manually assemble everything? Meaning that there's no point in including an assembler at all, this might as well just be a "memory allocator" library?
I also see you're using WriteProcessMemory to write the values... What on earth possessed you to do that? That is possibly the single slowest way to deference a pointer that you could possibly have imagined.
...Oh, look at this, I've just played with it a bit more, and... it doesn't actually work at all.
(Note that the line the debugger has run to is the line that it [wrongly] crashed at.)
1. It always skips the first byte of output.
2. You're assembling for the 8086 (generating the wrong opcodes), you should be targeting i386 and above.
3. mov ecx,-1 crashes it. (So long as it's not the first instruction)
3b. mov cx,0xCCCC crashes it. (so long as it *is* the first instruction)
3c. ...as does "or al,-1" as the first instruction. The list goes on, and on, and on...
[After adding a NOP byte to the start and setting the correct processor to target: ]
4. Calls crash it.... while it's trying to assemble.
5. Trying a JMP to 0x7C90D9BE crashed it - it got assembled as a JMP to 0x7EC0F84B!
6. Trying to set EAX to this value and then CALLing EAX still crashed it. I don't even see how that's possible.
7. You clobber the EBX register past the return of the function.
In short, calling this "not ready for release" was practically a compliment, as it doesn't work. You claim to be able to use any instruction? Only if you pick your instruction very carefully!
I would also like to point out that if you want to target ASM programmers, you have to know some basic ASM yourself, too.
Edited by score_under, 16 July 2010 - 05:41 PM.