szApi  db "MessageBox", 0

push MB_OK
push 0
push 0
push 0

I want call Messagebox with szApi, how ?
thx :)
Posted on 2006-07-31 17:37:11 by kaos
Most of the Win32 parameters use the STDCALL method, so anything that you find in the MSDN database for functions... just push those arugments in reverse order and call the function. For "MessageBox", you still need a caption. Here is a generic fix-up of your code in MASM syntax...

szApi  db "MessageBox", 0
szCap  db "Caption",0

;equivalent of "invoke MessageBox, 0, addr szApi, addr szCap, MB_OK"...
push MB_OK
push addr szCap
push addr szApi
push 0
call MessageBox
Posted on 2006-07-31 18:19:40 by SpooK
No.. lol thx
An another sample...

szApi  db ", ,d", 0 ;->>> Messagebox Crypted
szCap  db "Caption",0

Decrypt szApi -> szApi db "MessageBox", 0

push MB_OK
push offset szCap
push offset szApi
push 0
call ;I want call MessageBox in szApi, how ??

Posted on 2006-07-31 18:39:49 by kaos
For what reason would you want to embed a function call within an encrypted string?
Posted on 2006-07-31 19:59:48 by SpooK
For crypt api name. In Hex-Editor for example... no ?
Posted on 2006-07-31 20:06:50 by kaos

For crypt api name. In Hex-Editor for example... no ?

For what purpose would you want to hide the API call name from someone?
Posted on 2006-07-31 20:32:44 by SpooK
Would you mind giving more specific information about what you want to do ?
Posted on 2006-08-01 01:35:32 by Dite
I can't see much damage being done here.. I'll bite.

Since your function name has been 'mangled', you'll need to add code which does the following things:
-'unmangle' the function name
-use an api function called LoadLibrary to load the dll that contains your desired function, in your case, MessageBoxA lives inside User32.dll
-use an api function called GetProcAddress to obtain the actual address of the MessageBoxA function within the User32.dll
-push your params for the MessageBox
-call the address you obtained for MessageBox

The result of doing things this way is that there is no mention of the MessageBox function in your exe's "import table", however don't think for one moment that this kind of code represents any sort of 'security', this is what we call 'obfuscation' - you can hide an elephant in long grass, but everyone still knows its in there... in fact, the method I've given you leaves a big fat 'clue' because now LoadLibrary and GetProcAddress are in the import table instead. These two functions together basically scream "hidden functions ahead" like a neon sign.

Your question is not particularly problematic (this time), but as Moderators its our job to question your motives.
In future, please try to explain what you want to achieve more clearly..
If you think that doing so would jeopardize your chances of receiving a useful answer to your question, then you are in the wrong place to be asking that kind of question.
This forum has strict rules regarding the kind of topics which can be discussed - we're not TOTAL FASCISTS, but we WILL enforce the rules.
Posted on 2006-08-01 11:12:14 by Homer
Is there any benefits to loading the library besides 'obfuscation'?  Exe size?
Posted on 2006-08-01 11:35:18 by klassasin
Not really.. sure, you're saving a few bytes in the Import Table, but since the filesections of an exe file are aligned to a standard alignment (typically 512 bytes), you save absolutely nothing... you just have a few more zeroes in the import table... bit of a timewaster really, but its the easiest way to access arbitrary functions of arbitrary DLLs (for example functions in dlls coded by someone else) so its worth knowing about.

Posted on 2006-08-01 12:09:09 by Homer
The only way to really save space would be using something like CRC32 hashes of import names instead of textual ones... but then you have the overhead of you own GetProcAddress + the hashing algorithm - you need "some number of imports" before it gives any size savings. And most of the time, it'll be slower than calling GPA.
Posted on 2006-08-01 12:14:45 by f0dder
Interestings... Thanks for that tidbit!  :D
Posted on 2006-08-01 12:27:35 by klassasin
Well, you could save space (512 bytes) if you created the executable without an import section, as done in K32BINC, but like f0dder said before, it won't run on Win2K since it requires an import section (unlike 9x/ME/XP).
Posted on 2006-08-01 17:53:25 by Synfire