Stack View and Call Stack

[pgiblock]

Is it known that the Stack View seems... incorrect? Or at least the values seem misleading. Also, Call Stack seems to be unimplemented.

Are they expected to work? Or is this unfinished business? If the later, I'm willing to help try to improve this aspect of the plugin.

[pgiblock]

And by broken Stack View, I mean that I can do "Jump to EBP", then step through code that assigns to variables in the stack frame, but I don't see the data in the Stack View change. Similarly, I don't see (at least I don't interpret) the return address or saved BP in this view.

By the way, thanks for entertaining me. I know this project has been in hibernation.

[wjp]

Are you debugging a 16 bit program? IDA is not always consistent in its handling of segment registers (it has improved a lot since IDA 5.0 though), and from a quick glance at this, at least the "Jump to EBP" ignores SS.

I do see it properly follow ESP or EBP if I tell it to synchronize with EBP/ESP, but not immediately. (The actual following seems to work, but not the initialization.) I can also see the effect of call and push bp opcodes on the stack.

I've never tried IDA's stack trace functionality, but from a quick test, it seems to fail completely on 16 bit programs.

[wjp]

P.S. It might be worth it to contact hex-rays support or their forum for instances where segment registers are ignored. They're very helpful in my experience.

[pgiblock]

Yes, this is a 16bit program. In this case, I cannot even view the memory at SS:SP; not in the stack view or the hex view. I don't mind deciphering the stack myself, but I'd like to at least be able to see it ;-)

[wjp]

That's odd. Viewing the memory there seems fine for me. The address may be displayed in a different form, by the way. In a test I'm running now, SS:ESP is 1D5A:FB08, but the memory/stack views show 20E:2AFC8 (which is the same actual address, but relative to a different segment).

But it could be that the memory segmentation set up by idados isn't right for your binary. Does SS lie within the memory space that IDA knows about? (See the Segment window.)

[pgiblock]

I'll get back to this later tonight. In my case, the region of memory was totally missing (not an overlapping segment issue). SS was set to something in the 0x2000 range, but "sync with SP" in the Stack View would teleport me to something in the 0x0000 range. I'll see if I can make any sense of it. I wonder if I need to manually create the segment in IDA since it is missing from the executable image itself?

In case you are interested in recreating, this is the software I'm working on reversing: http://www.whicken.com/scorch/scorch15.zip (homepage: http://www.whicken.com/scorch/)

[wjp]

For me the "sync with ESP" also is broken at first, but after stepping, it fixes itself.

[pgiblock]

I'll try again with a new database. For consistency sake, what processor and mode did you choose?

[pgiblock]

Ok, sure enough, the stack view is working properly. The big thing that seems to be a hurdle for me at this point is that the stack is viewed as 32bit words, which can make it a bit hard to follow. In particular, what stinks is this prevents IDA from annotating any of the addresses with names. I'll look into the SDK and see if there is a way to influence the view. Although, I don't feel to optimistic about it.

The call stack might be easier for me to implement, but again, I need to look at the API. This might just be a matter of generating an event whenever a call or ret instruction is executed.

[wjp]

On Tue, Jan 12, 2016 at 06:53:41AM -0800, Paul Giblock wrote:

Ok, sure enough, the stack view is working properly. The big thing that seems to be a hurdle for me at this point is that the stack is viewed as 32bit words, which can make it a bit hard to follow. In particular, what stinks is this prevents IDA from annotating any of the addresses with names. I'll look into the SDK and see if there is a way to influence the view. Although, I don't feel to optimistic about it.

You can press '2' to turn it into 16 bit words. I don't know if that enables annotation though.

[pgiblock]

Regarding Stack View, it seems the feature works properly. The fact that the view assumes 32bit (and that pressing '2' for 16 bit results in a naked hex view) seem to be IDA problems, so those are out of scope for idados.

Regarding Call Stack, I created a workaround that fulfills my needs. Perhaps this can be integrated into idados once I get a chance to test it more. Some refactoring is necessary to make it proper. A quick overview of the solution in case you are interested:

• Hacked the CPU code of DOSBox to hook into the handling of CALL and RET instructions.
  • DOSBox now creates a POSIX SHM for storing the callstack
  • CALL instructions append a record to the SHM containing the old and new CS:IP, as well as SS:SP.
  • RET instructions remove the bottom-most record from the SHM
• Wrote an IDAPython script to create a "DOSBox Stack View" pane.
  • The pane parses the SHM, displays the caller CS:IP as well as the function name
  • Double-clicking an item jumps to the CALL instruction in the IDA View.

The result looks like:

Things left to do for "official" integration into idados:

• Test on 32bit executables
• Consider long jumps and interrupts
• See if the SHM can be replaced with IDA RPC
• Port the IDAPython stuff to C for the plugin (even better would be to populate IDA's real "Call Stack View".

However, I'm too lazy to learn enough IDA API to do the latter two steps.

[wjp]

Wow, very nice.