[Bug] Preserve and classify RIP-relative data and code references

Open
  • Is something wrong?
#7 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
cpp, linux
Domain
reverse-engineering

Research direction

Start in src/analysis/analysis.cpp around lines 292-300, where every RIP-relative memory operand is tagged as data, then read src/decompiler/project.cpp lines 174-232 and 282-299 to see how referenced objects are emitted. Add regression coverage for a code pointer to main, an initialized scalar like int g = 42, and a short non-printable object, and check that none becomes a zeroed global or an undefined extern. Done means the three cases classify and render correctly, or emit an explicit unsupported marker.

Written by the indexing model from the issue text.

Description

bug

Summary

RIP-relative references are all classified as data xrefs, and the project renderer only preserves a narrow subset of data as strings. This misclassifies code pointers and loses scalar/raw data contents in the generated source.

Evidence

src/analysis/analysis.cpp:292-300 labels every RIP-relative memory operand as "data" without checking whether the target is executable or a discovered function. src/decompiler/project.cpp:174-232 only extracts printable NUL-terminated strings; other data is emitted as zero-initialized storage or an external byte array at :282-299.

Observed cases:

  1. Normal ELF startup code contains a RIP-relative address of main. The recovered project declares a synthetic object such as global_<main-address> in the .text range instead of representing a code/function-pointer reference.
  2. For int g = 42;, the generated data section contains static uintptr_t g = 0, so the initialized value is lost.
  3. Referenced non-printable data is emitted as extern unsigned char name[] without embedding the bytes, despite the output header describing the file as self-contained.

Impact

Generated code can point at fabricated globals, discard initialized state, fail to link because referenced data is undefined, or behave differently when a code address is passed through a register. These failures are independent of instruction-level expression recovery.

Expected behavior

The analysis should distinguish data, code addresses, and function-pointer references. The project renderer should preserve referenced bytes or typed values when it claims to generate self-contained output; if exact reconstruction is impossible, it should emit an explicit unsupported artifact rather than silently zeroing or inventing storage.

Acceptance criteria

  • RIP-relative targets in executable sections or discovered functions are not emitted as data objects.
  • Initialized scalar and raw referenced data are represented without silently replacing their contents with zero.
  • Generated code does not contain undefined extern data solely because a referenced object was non-printable.
  • Add regression coverage for a code pointer, an initialized scalar, and a short/non-printable object.
Dominant language
C++
Stars
0
Forks
0
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from TiElixir/caraxes

All issues in TiElixir/caraxes

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.