0

I've been messing around a little with Radare2 trying to master binary exploitation and patching.
I added a couple of assembly instructions to an x86 elf binary in a non-executable section of the file, precisely the section LOAD1 I spotted after listing the available sections of the executable :

 S=
00* 0x08048000 |#################################-----------------------------------------------| 0x0804868c  1.6K mr-x  LOAD0
01  0x08049f0c |---------------------------------------------------------------------------#####| 0x0804a028   280 mrw-  LOAD1
=>  0x080483d0 |--------------------------------------------------------------------------------| 0x080483cf

Then when I tried to execute the binary I got the following error :

Inconsistency detected by ld.so: dl-version.c: 205: _dl_check_map_versions: Assertion `needed != NULL' failed!

I think the instructions types I added are not relevant in this matter as the issue arises with mov instructions as well as with simple jmp.

From what I know, the linking step had been performed at the compilation/linking of the original source code, so how does it come that ld is involved here ?

What exactly causes the linker inconsistency triggering the above error ?

  • use iS and not S or S= to list the sections – Megabeets Jul 7 '18 at 5:31
  • @Megabeets Why does iS list much more sections that S and S= commands do ? – programmersn Jul 9 '18 at 11:08
  • @Megabeets Moreover, r2 doc does not say a word about iS. – programmersn Jul 9 '18 at 11:10
  • S is outdated and eventually will be replaced with iS – Megabeets Jul 9 '18 at 11:52
1

Note that no section information is provided in your question. LOAD0 and LOAD1 refer to loadable segments. Refer to the SysV ABI for more details.

From what I know, the linking step had been performed at the compilation/linking of the original source code, so how does it come that ld is involved here ?

The link editor ld is not involved here; rather, the dynamic linker/loader ld.so is.

What exactly causes the linker inconsistency triggering the above error ?

Run LD_DEBUG=symbols,bindings or LD_DEBUG=all.

See https://stackoverflow.com/questions/22564780/debugging-ld-inconsistency-detected-by-ld-so

  • "Run LD_DEBUG=symbols,bindings or LD_DEBUG=all" How can I perform that while not having access to the source code ? – programmersn Jul 9 '18 at 11:00
  • @programmersn LD_DEBUG is used to examine the behavior or the dynamic linker. Only the executable is needed. See docs.oracle.com/cd/E19683-01/816-1386/chapter3-33/index.html – julian Jul 9 '18 at 12:17
  • Just tried out exporting LD_DEBUG=all as env variable as you advised, but it does not show anything when the faulty program is executed (apart from the inconsistency message already mentioned), although debugging symbols are listed when running any other program. – programmersn Jul 10 '18 at 11:33

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.