Symbol addresses off by constant offset

[Talndir]

Using Ubuntu 22.04 on WSL2 (Windows 11).

Every symbol from the PLT is off by exactly 0x1e0. For example, in the symbol table it shows that puts@plt is at 0x.....3070, but the code actually calls 0x......3250. Because of this, library functions are shown as an address rather than as a name, making it difficult to see what is going on. Local jumps are still correct and show the correct name, but library symbols are off, and all addresses seem to be off by the same amount.

I know the addresses are incorrect because GDB shows the correct function names. See screenshots below:

(I apologise for the terrible colour scheme.)

[eteran]

Interesting, we'll have to look into it. Is it with every program, or just this one? Is there an ideal way to reproduce the issue (I often use WSL2 so I can look into it using that)

[Talndir]

It's happening with everything. Here's one I just coded up, this time the offset is 0x20:

#include <stdio.h>

int main()
{
    puts("Hello, world!");
    return 0;
}

To reproduce:

1. Take the above C file and compile with gcc -g -o main main.c (gcc 11.4.0).
2. Install MobaXTerm on Windows, and in WSL set your DISPLAY environment variable to <machine hostname>:0.0.
3. Open MobaXTerm. Open main with edb (current HEAD and latest release both have the problem). Allow edb to connect to XTerm to see the GUI.
4. Open with gdb and run layout asm to see the disassembly.

[eteran]

Great, I'll take a look in the next couple of days (I'm not at my usual work laptop until like Tuesday)

[eteran]

OK, I have reproduced the issue locally and am looking into it!

[eteran]

Interesting, I have boiled it down to the PLT having a slightly different layout when the application is built -fcf-protection enabled.

Setting -fcf-protection=none when building the app "fixes" the issue. But... obviously we'd like to have edb support both cases.

[eteran]

@Talndir I possibly have a fix commited.

Important note: edb caches the symbols it generates and only recalculates them if the binary looks different. Since we've only changed how symbols are computed, and not the binaries themselves... we'll need to invalidate the cache. So you will need to run:

rm -rf ~/.cache/codef00.com/edb/symbols/

to delete existing cache entries for the new code to take effect. Please let me know if this solves the problem for you.

[Talndir]

I can confirm the fix worked! I had indeed observed that the PLT looked weird, almost duplicated, and had these endbr instructions everywhere, but hadn't realised it was specifically because of the branch protection!