Navigation: Cross links and call graph
Static analysis of binary files is not a consistent reading of code from top to bottom. These are jumps between functions along the call chain: from a suspicious string to a function that uses it, from the function to the one who calls it.
Crosslinks (XREFs)
Right click by function name or variable → References → Show References to. Ghidra will show all the places in the binary where this function is invoked or the variable is used.
A typical scenario: You found a suspicious string via Window → Defined Strings (e.g., IP address or URL). Clicked on the cross link – got into the function that uses this line. Opened Decompile — see context: the line is transmitted to connect() or send(). Conclusion: the binary climbs to this address. Next is the matter of technology.
By default, the hotkeys in Ghidra differ from the usual IDA-shemps. The Securelist article describes a configuration that is compatible with IDA habits: X – cross links, Esc – back, C – code, D – data. I advise you to set up so if you plan to work with Ghidra regularly - fingers will say thank you.
Call Count
Window → Function Call Graph shows a visual map: what functions the current one calls and who calls it. To analyze malware, this is critical – you see the “skeleton” of the program and determine which branches are responsible for the network, file system or encryption.
How to use Ghidra: six steps to disassemble the binary
Here is the algorithm I use for every new file. It does not require a deep knowledge of the assembler - it is enough to read the pseudocode and use navigation.
Step 1: exploration to Ghidra. Before importing I launch file suspicious_binary to define the format and architecture. Then strings suspicious_binary | grep -iE "http|\.com|password|key" – utility strings extracts readable strings from the binary. Often, C2 addresses or keys are detected before the decompiler is started. Ten seconds in the terminal can save half an hour in Ghidra.
Step 2: Import and Autoanalysis. I open the file in Ghidra, I agree to autoanalysis. After completion, I check Symbol Tree: there are meaningful function names (main, init, send_data) or only FUN_*. The first option is binary not stripped, the task is easier. The second is to deal with behavior.
Step 3: the lines. Window → Defined Strings. Ghidra shows all the lines found by autoanalysis: error messages, URLs, file paths, shell commands, registry keys. Each suspicious line is the entry point for deep analysis through cross-references.
Step 4: the entry point. In Symbol Tree looking for a function main (or entry, if main absent). I open in Decompile and read: what does the program do first? Initializing the network? Checking the environment? Decrypting the configuration?
Step 5: movement on calls. From main I follow the functions calls, clicking on the names in the pseudocode. Each function, the purpose of which became clear, I rename: FUN_00401150 → check_password, FUN_00401300 → connect_to_c2, FUN_004015A0 → decrypt_config. After an hour, the binary turns from a set of faceless addresses to a program with understandable logic.
Step 6: Documentation. Ghidra retains all the renaming and comments in the project. I add notes to key finds through Set Comment (right click). When you reopen, everything is in place.
This workflow is scalable: simple CrackMe – 20 minutes, medium-sized binary with obfuction – a few hours. The approach is the same: lines → cross links → pseudocode reading → renaming → repeat.
CTF reverse with Ghidra: from tasks to skills
The category reverse on CTF competitions is the best simulator for mastering Ghidra. A typical task: give a compiled binary, you need to find a flag - a line of the format flag{...}.
Entry-level tasks are solved in minutes according to the described workflow: import → lines → reading pseudocode. The flag line can lie in the open (as in the example with strcmp) or be encrypted by a simple XOR.
More complex tasks add obfuscation: strings are encrypted with a non-trivial algorithm, the binary checks the presence of a debugger, the logic is scattered across a dozen functions. But even here, the decompiler gives out the read pseudocode - a question in patience when disassembling.
According to the Introduction to Reverse Engineering with Ghidra (wrongbaud, Hackaday-U) course, the optimal learning format is four sessions with CrackMe tasks of increasing complexity. Each task is a binary with a password or key that needs to be removed. The course is designed for students with minimal preconditions: basic acquaintance with C and any scripted language. After the fourth task, students confidently navigate the interface and read the decompiled code without help. Four CrackMe and Ghidra ceases to seem alien.
Ghidra vs IDA Pro: what to choose for reverse software development
This question is asked in every second track on Reddit on reverse engineering. Here is a comparison by the criteria that really affect the work:
Criterion Ghidra IDA Pro + Hex-Rays
Price Free, open source Commercial license
Built-in decompiler Yes, all the architectures Hex-Rays is a separate module
Decompilation Quality x86_64 Good Great
Scripting Java, Python (Jython) IDAPython
Joint work Ghidra Server (native) Through third-party decisions
Convenience of the interface from the box Requires customization More intuitive
Supporting Architectures Wide, including rare Wide
Autoanalysis speed Average Faster on large files
For beginners, the choice is obvious: Ghidra is free and includes a decompiler out of the box. IDA Free (free version) has significant decompilation restrictions. Full IDA Pro with Hex-Rays is a tool for professionals with a corresponding budget.
In practice, I use Ghidra as the main tool for static analysis of binary files, IDA Free for quick re-checking of individual sites, x64dbg when dynamic analysis is needed. The author of the article on Securelist describes a similar transition: after setting up the hotkeys and the interface, he stopped returning to the usual tools.
Nuance, which is not written about: the quality of the decompilation of Hex-Rays for x86_64 is really higher. Pseudocode is cleaner, the types are more precisely. But the difference is critical in the analysis of complex optimized binarys - for typical tasks (malware-analysis, CTF with reverse Ghidra) decompiler Ghidra is enough. I switched to Ghidra as the main instrument two years ago and I have no regrets.
Typical errors in the analysis of binary in Ghidra
Reading the assembly instead of pseudocode. Newcomers open Listing and are scared of walls from MOV and PUSH. Start with the Decompile window. The assembler will be needed later when the decompiler will issue the trash.
Rejection of renaming. FUN_00401000 He says nothing. Take 5 seconds to rename each understood feature – in an hour you will have a readable binary card. This skill saves hours when re-returned to the file.
Blind trust to the decompiler. Ghidra decompiler confuses types, incorrectly defines the boundaries of functions, generates designs that did not exist in the original. The pseudocode looks illogical – check with the assembler in Listing. Don't be lazy.
Passing autoanalysis. Clicked “No” on the offer Auto Analysis – the binary will remain unmarked: the functions are not defined, no strings are found, cross links are not available. Run autoanalysis on every import. No exceptions.
Analysis without foreign intelligence. Open the binary in Ghidra without driving through file and strings – spend 30 minutes searching for what the command line would show in 10 seconds. The utility strings often issues C2 addresses, passwords, or configuration paths even before the decompiler is started.
Static analysis of binary files is not a consistent reading of code from top to bottom. These are jumps between functions along the call chain: from a suspicious string to a function that uses it, from the function to the one who calls it.
Crosslinks (XREFs)
Right click by function name or variable → References → Show References to. Ghidra will show all the places in the binary where this function is invoked or the variable is used.
A typical scenario: You found a suspicious string via Window → Defined Strings (e.g., IP address or URL). Clicked on the cross link – got into the function that uses this line. Opened Decompile — see context: the line is transmitted to connect() or send(). Conclusion: the binary climbs to this address. Next is the matter of technology.
By default, the hotkeys in Ghidra differ from the usual IDA-shemps. The Securelist article describes a configuration that is compatible with IDA habits: X – cross links, Esc – back, C – code, D – data. I advise you to set up so if you plan to work with Ghidra regularly - fingers will say thank you.
Call Count
Window → Function Call Graph shows a visual map: what functions the current one calls and who calls it. To analyze malware, this is critical – you see the “skeleton” of the program and determine which branches are responsible for the network, file system or encryption.
How to use Ghidra: six steps to disassemble the binary
Here is the algorithm I use for every new file. It does not require a deep knowledge of the assembler - it is enough to read the pseudocode and use navigation.
Step 1: exploration to Ghidra. Before importing I launch file suspicious_binary to define the format and architecture. Then strings suspicious_binary | grep -iE "http|\.com|password|key" – utility strings extracts readable strings from the binary. Often, C2 addresses or keys are detected before the decompiler is started. Ten seconds in the terminal can save half an hour in Ghidra.
Step 2: Import and Autoanalysis. I open the file in Ghidra, I agree to autoanalysis. After completion, I check Symbol Tree: there are meaningful function names (main, init, send_data) or only FUN_*. The first option is binary not stripped, the task is easier. The second is to deal with behavior.
Step 3: the lines. Window → Defined Strings. Ghidra shows all the lines found by autoanalysis: error messages, URLs, file paths, shell commands, registry keys. Each suspicious line is the entry point for deep analysis through cross-references.
Step 4: the entry point. In Symbol Tree looking for a function main (or entry, if main absent). I open in Decompile and read: what does the program do first? Initializing the network? Checking the environment? Decrypting the configuration?
Step 5: movement on calls. From main I follow the functions calls, clicking on the names in the pseudocode. Each function, the purpose of which became clear, I rename: FUN_00401150 → check_password, FUN_00401300 → connect_to_c2, FUN_004015A0 → decrypt_config. After an hour, the binary turns from a set of faceless addresses to a program with understandable logic.
Step 6: Documentation. Ghidra retains all the renaming and comments in the project. I add notes to key finds through Set Comment (right click). When you reopen, everything is in place.
This workflow is scalable: simple CrackMe – 20 minutes, medium-sized binary with obfuction – a few hours. The approach is the same: lines → cross links → pseudocode reading → renaming → repeat.
CTF reverse with Ghidra: from tasks to skills
The category reverse on CTF competitions is the best simulator for mastering Ghidra. A typical task: give a compiled binary, you need to find a flag - a line of the format flag{...}.
Entry-level tasks are solved in minutes according to the described workflow: import → lines → reading pseudocode. The flag line can lie in the open (as in the example with strcmp) or be encrypted by a simple XOR.
More complex tasks add obfuscation: strings are encrypted with a non-trivial algorithm, the binary checks the presence of a debugger, the logic is scattered across a dozen functions. But even here, the decompiler gives out the read pseudocode - a question in patience when disassembling.
According to the Introduction to Reverse Engineering with Ghidra (wrongbaud, Hackaday-U) course, the optimal learning format is four sessions with CrackMe tasks of increasing complexity. Each task is a binary with a password or key that needs to be removed. The course is designed for students with minimal preconditions: basic acquaintance with C and any scripted language. After the fourth task, students confidently navigate the interface and read the decompiled code without help. Four CrackMe and Ghidra ceases to seem alien.
Ghidra vs IDA Pro: what to choose for reverse software development
This question is asked in every second track on Reddit on reverse engineering. Here is a comparison by the criteria that really affect the work:
Criterion Ghidra IDA Pro + Hex-Rays
Price Free, open source Commercial license
Built-in decompiler Yes, all the architectures Hex-Rays is a separate module
Decompilation Quality x86_64 Good Great
Scripting Java, Python (Jython) IDAPython
Joint work Ghidra Server (native) Through third-party decisions
Convenience of the interface from the box Requires customization More intuitive
Supporting Architectures Wide, including rare Wide
Autoanalysis speed Average Faster on large files
For beginners, the choice is obvious: Ghidra is free and includes a decompiler out of the box. IDA Free (free version) has significant decompilation restrictions. Full IDA Pro with Hex-Rays is a tool for professionals with a corresponding budget.
In practice, I use Ghidra as the main tool for static analysis of binary files, IDA Free for quick re-checking of individual sites, x64dbg when dynamic analysis is needed. The author of the article on Securelist describes a similar transition: after setting up the hotkeys and the interface, he stopped returning to the usual tools.
Nuance, which is not written about: the quality of the decompilation of Hex-Rays for x86_64 is really higher. Pseudocode is cleaner, the types are more precisely. But the difference is critical in the analysis of complex optimized binarys - for typical tasks (malware-analysis, CTF with reverse Ghidra) decompiler Ghidra is enough. I switched to Ghidra as the main instrument two years ago and I have no regrets.
Typical errors in the analysis of binary in Ghidra
Reading the assembly instead of pseudocode. Newcomers open Listing and are scared of walls from MOV and PUSH. Start with the Decompile window. The assembler will be needed later when the decompiler will issue the trash.
Rejection of renaming. FUN_00401000 He says nothing. Take 5 seconds to rename each understood feature – in an hour you will have a readable binary card. This skill saves hours when re-returned to the file.
Blind trust to the decompiler. Ghidra decompiler confuses types, incorrectly defines the boundaries of functions, generates designs that did not exist in the original. The pseudocode looks illogical – check with the assembler in Listing. Don't be lazy.
Passing autoanalysis. Clicked “No” on the offer Auto Analysis – the binary will remain unmarked: the functions are not defined, no strings are found, cross links are not available. Run autoanalysis on every import. No exceptions.
Analysis without foreign intelligence. Open the binary in Ghidra without driving through file and strings – spend 30 minutes searching for what the command line would show in 10 seconds. The utility strings often issues C2 addresses, passwords, or configuration paths even before the decompiler is started.
