Executing raw machine code

[JRowe]

Here's the modified version I'm tinkering with, by the way. I'm using a test string instead of a file, but $str can be set to any file in the script directory using FileRead(@ScriptDir & "\anyFile.whatever")

CODE

; Created by Yudin Dmitry (Lazycat)

$str = "I AM A TEST STRING!!!!"

$timer = TimerInit()

$crc2 = Hex(FastCRC32($str), 8)

$timer1 = TimerDiff($timer)

MsgBox (0, "Result", $crc2 & " in " & Round($timer1) & " ms")

Func FastCRC32($vBuffer, $nCRC32 = 0xFFFFFFFF)

Local $nLen, $vTemp

If DllStructGetSize($vBuffer) = 0 Then ; String passed

If IsBinary($vBuffer) Then

$nLen = BinaryLen($vBuffer)

Else

$nLen = StringLen($vBuffer)

EndIf

$vTemp = DllStructCreate("byte[" & $nLen & "]")

DllStructSetData($vTemp, 1, $vBuffer)

$vBuffer = $vTemp

EndIf

; Machine code hex strings (created by Laszlo)

Local $CRC32Init = "0x33C06A088BC85AF6C101740AD1E981F12083B8EDEB02D1E94A75EC8B542404890C82403D0001000072D8C3"

Local $CRC32Exec = "0x558BEC33C039450C7627568B4D080FB60C08334D108B55108B751481E1FF000000C1EA0833148E403B450C8955107

2DB5E8B4510F7D05DC3"

; Create machine code stubs

Local $CRC32InitCode = DllStructCreate("byte[" & BinaryLen($CRC32Init) & "]")

DllStructSetData($CRC32InitCode, 1, $CRC32Init)

Local $CRC32ExecCode = DllStructCreate("byte[" & BinaryLen($CRC32Exec) & "]")

DllStructSetData($CRC32ExecCode, 1, $CRC32Exec)

; Structure for CRC32 Lookup table

Local $CRC32LookupTable = DllStructCreate("int["& 256 &"]")

; CallWindowProc under WinXP can have 0 or 4 parameters only, so pad remain params with zeros

; Execute stub for fill lookup table

DllCall("user32.dll", "int", "CallWindowProc", "ptr", DllStructGetPtr($CRC32InitCode), _

"ptr", DllStructGetPtr($CRC32LookupTable), _

"int", 0, _

"int", 0, _

"int", 0)

; Execute main stub

Local $ret = DllCall("user32.dll", "uint", "CallWindowProc", "ptr", DllStructGetPtr($CRC32ExecCode), _

"ptr", DllStructGetPtr($vBuffer), _

"uint", DllStructGetSize($vBuffer), _

"uint", $nCRC32, _

"ptr", DllStructGetPtr($CRC32LookupTable))

Return $ret[0]

EndFunc

The $CRC32InitCode is

typedef unsigned long uint; 

void CRC32_Init(uint* table) { // uint table[256] 
  uint i, j, poly = 0xEDB88320, CRC; 

  for(i = 0; i < 256; i++) { 
    CRC = i; 
    for(j = 0; j < 8; j++) 
      if(CRC & 1) 
        CRC = (CRC >> 1) ^ poly; 
      else 
        CRC >>= 1; 
    table[i] = CRC; 
  } 
}

and the $CRC32Exec code is:

uint CRC32(unsigned char* buffer, uint len, uint crc32val, uint* table) { // init: crc32val = 0xFFFFFFFF 
  uint i; 
  for (i = 0; i < len; i++) 
    crc32val = table[(crc32val ^ buffer[i]) & 255] ^ (crc32val >> 8); 
  return ~crc32val; 
}

[jennico]

sorry if i am stupid, but i have two questions:

1. okay, crc32 reads my 16 mb .txt file in 200 ms. this is a-ma-zing. but where can i find the read data now ?

2. is it possible to use it for simple mathematic operations ? Example:

asm
    mul edx
    div ecx
    mov eax,   edx
end

this would enable modular arithmetic operations with real 64bit int beyond AutoIt limitations. (i am working on that)

regards

j.

[JRowe]

This is the equivalent of dllCall. You can write a c or c++ plugin that does this more simply, using the plugin SDK. You can also write a dll in any language and call it from AutoIt.

What this snippet does is create data that's identical to a dll loaded in memory, allowing autoit to run a function on it's own, using the hardcoded data, as opposed to utilizing an actual, compiled dll.

I think there might be a *tiny* bit less overhead involved with this method compared to plugins, but overall, you'd be better off using the plugin SDK, writing your function in c and compiling under an x64 compiler, and just use MyFastMathFunction(number, number, number, number) in a regular autoit script.

[jennico]

well the thing in my example is, that it handles large integers like

mod(2121233235543365*2121233235543365,523222543435658)

.the final result will not be very high since it's a modulo but the intermediate product is beyond 64 bit and can therefore not processed directly.

though its off topic then, could you show me how to use dllcall with this data ?

Dim $tStruct = DllStructCreate("double");or uint64 or int64 ?
DllStructSetData($tStruct, 1, DllStructGetData($tStruct, 1) +2121233235543365)
DllStructSetData($tStruct, 1, DllStructGetData($tStruct, 1) *2121233235543365)
DllStructSetData($tStruct, 1, DllStructGetData($tStruct, 1) /523222543435658)
$result=DllStructGetData($tStruct, 1)

but this does not give the result, no ?

j.

edit the result is the Int of the division, not the remainder. how can i achieve the remainder ?

j.

Edited October 5, 2008 by jennico

[tip]

Hi all,

This is the equivalent of dllCall. You can write a c or c++ plugin that does this more simply, using the plugin SDK. You can also write a dll in any language and call it from AutoIt.

What this snippet does is create data that's identical to a dll loaded in memory, allowing autoit to run a function on it's own, using the hardcoded data, as opposed to utilizing an actual, compiled dll...

I'm trying to understand how CallWindowProc work with no luck. So I thought a direct example can be very usefull to everybody .

Can any one give some simple examples with CallWindowProc dllcall method?

Like how can these type of dllcalls can be made using CallWindowProc method:

Func _gzopen($Path, $Mode)
    Local $Ret = DllCall($_ZLIBDLL, "ptr:cdecl", "gzopen", "str", $Path, "str", $Mode)
    Return $Ret[0]
EndFunc

Func _gzread($File, $Buf, $Len)
    Local $Ret = DllCall($_ZLIBDLL, "int:cdecl", "gzread", "ptr", $File, "ptr", $Buf, "uint", $Len)
    Return $Ret[0]
EndFunc

I think I figured out the start but I'm not sure how to make the actual dllcall.

$zlibOpcode = "0x..."
Local $ZlibOpCodeBuffer = DllStructCreate("byte[" & BinaryLen($zlibOpcode) & "]")
DllStructSetData($ZlibOpCodeBuffer, 1, $zlibOpcode)


    
    Local $Ret = DllCall("user32.dll", "uint", "CallWindowProc", "ptr", DllStructGetPtr($ZlibOpCodeBuffer), _
                                 "ptr:cdecl","gzopen", _
                                                                 "str", DllStructGetPtr($Path),...

Thanks in advance

Regards

Tip

[trancexx]

Hi all,

I'm trying to understand how CallWindowProc work with no luck. So I thought a direct example can be very usefull to everybody .

Can any one give some simple examples with CallWindowProc dllcall method?

Like how can these type of dllcalls can be made using CallWindowProc method:

Func _gzopen($Path, $Mode)
    Local $Ret = DllCall($_ZLIBDLL, "ptr:cdecl", "gzopen", "str", $Path, "str", $Mode)
    Return $Ret[0]
EndFunc

Func _gzread($File, $Buf, $Len)
    Local $Ret = DllCall($_ZLIBDLL, "int:cdecl", "gzread", "ptr", $File, "ptr", $Buf, "uint", $Len)
    Return $Ret[0]
EndFunc

I think I figured out the start but I'm not sure how to make the actual dllcall.

$zlibOpcode = "0x..."
Local $ZlibOpCodeBuffer = DllStructCreate("byte[" & BinaryLen($zlibOpcode) & "]")
DllStructSetData($ZlibOpCodeBuffer, 1, $zlibOpcode)


    
    Local $Ret = DllCall("user32.dll", "uint", "CallWindowProc", "ptr", DllStructGetPtr($ZlibOpCodeBuffer), _
                                 "ptr:cdecl","gzopen", _
                                                                 "str", DllStructGetPtr($Path),...

Thanks in advance

Regards

Tip

Opcode execution requires context. Sometimes the context is provided by the opcode itself (as demonstrated here). In other cases context is made by the PE file that opcode resides in.

For example, calling gzopen in your case means nothing. CallWindowProc function wouldn't know (nor knows) what gzopen means or what to do with it.

CallWindowProc will run/execute pointer, to put it plainly. Provide it with it and voila.

And remember, pointer needs its own context too.

As for calling functions from PE memory image, look for Ward's threads. Or even better, mine.

Edited May 19, 2011 by trancexx

[Ward]

Opcode execution requires context. Sometimes the context is provided by the opcode itself (as demonstrated here). In other cases context is made by the PE file that opcode resides in.

For example, calling gzopen in your case means nothing. CallWindowProc function wouldn't know (nor knows) what gzopen means or what to do with it.

CallWindowProc will run/execute pointer, to put it plainly. Provide it with it and voila.

And remember, pointer needs its own context too.

As for calling functions from PE memory image, look for Ward's threads. Or even better, mine.

Yes~ you are right! Your code is better!

Your method that load a stub (like cmd.exe) by DllOpen and then overwrite it is really genius.

But how to load different DLL at the same time and not use different exe?

I want to find out a way but I fail.

So my new MemoryDll UDF still use MemroyCall, but it is slower than DllCall by your method.

BTW, I am working on machine code version of deflate/inflate and gzip. Don't so impatient, tip.

[tip]

BTW, I am working on machine code version of deflate/inflate and gzip. Don't so impatient, tip.

I'm currently using gzip func you provided with your MemoryDll udf. And I must say they are working great. Thanks for that

I just thought if I figure out a way to use zlib dll with "CallWindowProc" method it'd help to take a bit of the workload from you ...

As for calling functions from PE memory image, look for Ward's threads. Or even better, mine.

I've just read your "Run binary" thread. Wow! Your coding skills... Wow!

But I think it is intended to use only with exe files, am I right?

And thanks for clearing it up about "CallWindowProc"

Edited June 10, 2011 by tip