AutoHotkey Community

MemCpy is straightforward in C: copy n bytes (parameter #3) from source (parameter #2) to destination (parameter #1).

In MemCmp we have a number of choices about the parameters. The version below compares up to n (parameter #3) bytes of buffer1 (parameter #1) and buffer2 (parameter #2). The result is the difference of the first unequal bytes (negative if buffer1 < buffer2, positive if buffer1 > buffer2) or 0 if they are the same. Parameter #4 tells at which offset the byte difference was taken and returned.

Test them with

I had missed that.

Thank you very much for the binary functions.

I'm late (been busy elsewhere late days), but it's here.

@Laszlo

Sir, I compiled the following source code given by you with VC++ 6.0 :



This what I get from disasm.exe: http://arian.suresh.googlepages.com/main.txt

Can you please throw some light on how to extract the relevant hex from this dump?
Can this extraction be automated with an ahk parser ?

Please help.

I don't have VC++6, but I guess you did not export your function. Add to the linker command line options: /EXPORT:spyn. When you compile the program as a console application, the function name should appear in the assembler listing, so you can search for it.

You can extract the machine code from each non-comment line. It is between the first and second white space (tab). I copy the function code to the clipboard, where a simple AHK script removes the beginning and end of each line. There are, unfortunatelly exceptions. Sometimes a longer block of machine code is spread into 2 lines. I don't have an intelligent enough script, just process the bad code manually.

I had thought that was neccessary only for a DLL.
Now I opted the wizard mode and created a simple Win32 Console application and added scpyn in exports.def



The neccessary part of disasm dump:



Derived hex : 568B7424104E74168B4C240C8B4424088A11881040414E75F7C600005EC3
is different from yours : 558becff4d108b4508740e8b4d0c8a1188104041ff4d1075f5c600005dc3
.. though it seems to work:







Thanks! I have it as follows, now:





I was referring to a different problem. Would a function GoTo to an another offset ? If that is the case, should I jump to the relevant part to extract the hex code ? Does these machine code functions always end with hex C3 ?

Thanks for all the help Sir, but I am terribly confused.

Different compilers create different machine code. You could also experiment with different optimization settings.
If the branch is to another function, you are out of luck. The machine code functions in AHK will have different relative location. Unless you include all the code in one machine code block, these will not work. Also, if library functions are called, they often crash your script.
Not necessarily. The last instruction can be any of the many branch instructions, and the function returns from another place. Also, if the function is not CDECL, the last instruction is usually a return with stack cleanup.

Means ... I did it . Thank you Sir.







You mean .LIB or also .DLL ?



Thanks for the clarifications Sir.. very useful information!

Any library function call is bad. Even if the code is stand alone, and the compiler copies the used functions somewhere into the program, their locations are hard to find, and the machine code needs address patches. This was the reason I could not make floating point machine code functions: the compiler used its internal functions regardless of what I tried.

Oh!



How do I tell it by looking at the dump ?

They are marked with funny looking names.

someone write a script that takes a function in a program or a dll or something and turns it into a hex string for use with the mcode function.
think: you could define any function no matter how complex in one line!

_________________
problems := bugs + errors + glitches
(problems != 0) ? code := debug(code) : celebrate()
--
humor for: 1. Programmers 2. Everyone

lol
i dont think its as easy as that

Skan, reading your posts, I understand (but might be wrong) that you want to made and automatic concersion from C to HEX code. Am I right ?

I think it'll be really difficult if C functions want to talk to each other. So will it be to embed static data. If you disassemble Ascii85_Encoder in ODBG, you'll see there are static tables : they are difficult to embed because the code, to be usable in AHK, must be "self-relative". That means any reference to memory or data must be relative to the starting adress of the function. Usually, branches (like goto) are self-relative, but function calls are absolute (the EXE/DLL loading module in Windows does what is called "code relacation" to correct absolute addresses so they match with the address the data is loaded into memory), as are references to static data.

In assembler, with some little tricks, the code can be made self-relative. In C, you only depend on the compiler, which use no such tricks.

And for compilation of stand-alone functions, I was wondering if using gcc (MingW in our case) to produce object modules and to export the binary code out of object modules would not be easier than producing EXEs and searching hazardously for start and end of function into it. Stand-alone object modules with one function in each would further explicitely permit to identify if code is self-relative or not...

Exactly.. I give the script a starting offset, and it tries to extract dependencies, patch the offsets and put it together to make it one long byte stream.

I see it not possible ..