3

may anyone explain to me why most of the debuggers don't auto recognize functions?

This is a feature I only found in IDA and ollydbg, any other debugger I tried just don't analyze the functions as IDA and olly do.

I understand that this could be a performance issue to justify don't set this feature as the default behaviour, but why debuggers like x64dbg seems to just don't have the feature?

Thanks.

  • The easier answer is "Because debuggers are not aware there is such thinh as a function at all", as they only execute one instruction at a time. Even if a list of instructions-to-be-executed is displayed, there is no guarantee at all that that is going to happen in that order and with those instructions. – usr2564301 Dec 8 '17 at 11:06
4

As assembly instruction sets are reasonably complex, properly figuring out a function boundaries inside a big executable binaries is a somewhat difficult task. Even IDA, which specializes in that, has quite a few mistakes and misses in certain scenarios.

This goes back to disassembly strategies, which are basically the algorithm used to provide disassembly listings for given stream of binary. They're often divided to two categories:

  1. Linear Sweep is to simply disassembly one instruction after the other. The straight-forward way to disassemble a sequence of instructions - start the next instruction disassemble right where the last instruction ended.
  2. Recursive Disassembly attempts to consider the code flow while disassembling, and will likely hold a stack of "function entries" (every call, for example, will get it's target address in that queue). The queue keeps being emptied by the disassembly engine until all encountered functions are analyzed.

They both have their pros and cons although Linear sweep is considered simpler to implement and recursive disassembly to yield better results.

Most debuggers don't focus too much on the disassembly task because usually, instruction pointer registers will point to the correct function to disassemble and the need to disassemble big binary blobs and recognise functions is rare. Additionally, as mostly static analysis tool IDA puts a lot more focus into exposure of the "whole picture", where debuggers tend to shine a light on only a small piece of the executable at a time.

P.S.

x64dbg is another debugger (considered an ollydbg replacement by some) with decent function discovery.

  • Hum I see, so you think the main reason is because function analyze is a complex thing to do? Why do you think olleh did it so well years ago and people can't replicate that nowadays? – underthevoid Dec 7 '17 at 22:05
  • 1
    When I was using x64dbg i found it's analysis capabilities satisfying. If you did not - there isn't anything that could easily improve them. Sorry. – NirIzr Dec 8 '17 at 0:34
  • 1
    Thank you :) please let me know if there's anything else I can do to shed more light onto the topic. – NirIzr Dec 8 '17 at 1:46
  • 1
    @underthevoid Preferences such as speed or workflow. For me I was debugging a 50MB binary whose idb was generated of ~600 MB. As soon I started to debug, IDA will rebase the whole binary which would take a lot of time for me. – sudhackar Dec 9 '17 at 7:20
  • 1
    @underthevoid IDA's debugger is quite poor. This is even Ilfak's take on it, as it was mostly done "to satisfy demand" and against Ilfak's will. Disassemblers and debuggers are too completely different tools and may be used to slightly different tasks, although there is quite a bit of personal preference to it. – NirIzr Dec 10 '17 at 6:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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