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.

Improve this question
1
  • 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.
    – Jongware
    Dec 8, 2017 at 11:06

1 Answer 1

Reset to default
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.

Improve this answer
10
  • 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, 2017 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, 2017 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, 2017 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, 2017 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, 2017 at 6:12

Your Answer

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

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