[Bug] Prevent collisions in generated identifiers and runtime symbols

Open
  • Is something wrong?
#8 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
42/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c, cpp
Domain
reverse-engineering

Research direction

Start with the data-symbol collection in src/main.cpp (around lines 162-170), then the name sanitizing in src/decompiler/decompiler.cpp (75-91) and src/decompiler/project.cpp (53-66), and the declaration emission at project.cpp (282-299). The goal is a deterministic unique-name mapping that avoids C keywords and libc names, with every reference following that mapping. Done means a binary using stdout compiles and colliding names like foo-bar and foo_bar get distinct stable identifiers; the payload names no test, so one must be found or added.

Written by the indexing model from the issue text.

Description

bug

Summary

Generated identifiers are sanitized locally but are not made unique or reserved-name safe. The CLI also feeds runtime and libc symbols into the recovered data declarations, which can conflict with headers included by the generated file.

Evidence

src/main.cpp:162-170 collects nearly every non-function ELF symbol as a data name. src/decompiler/decompiler.cpp:75-91 and src/decompiler/project.cpp:53-66 replace invalid characters and prefix digits, but do not detect collisions, C keywords, or names already declared by included headers. Declarations are emitted at src/decompiler/project.cpp:282-299.

For a binary using stdio, the generated project can contain:

#include <stdio.h>
static uintptr_t stdout = 0;

which conflicts with libc's FILE *stdout declaration. Similar conflicts occur when an unrecognized imported function receives a fallback with the same name as a libc declaration, and two symbols such as foo-bar and foo_bar both sanitize to foo_bar.

Impact

Otherwise usable recovered output fails at compile time or silently binds references to the wrong declaration. Runtime/linker symbols and user symbols are common in ELF files, so this is not limited to intentionally adversarial input.

Expected behavior

Generated identifiers should use a dedicated namespace/prefix, be deterministic and unique after sanitization, avoid C keywords and reserved/runtime names, and distinguish external declarations from recovered storage. Standard-library symbols should not be redeclared with incompatible types.

Acceptance criteria

  • A binary containing stdout or another libc runtime symbol produces compilable output.
  • Sanitization collisions receive stable unique names and all references follow the mapping.
  • C keywords and reserved identifiers cannot become generated declarations.
  • Unknown-import fallbacks cannot conflict with declarations from emitted standard headers.
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.