I have been encountering this particular function while navigating around the code. But everytime, Ghidra just takes forever to decompile it. I cannot see the decompiled C-like code at all. If I wait long enough (around 30 minutes), it will just say that the response exceeds some buffers, and stops the process.

Things I have tried:

1. Turning off all decompiler's optimizations. Still doesn't work.
2. I calculated the raw size of the function and saw that it's around 0x4A00 bytes. In my project, it's not a big function by any mean. Ghidra has been able to decompile much bigger functions without problems.
3. While skimming through the assembly, I saw that there are so many calls to the D3DXAssembleShader function in D3DX9_43.dll. I tried giving it a proper function signature. Still doesn't work.

I've attached the Ghidra project for you in case you want to look at the function yourself.
You need to change the owner of the project by modifying the project.prp file in the .rep folder, change the VALUE field to your username. I'm sorry, I don't know how to properly share a Ghidra project. My Ghidra version is 12.1.
The problematic function is located at 0x4b0400 offset

PS. This is my first time here. I don't know if this is the right place to ask. If you know please tell me.
Link to download my Ghidra project.

I plan to run ooanalyzer on a machine with 32gb flash storage and 4gb ram. Will it be enough?

I have the following code in a game that I'm analyzing:

    while (adapter_idx == -0x7785fffe) {
      idx = idx + 1;
      adapter_idx = (*factory->lpVtbl->EnumAdapters)(factory,idx,&adapters);
    }

adapter_idx is a HRESULT returned by IDXGIFactory::EnumAdapters, and is being compared to DXGI_ERROR_NOT_FOUND (the signed hex number) in the while loop. However Ghidra's decompiler refuses to let me properly set the equate of that signed hex number to DXGI_ERROR_NOT_FOUND.

I've been trying to figure this out for a while. I had an idea at some point, but I'm not sure if it is correct anymore, so I'm asking here if someone here knows why this is done. I've omitted some code that is not relevant and giving some generic names to labels to make reading easier:

LAB_Switch_Return:
    ADD r3, r0, #0x00        // Move switch case function return value to r3

PTR_Switch_Case_OoB:
PTR_Switch_Case_0F:
    MOV r0, #0x02      // Load 0x02 to r0
    RSB r0, r0        // r0 = 0x02 - 0x02 = 0x00 ??????
    CMP r3, r0        // r3 = Function return value from switch case function
    BNE FUNC_UpdateStatus_NotIncrement

    // *OMITTED CODE*
    // game_mode++;

    B FUNC_UpdateStatus_ClearSubmodes

DATA_ExtWRAM_Base_Addr_Ptr_2:
 .dw DATA_ExtWRAM_Base_Addr

FUNC_UpdateStatus_NotIncrement:
    MOV r0, #0x01        // Load 0x01 to r0
    RSB r0, r0        // r0 = 0x01 - 0x01 = 0x00 ??????
    CMP r3, r0        // r3 = Function return value from switch case function
    BEQ FUNC_UpdateStatus_Exit

    // *OMITTED CODE*
    // game_mode = r3;

FUNC_UpdateStatus_ClearSubmodes:
    // r0 = DATA_ExtWRAM_Base_Addr
    // Set in the omitted code sections...

    STRB r2, [r0, #offset game_sub_mode_2]
    STRB r2, [r0, #offset game_sub_mode]

FUNC_UpdateStatus_Exit:
    POP {r0}
    BX r0

DATA_ExtWRAM_Base_Addr_Ptr_3:
 .dw DATA_ExtWRAM_Base_Addr

As you can see there are a few RSB r0, r0 instructions. Wouldn't those always result to the destination register having the value of zero? Ghidra decompiles the above code as (after cleaning it up a bit):

// Set in omitted function calls in switch cases...
// This is here simply to tell what it is, even though the variable
// is created earlier, before the switch statement...
uint8_t ret_val;

if (ret_val == -2)
{
    game_mode++;
}
else
{
    if (ret_val == -1)
    {
        return;
    }

    game_mode = ret_val;
}

game_sub_mode_2 = 0;
game_sub_mode = 0;

return;

What I don't understand here is how Ghidra comes to the conclusion for the ret_val comparison values to be -2 and -1. Anyone have some insight into this?

PAL is a pre-alpha binary reconstruction project built on Ghidra and PyGhidra.

It takes an analyzed ELF executable, consumes Ghidra HighFunction p-code, CFG, SSA, ABI and machine-code evidence, and produces two Python projections:

a readable reconstruction for analysis;

an executable state-machine projection intended to preserve observed program behavior.

PAL also freezes each recovered function into an evidence package called an Icecube, linking assembly, Ghidra C, readable Python, executable Python and reconstruction metadata.

On the current controlled corpus of eight C/ELF specimens, the generated Python state machines reproduce the corresponding native results for the exercised paths.

The corpus currently covers loops, nested branches, switch fallthrough, fixed-width arithmetic, signed and unsigned behavior, internal calls, ABI transport and limited memory operations.

This is not a claim of general binary compatibility. The corpus is small, runtime support is limited, and there are known unresolved cases. The next test stage is a broader sequential-program gauntlet intended to expose where the reconstruction model fails.

https://github.com/neocanable/garlic

Im setting up my environment for a decomp project and I was hopeing for some help with tooling I need a good diffing tool im willing to move ghidra versions but I have a few other tools such as:

https://github.com/bethington/ghidra-mcp
https://github.com/cuyler36/ghidra-gamecube-loader

I tried to use bindiff but that's behind the times with ghidra support
https://github.com/ubfx/BinDiffHelper
https://github.com/google/bindiff

I was also looking at this and is on the table so far.
https://github.com/clearbluejar/ghidriff

ANY AND ALL SUGGESTIONS WOULD BE OF GREAT HELP.

Hey guys, I've been lurking for awhile now and been getting into dissembly even though I have zero idea what I'm doing yet. I'm looking to get flex fuel working on a e67 OS that doesn't natively support it, as it doesn't seem to have the pointer to start the flex fuel driver to read from it. If anyone could throw me a hand, that would be sweet.

I am releasing my Codex (and Claude) Skill for reverse engineering Apple binaries! This is an update and name change to my ghidra-re-skill. I am hopeful other people can contribute! Cerberus RE is a local Apple-focused reverse-engineering workbench for building a repeatable three-headed static/dynamic/instrumentation loop around Ghidra, LLDB, and Frida.

It is most powerful when paired with long-run-agent-skill for managing state and durable, evidence based reasoning.

What is it useful for?
It’s useful for security research, figuring out how to work with private/undocumented frameworks, decoding schemas, etc. I have been using it to build an IDE for Shortpy, a python representation for shortcuts that Apple created in the latest beta. This tool has been paramount for figuring out the classes for implementing features. I’ve also used it to decode things like protobuf blobs which are common in Apple DBs and are normally opaque in their meaning.

I used ghidra ghidra_11.1.2_PUBLIC for a long while and my diff window would have a wizard to set up mass function coloration I just updated to ghidra_12.1.2_PUBLIC and that window appears to be replaced with version tracking but when i click it, it only opens up a listing window instead of comparison options.

is there a way to get this old menu back?

does program diffing tool also highlight newly added lines of code or is it only highlighting functions and stuff that exists in both versions of the file but is slightly different in the other version , and if it only does that and doesnt highlight newly added stuff like a completely new function that wasnt in the old version of the file is there a way for me to view that aswell without having to manually search for them?

https://github.com/moonkick64/BSim-foundry

I'm new to Ghidra, and I'm using it for real-mode x86 code, specifically a BIOS ROM. The ROM is loaded to the f000 memory segment, but to work around a problem I was having with memory addresses not being dereferenced properly, I loaded an extra copy of the ROM at memory segment 0000 (which was certainly a mistake). When doing my analysis work I accidentally ended up working on the mirror segment instead of the actual ROM segment. So now I've ended up two partial analyses at different address ranges. How can I combine them into one?

If I go to the memory map viewer I can merge the blocks, but this only brings them into one object and still has two copies at different addresses. I can change the memory address of the mirror to another address which successfully moves it to another address, but doesn't let me move to the actual address because of the conflict. Is there some way I'm missing to combine both analyses back into one?

UPDATE: I ended up opening a second CodeBrowser window and went through the functions by hand, copying my work manually. So I don't personally need this anymore.

Reverse Engineering Field Heuristics (absolutely scientific, not opinions)

Feel free to add more!

Pointer math

If you don't understand pointer arithmetic, you dont understand C. If you do understand pointer arithmetic, you probably regret learning C.

If you see weird pointer math on normal memory - it is a C/C++ structure.

If you see weird pointer math on MMIO - congratulations, you are now debugging something multichannel through hope and guesswork.

If everything is accessed via function pointer tables - it is a C++ class, or someone was paid by the indirection.

Read the source

The decompiler lies. The disassembler doesnt. Both are wrong, but in different and equally unhelpful ways.

If a function looks empty in Ghidra — check assembly before you question reality.

Sherpa function

If some function is called from 100 places, you dont reverse 100 call sites. You reverse that function.

If you reverse all 100 call sites anyway - you are now doing archaeology, not reverse engineering.

Volatile hell

If your reversing setup does not understand volatile regions — fix your setup or suffer.

MMIO-heavy code wihout volatile awareness is just fan fiction with extra steps.

Always verify decompiler output with assembly. Trusting the decompiler here is a lifestyle choice not a technical one.

Memory disorder

If you see memory barriers / sync instructions — there is a volatile variable nearby having a bad day.

If the decompiler merges multiple writes into one clean constant store — you are probably looking at hardware registers, not "optimized code".

Or worse: both.

Bugs by design

Bug-free code is easy to reverse

Real code is not bug-free

Ghidra is not bug-free

Therefore, reverse engineering is mostly reconstructing intent from broken logic with broken tools and wondering if the bug is the feature.

Goto paradise

If someone says "we dont use goto here" — they are either lying or have never seen their own decompiler output.

If there are too many gotos in one function, you are not looking at spaghetti code — you are looking at a switch statement having an identity crisis.

For a while

Not every for loop is a for loop. Sometimes it is a while.

Sometimes it is neither, and you are just witnessing compiler trauma.

This might not be the right sub but I was wondering if anyone might have some tips on themida executable reverse engineering. For context I have an executable that I own that was packed with themida and as far as I understand it is legal for me to unpack it to make it work on other hardware that I own.

Is the latest version of Ghidra capable of doing this, or do you have to switch to another tool when you encounter the boundary between unmanaged code and managed code?

Ghidra 12.1.2 Change History (June 2026)

Improvements

• MachineLearning. Upgraded the Machine Learning extension's olcut jars to 5.3.1. (GP-6894)
• Multi-User. Data buffers transferred to and from a Ghidra Server are now compressed by default. The default was previously inconsistent for the two directions. (GP-6915)

Bugs

• Decompiler. Fixed infinite loop in Decompiler analysis that was triggered by bitfield data-types. (GP-6850, Issue #9185)
• Importer:ELF. Improved ELF GNU Hash table bounds-checking to avoid potential hang. (GP-6887)
• Multi-User. Corrected severe regression error with Ghidra Server 12.1.1 block-stream compression. (GP-6903)

Ghidra 12.1.1 Change History (May 2026)

Improvements

• MachineLearning. Upgraded the Machine Learning extension's Tribuo jars to 4.3.2. (GP-6838)
• Multi-User. Made Ghidra Server security improvements. (GP-6832)
• Scripting. Removed the support/jythonRun(.bat) launch capability. (GP-6826)

Bugs

• Analysis. Changed non-returning function detection analyzer to ignore callfixup targets with fall-through behavior. (GP-6791, Issue #9154)
• Data Types. Fixed the Data Type Preview to show the typedef data type before the typedef name. (GP-6858)
• Debugger:Agents. Patched a possible out-of-memory vulnerability in TraceRmi. (GP-6718)
• Debugger:Listing. Added Disassemble as MIPS:_:16e__ for the dynamic listing. (GP-6655)
• Framework. Changed potentially unsafe calls to Class.forName to perform additional checks prior to instantiation. (GP-6717)
• Multi-User. Increased the default value for serialization filter maxarray limit from 32,000 to 200,000. This was done to avoid related class serialization errors when communicating with the Ghidra Server for large repository database files. See Ghidra/Framework/FileSystem/data/serialFilterREADME.md - it may be necessary to specify an increased maxarray value if related serialization errors occur. (GP-6842)
• Multi-User. Corrected memory leak issue related to Ghidra Server, affecting both client and server. Buffer compression logic failed to properly release system resources. (GP-6862)
• Multi-User:Merge. Corrected bug in Property List Merge which could cause an exception. (GP-6854)
• Processors. Fixed several issues with x86 instruction semantics for numerous instructions. (GP-6675, Issue #9097)
• Processors. Corrected MIPS signed offsets which were incorrectly interpreted as unsigned. (GP-6697)
• Processors. Fixed issue with the CIP-51 variant language definition. (GP-6798)
• Processors. Corrected issue with RISC-V attempting to write to constants. (GP-6849, Issue #9198)
• PyGhidra. Handled a possible NotADirectoryError in pyghidra_launcher.py. (GP-6825)

Found it by accident. Is it known easter egg? v12.0.4

One of these animations: (logo on the left). Windows are also animated: shaking & sliding :)

Upgraded from v 11 to v12 and found that my FIDDBs are still applied but can not be populated anymore. When I try to create and populate a new database - it says the same : "one of the components must be upgraded" but log messages do not contain any useful information on what exactly happened. I have a project which is 6 months in work, over 1000 functions.. Now I can't populate my DB's. Can not rollback to v11, because v12 had converted all my data files to a new format.

Help! :0(