Jump to content


Photo

AllocAsm v0.1.1.0


  • Please log in to reply
9 replies to this topic

#1 cabreak

cabreak

    GMC Member

  • New Member
  • 93 posts

Posted 15 July 2010 - 05:55 PM

AllocAsm v0.3.2.0 (UPDATED)
------------------------------------

AllocAsm allocates memory in your application and allows you to add assembler instructions into the allocated memory,
execute them and store results in simple variables which you can use outside the dll.

This is especially useful for executing the same assembler instructions and bytecodes many times in order to increase performance and gain optimization.
Examples: Video editing, games, ...

You can use AllocAsm without giving any credit.
Source code is available on request. PM or email me (mariano@di-martino.net).



AllocAsm v0.3.2.0 includes:

AllocAsm.dll
FASM.exe (Flat Assembler 0.93.19.0. Freeware)
An empty asm.asm file.
A Game Maker file template (testdll.gmk)
This README.
License file of FASM.

Download link: AllocAsm v0.3.2.0

For more information: Read the README.txt

Edited by cabreak, 16 July 2010 - 11:40 AM.

  • 0
Visit my website: http://www.di-martino.net

#2 score_under

score_under

    Least kawaii

  • GMC Member
  • 1321 posts

Posted 15 July 2010 - 09:55 PM

Hate to break it to you, but this is really slow (at assembly time, not runtime) and is not very easy to use at all...

Is there even any way to write code without having to transform it into PIC? Try JMPing to a known address, see if it works.

Now, I know I've written an ASM DLL myself, but that's not why I don't think this is suitable.
Read your own limitations readme to find out why it's not suitable - it allocates a fixed size, it calls an exe file (BIG NO-NO!) to assemble an instruction, you can only see EAX,ECX,EDX (the volatile registers) and EBX... (why EBX and not the other 3 non-volatile registers? And why not ESP?), You can only use 4 variables, and it seems that you yourself do not know much assembly. (Which is why EBX is used as a non-volatile register, and why you present values in decimal that make sense only in hexadecimal.)

You provide an example for it, which does this:
mov eax,4
dec ebx
dec ecx
mov ebx,eax
push eax
pop eax
dec eax
Now, since we can't see what those instructions do while they're running... why didn't you just leave it as:
mov eax,3
lea ebx,[eax+1]
Or even better:
mov eax,3
lea ecx,[eax+1]
Or better yet, make it do something to prove it's running real ASM:
rdtsc
push edx
push eax
fild qword[esp]
add esp,8
ret
(But you'd need to implement FPU register saving)

Or, for a little windows showoffery:
xor eax,eax
pop edx
push eax
push title
push msg
push eax
push edx
jmp MessageBoxA

  • 2

Anti-Decompiler for GM6.1 to GM8.1.91! :GM8_new: [Main skin by Sindarin]
Discontinued.

decimal2.png
^ Signature image because it's been sorta empty since the old host died

If you need to contact me, I still get notification emails from PMs.


#3 cabreak

cabreak

    GMC Member

  • New Member
  • 93 posts

Posted 16 July 2010 - 09:46 AM

Hate to break it to you, but this is really slow (at assembly time, not runtime) and is not very easy to use at all...

Is there even any way to write code without having to transform it into PIC? Try JMPing to a known address, see if it works.

Now, I know I've written an ASM DLL myself, but that's not why I don't think this is suitable.
Read your own limitations readme to find out why it's not suitable - it allocates a fixed size, it calls an exe file (BIG NO-NO!) to assemble an instruction, you can only see EAX,ECX,EDX (the volatile registers) and EBX... (why EBX and not the other 3 non-volatile registers? And why not ESP?), You can only use 4 variables, and it seems that you yourself do not know much assembly. (Which is why EBX is used as a non-volatile register, and why you present values in decimal that make sense only in hexadecimal.)

You provide an example for it, which does this:

mov eax,4
dec ebx
dec ecx
mov ebx,eax
push eax
pop eax
dec eax
Now, since we can't see what those instructions do while they're running... why didn't you just leave it as:
mov eax,3
lea ebx,[eax+1]
Or even better:
mov eax,3
lea ecx,[eax+1]
Or better yet, make it do something to prove it's running real ASM:
rdtsc
push edx
push eax
fild qword[esp]
add esp,8
ret
(But you'd need to implement FPU register saving)

Or, for a little windows showoffery:
xor eax,eax
pop edx
push eax
push title
push msg
push eax
push edx
jmp MessageBoxA


Actually, the execution itself isn't slow at all. It jumps to the allocated memory and executes it.
And yes you can jump to an address outside the allocated memory, as long as you safely return.
These limitations I wrote are just because of my lack in programming time. They will be removed in further versions.

The DLL just writes opcodes to the memory to execute them later. That's not slow at all! You can use all Intel x86 opcodes.


mov eax,4
dec ebx
dec ecx
mov ebx,eax
push eax
pop eax
dec eax
And this is just an example.
Second, you're using a Borland dll , which is actually illegal without asking permission or including licenses.

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.


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.

Edited by cabreak, 16 July 2010 - 09:48 AM.

  • 0
Visit my website: http://www.di-martino.net

#4 score_under

score_under

    Least kawaii

  • GMC Member
  • 1321 posts

Posted 16 July 2010 - 05:29 PM

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?

mov eax,4
dec ebx
dec ecx
mov ebx,eax
push eax
pop eax
dec eax
And 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.
Posted Image
(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.

  • 2

Anti-Decompiler for GM6.1 to GM8.1.91! :GM8_new: [Main skin by Sindarin]
Discontinued.

decimal2.png
^ Signature image because it's been sorta empty since the old host died

If you need to contact me, I still get notification emails from PMs.


#5 cabreak

cabreak

    GMC Member

  • New Member
  • 93 posts

Posted 16 July 2010 - 06:17 PM

I'm not going to react on all your answers. But the dll is useful for me when I'm using it with Game Maker.
And ofcourse it's not stable at all, but you should better think twice before giving bad critic about someone you don't know.

Edited by cabreak, 16 July 2010 - 06:17 PM.

  • 0
Visit my website: http://www.di-martino.net

#6 score_under

score_under

    Least kawaii

  • GMC Member
  • 1321 posts

Posted 16 July 2010 - 06:25 PM

I'm not going to react on all your answers.

And I know why.

But the dll is useful for me when I'm using it with Game Maker.

When you finally find a use for it, please inform me :)

And ofcourse it's not stable at all, but you should better think twice before giving bad critic about someone you don't know.

"Not stable"? It's completely broken! I'll give bad critique to anyone who releases software that doesn't work.
The whole point of critique is not to get to know the person, it's to let them know what's wrong, so that they can pinpoint and fix it.
If you look down the bottom of my last reply, you should have all the info you need to debug your software properly.
(And by the way, yes, I was testing in 0.3.2.0.)

Edited by score_under, 16 July 2010 - 07:00 PM.

  • 2

Anti-Decompiler for GM6.1 to GM8.1.91! :GM8_new: [Main skin by Sindarin]
Discontinued.

decimal2.png
^ Signature image because it's been sorta empty since the old host died

If you need to contact me, I still get notification emails from PMs.


#7 sabriath

sabriath

    12013

  • GMC Member
  • 3197 posts

Posted 16 July 2010 - 06:59 PM

I would have to say that score_under is the foremost authority when it comes to assembly here at the GMC....being that he created a decompiler for GM and an anti-decompiler, along with many other useful things between. I personally would heed his suggestions on this matter, he is actually taking the time out of his schedule to point out your flaws so that you may fix them. It is far better than the alternative of just "letting it go" and someone ends up with a crashed system somewhere (or worse, must do a wipe) just because you failed to fix anything.

I'm also not sure what is going on in this dll...it's pretty confusing with all the Gets and Sets everywhere. Wouldn't it be much better to just have these instead:

code_pointer = assemble(asm_string)

Where "asm_string" contains the opcodes to be assembled and must end with a far return (a fall-through return is defaultly added). EAX can be used as the normal return register (like usual)


answer = execute_code(code_pointer, arg_count, args)

Where "code_pointer" was the location of the previously assembled code. Prior to executing the block, args are pushed onto the stack, and after the return, the stack is cleared of them.


free_code(code_pointer)

free up the memory used by the assembler


It looks pretty straightforward and a lot less hassle with Gets and Sets. Even easier would be to do a little pre-work before assembling like:

move eax, arg1
move ebx, arg[2]
add eax, ebx
ret

Since assemblers don't understand "arg" as a variable, this is where the pre-work comes into play. By defining "arg#" as specific positions in the stack relative to EBP because we have this as the header to our call:

push ebp
move ebp, esp

Then we can figure out that "arg1" would be "EBP+8" (4 for the EBP push, and 4 for the RET call), so a simple string replacement for that. As for "arg[#]" we would need to do a little bit more work, but I've been out of assembly for awhile, so there might be an easier way.

Good luck though!
  • 0

Tutorials of Interest:
* Multiplayer: mine or True Valhalla's

Projects:
* Net39
* My 39dll scripts
* My 39dll lib
* Multiplayer Engine
* Artificial Chemistry

Posted Image

#8 Captain Cook

Captain Cook

    GMC Member

  • GMC Member
  • 55 posts

Posted 28 September 2010 - 01:50 PM

Since you apparently can't be bothered to listen to what score_under has to say, I'll keep my post short and sweet:

Your DLL is crap.

That is all.

EDIT:

but you should better think twice before giving bad critic about someone you don't know.


Or what? You'll play Internet Tough Guy and threaten to beat people to a pulp despite being completely unable to even find out where we live?

Grow up, man.

Edited by Captain Cook, 30 September 2010 - 02:28 PM.

  • 0

#9 jobro

jobro

    GMC Member

  • GMC Member
  • 1300 posts
  • Version:GM:Studio

Posted 04 October 2010 - 02:49 AM

I must say that this is an intresting prospect, but not for me. Assembler has never been my forte anyway. To much either can go wrong, or will go wrong. That's why I stick to C# or Delphi, but I intend to look up OllyDbg.
  • 0

Marketplace.png


#10 TheMagicNumber

TheMagicNumber

    GMC Member

  • GMC Member
  • 5247 posts
  • Version:Unknown

Posted 04 October 2010 - 03:25 AM

score_under's DLL is a better choice.
  • 0