Decompiling 2024: A Year of Resurgance in Decompilation Research

Re:Decompiling 2024: A Year of Resurgance in Decompilation R... by skissane on Thursday January 30, 2025 @10:53PM (#42884565)

I think Ghidra could do better even without any LLM involved. Ghidra will define local variables like this:

SERVICE_TABLE_ENTRY* local_5c;

I wish it at least did something like:

SERVICE_TABLE_ENTRY* local_5c_pServiceTableEntry;

Oh yeah, there’s probably some plugin or Python script to do this. But I just dabble with Ghidra in my spare time

It would be great if it tracked the origin of a variable/parameter name, and could show them in a different colour (or some other visual distinction) based on their origin. That way you could easily distinguish “name manually assigned by analyst” (probably correct) vs “name picked by some LLM” (much more tentative, could easily be a hallucination)

[ Parent | on HN ]

Re:Decompiling 2024: A Year of Resurgance in Decompilation R... by rgovostes on Friday January 31, 2025 @05:20PM (#42892952)

In my view one of the most pressing shortcomings of Ghidra is that it can't understand the lifetimes of multiple variables with overlapping stack addresses: https://github.com/NationalSecurityAgency/ghidra/issues/975

Ghidra does have an extensive scripting API, and I've used LLMs to help me write scripts to do bulk changes like you've described. But you would have to think about how you would ensure the name suffix is synchronized as you retype variables during your analysis.

[ Parent | on HN ]

Re:Decompiling 2024: A Year of Resurgance in Decompilation R... by skissane on Friday January 31, 2025 @09:35PM (#42895099)

Yeah, I don't know why they don't use something like SSA – make every line of code which performs an assignment create a new local variable.

Although I suppose when decompiling to C, you need to translate it out of SSA form when you encounter loops or backwards control flow.

[ Parent | on HN ]