Vector35 / Vector35/binaryninja-api
Stack structure detection without leveraging type information
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 1.3k
- Forks
- 298
- Avg merge
- 5d 5h
- Merged PRs (30d)
- 19
Description
Consider the following C code:
#include <stdio.h>
struct foobar
{
int a;
int b;
int c;
};
int func(struct foobar* f)
{
return f->a + f->b + f->c;
}
int main()
{
struct foobar f;
f.a = 123;
f.b = 456;
f.c = 789;
int result = func(&f);
printf("result: %d\n", result);
}
The default decompilation looks like this:
Since the analysis does not see the var_1c, var_18, and var_14 all belong to a structure, it marks the latter two as dead store. While the result is reasonable, it would be great if we can actually detect the case and create the stack structure.
Note this is different from https://github.com/Vector35/binaryninja-api/issues/773, when we already know the type of the _func function -- that is just a type propagation. This issue suggests the capacity to detect the structure even if the function type is not set
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the supplied C example and inspect where var_1c, var_18, and var_14 are treated as separate stack variables. Compare the behavior with issue #773, which covers propagation when the function type is already known. Done means the decompiler can recognize the shared stack structure without a preset function type.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, cpp
- Domain
- compilers, reverse-engineering
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100