Log in

View Full Version : Generic IDAPro/ASM questions...


midnitrcr
March 4th, 2005, 15:49
In IDA I have seen the parameter listing inside functions contain any of the following...

arg_0
arg_C
var_1
var_2
var_3

I'm assuming there is some sort of logic to the naming convention, but I haven't figured it out.

Also, what register do *return* values for functions get placed in? For instance a program that looks like the following...

push [ebp+var_1]
push [ebp+var_2]
call function_12345

...where the function would take those two parameters, manipulate them and return execution to the calling segment.

Polaris
March 4th, 2005, 16:30
Quote:
[Originally Posted by midnitrcr]In IDA I have seen the parameter listing inside functions contain any of the following...

arg_0
arg_C
var_1
var_2
var_3

I'm assuming there is some sort of logic to the naming convention, but I haven't figured it out.


It is quite simple, indeed... The "arg_" prefix is used for passed arguments (positive offsets), while the "var_" prefix is used for locals vars (negative offsets). Then the offset address is used to complete the name.

Quote:
[Originally Posted by midnitrcr]Also, what register do *return* values for functions get placed in? For instance a program that looks like the following...

push [ebp+var_1]
push [ebp+var_2]
call function_12345

...where the function would take those two parameters, manipulate them and return execution to the calling segment.


This heavily depends on compiler specifications; usually using the accumulator register (EAX).

HTH,

Polaris

evaluator
March 4th, 2005, 17:04
arg_C probably = argument at [ebp+0Ch]..

retern can be anywhere where code will want.. go there & look

TBone
March 4th, 2005, 18:58
There are various calling conventions that define how return values are handled, but as has been pointed out, a function can return a value any way it wants to. It can even not return at all, or return to somewhere other than where it came from, as I'm sure you'll discover if/when you play around with packers/crypters. But, probably 99% of the time, something will be returned in EAX, even if it's just a status code that indicates success or a failure code. The only way to know for sure is to look at the function and see what registers are referenced and modified by the code. It could also return values by modifying data in memory. Look for any memory addresses that are pushed as arguments to the function. Variables and structures in memory that are passed by address could have their contents modified. A function could also modify the contents of a global variable without having the address passed to it.

On a related note, you can rename the variables and arguments in IDA, although I don't know if you can change the default naming convention. So if you've figured out that var_4 is the serial number, you can call it that. If you look at the top of a subroutine, IDA provides a variable legend for you. Something like:
Code:

.text:00401320 LocalFileTime = _FILETIME ptr -0C4h
.text:00401320 Time = SYSTEMTIME ptr -0BCh
.text:00401320 lParam = dword ptr -0A8h
.text:00401320 var_A4 = dword ptr -0A4h
.text:00401320 var_A0 = dword ptr -0A0h
...
.text:00401320 hWnd = dword ptr 4
.text:00401320 FileTime = FILETIME ptr 8
.text:00401320 arg_C = dword ptr 10h
.text:00401320 arg_10 = dword ptr 14h
...

As you can see, the arg_X names seem to be off by 4, for some reason, and it automatically assigns descriptive names (and types) when an argument or variable is only used as an argument to some API call that IDA recognizes.

tom324
March 5th, 2005, 03:31
About calling conventions:

http://www.codeproject.com/cpp/calling_conventions_demystified.asp

Tom

midnitrcr
March 11th, 2005, 09:57
Thanks for the input guys... Nice to find a place that people actually understand what the hell it is I'm talking about and can give some solid answers.

ColdWinterWind
March 15th, 2005, 14:28
It's always good to not have to dumb-yourself-down, or spend so much time Explaining-to-Lucy that you forget your original thought!

Now if I could just find a decompiler so I'll know what my teenaged kids are talking about!