How to get Arguments of Exported DLL function

[Tarun Lalwani]

I am trying to call a exported function from a DLL in VB6. I dont know the arguments needed for the call. It is used to decrypt a string from encryted form to normal. The function uses __stdCall calling conventions.

Here is what start of exported function looks like

Code Select Expand


.text:6415200F XXXFunc proc near
.text:6415200F
.text:6415200F cchWideChar     = dword ptr -8
.text:6415200F var_4           = dword ptr -4
.text:6415200F lpWideCharStr   = dword ptr  8
.text:6415200F
.text:6415200F                 push    ebp
.text:64152010                 mov     ebp, esp
.text:64152012                 push    ecx
.text:64152013                 push    ecx
.text:64152014                 push    ebx
.text:64152015                 xor     ebx, ebx


and Here is return code

Code Select Expand


.text:641520EC                 pop     edi
.text:641520ED                 pop     esi
.text:641520EE                 pop     ebx
.text:641520EF                 leave
.text:641520F0                 retn    4


I dont have much/any knowledge about assembly language to understand the arguments from the stack. Can some one guide me on this?

[l)ragon]

What does the function do, if you know that you might get an idea of the variables passed to it.

[Tarun Lalwani]

Well it encrypts/decrypts strings

there are 2 function in the DLL one for encryot and one for decrypt. I am more intersted in using the decrypt.

[l)ragon]

This is what it looks like to me however i could be wrong (probably).
(string, long, string) as long

if this is the case i would asume one is INPUT, INPUT.Length, and OUTPUT.



Interesting, thx warz ;p

[warz]

When looking at the disasm of a certain function, it's always good to take a look at both the function itself, and a call to the function. Just by looking at the function disasm you posted there, you can see that there's one argument being passed to the function by way of the stack. The argument is a pointer to a character array, or, the address of the first character in the array. The character array is most likely assumed to be null terminated since there's no apparent length argument being passed with it. The reason I say you might want to look at a call to the function, though, is to determine how the output is received. For example, take a look at the beginning of CheckRevision...

Code Select Expand


public CheckRevision
CheckRevision proc near

var_114= dword ptr -114h
var_110= dword ptr -110h
var_10C= dword ptr -10Ch
var_108= dword ptr -108h
var_28= dword ptr -28h
var_18= dword ptr -18h
var_14= dword ptr -14h
var_4= dword ptr -4
arg_C= dword ptr  14h
arg_10= dword ptr  18h
arg_14= dword ptr  1Ch
arg_18= dword ptr  20h

push    ebp
mov     ebp, esp
sub     esp, 114h
mov     eax, dword_404014
xor     eax, ebp
mov     [ebp+var_4], eax
mov     eax, [ebp+arg_14]
push    esi
mov     esi, [ebp+arg_C]
mov     [ebp+var_114], eax
...


... we can see that it's expecting four arguments off of the stack. From prior knowledge, though, we know that CheckRevision does not only require four arguments, but actually requires six. This is because the output is written to the addresses specified in the fifth, and sixth arguments of the function. The function itself knows this, and expects to be able to write to those locations specified on the stack. Since you said this function returns a string, it's probable that this may occur, also, so be weary when looking only at function disasm, and not a call to the function.

Edit: I guess I should also mention that when looking at functions in a disassembler, or debugger, the arguments grabbed off of the stack will be the pointers with a negative value, and the pointers with a positive value are function local variables. Also, in the code you pasted, the end of the function is not enough actual code to determine what is returned. The stdcall calling convention cleans the stack up inside the function, as opposed to leaving the task of cleaning up the stack to the caller. So, what you're seeing there is the stack ptr being reset, and the registers being returned to their values prior to the call. The retn 4 is telling where to return to on the stack. What does this signify to us? This tells us that there is, in fact, two arguments supplied to this function. One is apparent in the disassembler, as we can see, and the second is not. So, this function probably looks something like this...

Code Select Expand


int myfunc(char *intput, char *output);


[Tarun Lalwani]

Thank for the input. I was able to decode the parameter yesterday only. I looked at one of the calls and as per that there was only one PUSH so i knew that it takes only one parameter. The problem was that the function protoype was something like this

char * Func(char *)

now i was using VB and just because of it own interference in the way it calls APIs i was not able to make the function call successful. So i had to declare both the input and return value as long instead of strings and then pass the pointer to a string. I had to play around with that a bit and crashed my VB session many times. But in the end i was able to make it work. The funny part was that it takes the input as a normal string and returns a unicode string while i was doing vice versa from last so many days and that was the reason i was thinking that it might have some more parameter or the input might be a structure. Thats why i though it would be better to take help from experts.

Thanks everyone.