Grouping functions based on their placement/order in the binary

Question

Can I group functions based on their place in the binary? Can I assume functions next to each othe belong to the same logical group, or at least they have similar functionality? I suspect that the ordering/layout of the functions are decided compile time, however I still don't know what exactly controls this.

Anyway, here is an example for better understanding my question. Let's say I have 3 functions that IDA named for me :

sub_00543210
sub_00543211
sub_00543212

Later during the analysis I find out the name of two functions.

foo_bar1
sub_00543211
foo_bar3

At this point I would say that the name of the 2nd function, surrounded by found function names is definitely has something to do with "foo" so I'll name it "foo_bar2". (Which later it turned out to be true.)

Is this a valid assumption, or was this a special occasion?

Answer 1

Often times you will see patterns like this in a binary. It's certainly not guaranteed by any means, but you will typically see like functions placed near each other.

What do I mean by that? Well consider how a typical C program might be laid out:

foo.c
    static foo_1()
    static foo_2()
    use_foo()

bar.c
    static bar_1()
    static bar_2()
    use_bar()

main.c
    usage()
    process_args()
    main()

People typically compile each C file by itself (into a .o) and then those object files are linked together to form the final binary. Most of the time, the linker will not reorder the functions. So this is why you can expect to see similar or related functions right around each other.

Additionally, this holds true for libraries that the binary is statically linked against. If an IDA FLIRT signature matches, you'll often see those standard library functions right next to each other as well.

This fact really helps when you find a standard compression/encryption/xml/whatever function, because most of the time, you can pull the source code and quickly start identifying the rest of the library calls (or at least know what functions you can ignore).

Answer 2

Normally the linker will leave the functions in their original order.

However, techniques like Working-Set Tuning (see also Profile-Guided Optimization) can profile the program to see which parts are called the most often, then re-link it with that information in mind. This will clump the most frequently used code together (not only reordering functions, but also possibly splitting them into separate chunks) for memory paging purposes, and of course throw the original function ordering out the window.