Ghidra for Beginners: Inspect Your Own Scoring Program

What you will learn

Compile an original C exercise, compare boundary outputs and follow a manual Ghidra analysis plan.

1. Extract into a new folder and run node check.mjs from that folder.
2. For the browser games, run python3 -m http.server 8080 with Python 3 and open http://localhost:8080/index.html. Do not open modules with file://.
3. Read the full setup instructions and the original code licence. Keep your existing game on a separate test branch.

The JavaScript behaviour checks and native C comparison can run independently of the browser. Ghidra UI, physical-phone and your engine integration are separate checks. This is a small reference, not a certification of your project.

Explore the related game idea · Start with Build a Game · Improve your existing game

Five practical steps

1. Build a known local target

   Use the provided score.c on a Linux x86-64 system with GCC and binutils. Run gcc -O0 -g -o score score.c, then ./score 9 and ./score 10. Record compiler version and sha256sum score. This creates your own binary; no game ROM, DRM or third-party executable is needed.

   Expected result: Known outputs reward=27 and reward=35.

   Check it: Also try -1, 0, 100 and 101; record the invalid-range result -1.

   rewardObserve the inputs → check the state → compare the result

2. Inspect symbols and instructions

   Run nm score and objdump -d -M intel score. Locate reward and inspect its comparisons and return paths. Intel syntax here is x86-specific; other architectures have different instructions and calling conventions. Source and compiler flags remain the ground truth.

   Expected result: A named function with boundary checks and a bonus branch.

   Check it: Compare ./score 9 versus 10 before deciding what a conditional jump means.

3. Import in Ghidra manually

   Use the official release requirements and Getting Started guidance for your installed version. Create a local project, import your newly built score, confirm detected format/language and run analysis. Navigate to reward, then compare Listing and Decompiler views. This UI exercise is manual, not claimed as automated acceptance.

   Expected result: A decompiler hypothesis beside the actual instruction listing.

   Check it: Confirm arguments, integer signedness and branch boundaries against the known C source.

4. Compare an optimised build

   Build a separate target with gcc -O2 -o score-fast score.c. Run the same inputs and compare objdump output. Optimisation can fold arithmetic, change branch structure or inline calls; equivalent outputs do not require identical instructions or original variable names.

   Expected result: Two builds with equivalent tested behaviour and different code structure.

   Check it: Use the provided native checks across all integers -1 through 101 for both builds.

5. Reconstruct and state limits

   Describe the reward rule in your own words and implement an equivalent function. Keep the source, build flags, hashes, input table and unresolved hypotheses together. Decompiler output is recovered pseudo-code, not the exact author source or a licence to redistribute unrelated software.

   Expected result: A small reproducible reverse-engineering report.

   Check it: Compare threshold inputs and invalid range; do not generalise this exercise into whole-game compatibility or a verified Ghidra session.

Read and reuse the actual code

score.c: complete source · Standalone behavioural checks · Shared browser runner and input. Original BINX Forge code, MIT; the package includes every required file and its notice.

#include <stdio.h>
#include <stdlib.h>
/* Original practice program. MIT. Inputs are intentionally small. */
int reward(int coins) {
  if (coins < 0 || coins > 100) return -1;
  if (coins >= 10) return coins * 3 + 5;
  return coins * 3;
}
int main(int argc, char **argv) {
  if(argc != 2) return 2;
  char *end; long n = strtol(argv[1], &end, 10);
  if(end == argv[1] || *end || n < -1 || n > 101) return 2;
  printf("reward=%d\n", reward((int)n)); return 0;
}

Code rights: the included MIT notice permits use, modification and distribution, including commercial games and source products, with the copyright and licence notice. Added third-party files have their own terms. Read the official licence & usage terms.

Common failures and fixes

Make Your Game Better

Change one system after the baseline works. Keep the free reference and compare the same inputs before and after.

Licensing summary, not legal advice. Before publishing or selling, check exact terms for finished-game use, reselling files and including files in a source/template product separately.

Keep learning

Original reverse-engineering practice lab · Sonic Unleashed creator-project study · SpaghettiKart creator-project study