3

I have a problem just like in the question. Modern compilers don't use ebp to handle local variables and arguments, they just calculate and add hard=coded offsets to esp. Example:

sub     esp, 5Eh  
...     
mov     [esp+5Eh+var_1], 123h
mov     [esp+5Eh+var_2], 456h
call    some_func            ; var_1 and var_2 point to actual addresses
cmp     eax, 0               ; esp changed (stdcall), var_1 and var_2 point to wrong addresses

...

;  creation of a "fake" variable example:
;  var_3 = -8h
;  var_4 = -12h 
mov     [esp+5Eh+var_3], 78h  ; var_3 at: esp + 5Eh -8h
pop     eax                   ; esp = esp + 4  
mov     [esp+5Eh+var_4], 89h  ; var_4 at: esp + 4  + 5eh -12h = esp + 5Eh -8h = var_3
; desireable fix:
mov     [esp+62h+var_3], 89h 

This results in a lot of overhead: IDA creates "fake" local variables (i.e. several names for one and the same address), you can't freely check variables whenever you want to, you have to create additional comments, etc. So I was wondering is there any way to fix that ?

PS. I'm using IDA Pro Free. Tell me if it is possible only in IDA Pro (full version).

2 Answers 2

3

The variable names that IDA is generating aren't "fake"; they are exactly the same as they would be labeled had the function been ebp-based. The problem you describe is only really an issue when debugging since that's the only time you can inspect the values pointed to. I'm not aware of any built-in way to get IDA to display what you want. When you hover over an operand, IDA just takes the current value of the register and adds the offset. If esp has changed, then it will show you the wrong address, which is what you're seeing in your example.

Since IDA does know the correct stack offset, one way to do what you're asking is to write an IDC script that checks eip and adjusts for the difference in esp values before calculating the final target address. The IDC function that gets the stack offset at a given address is GetSpd(). The algorithm would go something like this:

  1. Calculate the target address of the operand you are interested in (i.e. esp+5Eh+var_1 -> 0x10000000)
  2. Get the stack pointer delta (SPD) of the line containing the operand you're interested in (i.e. 5Eh)
  3. Get the SPD of eip (i.e. 6Eh)
  4. Calculate the difference of the two SPDs and add (or subtract) that amount from the target address you calculated in step 1 (i.e. 0x10000000 + (6Eh-5Eh) = 0x10000010)
  5. Go to your calculated address ([0x10000010] contains the variable you are after)
3
  • Thank you very much for your answer, now I know that there are no facilities for that issue in IDA Pro so I should write my own script. Ad. ("fake") variables - I updated my post so it's more clear what I mean. Ad. your algo - it's not that trivial because i.e. GetSpd() ignores esp changes done by stdcall functions. I think the approach I will take is to write a script that will run a function while keeping track of all variable addresses and do some access presentation adjustments (fix shown in post) and eventually write addresses in comments. Commented May 3, 2014 at 22:37
  • 1
    Hi, looking at your update, what you've labelled as the desirable fix is exactly what my version of IDA does. I'm wondering if this is a free vs. paid difference. I use IDA 6.2. You're right, the script would be more complicated than I made it sound. :-) I've found that the stack pointer delta is usually pretty accurate, but that might also have been improved in more recent versions.
    – bad_decoy
    Commented May 3, 2014 at 22:53
  • Ah, sorry I didn't post it when creating the topic. I think it's not a free vs paid difference, just the free version is 5.0 and hex-rays did a lot of improvements since that time I guess. Thank you again, a script that would run the function should be useful but I'll probably have to risk my future and buy the newest version of IDA one day anyway. Commented May 4, 2014 at 8:24
2

With your cursor inside of the given function, press Alt+P to edit the function properties. In the Edit function window, uncheck BP based frame and press OK.

2
  • Thank you for an answer, but it's never been checked. Commented Apr 30, 2014 at 13:57
  • This should be the correct answer. Commented Dec 14, 2017 at 23:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.