mari-mari
mari-mari
### Proposal Refactor `constants.py` and `globals.py` after #107 is done, since the changes may render some parts of code unused. I suspect that continuous development of Binary Ninja also makes...
### What happened? When decompiling a complete binary from the command line, we output decompiled code for each of the functions in that binary. In case decompilation of even a...
### Proposal Currently, we consider expressions `*(base+offset)` as an array element access `base[offset/type_size]` if the `base` variable has type `Pointer` and `offset` satisfies valid offset requirements. For instance, here: ```c...
### Proposal Currently we represent addresses within the binary as hexadecimal: [extractme.zip](https://github.com/fkie-cad/dewolf/files/7985913/extractme.zip) `main` ``` ... var_3 = i + 0x804c020; ... ``` For instance, Binary Ninja prepends in such cases...
### Proposal Is it possible to make addresses in code clickable, i.e. if we have address in the decompiled code that points to some location within the binary, we could...
### Proposal There are a couple a checks that could be made in order to get type of array if we have `void *` - since we need type of...
### Proposal Currently, we do not propagate (re)definitions of global variables, as there are cases where it could lead to incorrect decompilation. Consider the following example [test_global.zip](https://github.com/fkie-cad/dewolf/files/7978612/test_global.zip): ``` 00004010 uint32_t...
### Proposal Pure free-time refactoring issue, originated from some merge request review. One could make the function that collects candidates prettier. ### Approach Something like this could potentially work: ```...
### Proposal Currently we avoid propagating of address of a variable into its usages. Consider the following example: [whatami.zip](https://github.com/fkie-cad/dewolf/files/7933341/whatami.zip) ```bash $ python decompile.py whatami 0x8048c5c ``` ```c ... var_1 =...