The Binary: dgf, anatomized

1.1Identity and build provenance

Everything in this table is measured from the file itself (readelf, nm, Ghidra), not inferred:

Embedded build paths confirm the origin: /home/inn/wkdir/type3/dgtype3_build_r16/… and /jenkins/workspace/dgf/…: a developer's Linux box feeding a Jenkins CI job. The game and its board image (Linux kernel uImage, 3.4.113, dated Dec 2017) were shipped together on the unit's 8 GB eMMC.

Two shipped binaries, four patched bytes

Two copies of the game exist in this project's corpus, differing at exactly one instruction site: the SW2001 anti-clone dongle check (§1.5):

All screenshots and live experiments in this report run the playable binary; everything else is untouched original code.

1.2What the symbol table reveals

Although the game was shipped without debug info for its own code, the linker kept the symbol table, and the 458 STT_FILE records preserve the original source-file names. They expose the module split of the game exactly as its authors organized it:

The usb*con.cpp names confirm three physical controller families polled through evdev: the consumer mascon/brake unit (dencon), the two-handle cabinet (shincon), and a third-party type-RJ controller, each with its own driver module inside the game.

1.3The debug-info red herring

file dgf reports “with debug_info”. That is technically true and practically useless: the DWARF is ~2.5 KB, and its line tables reference only three files: the vendor library of the SW2001 anti-clone dongle:

sw2001_verify/src/example.c
sw2001_verify/src/interface.c
sw2001_verify/src/sw2001_aes.c

So: names without types. Every function name is known; no struct layout, field type, or line number is. Everything structural in this report was recovered by decompilation and dynamic verification.

1.4Aqualead: the embedded engine

The game runs on Aqualead, a proprietary Japanese C++ middleware (its AL* classes fill the symtab). The game code does not use Aqualead's higher-level OOP frameworks; its scene graphs, widget, FSM, collision and particle systems are present as compiled code but never instantiated by game logic (decompiled vtable-level analysis across the whole binary). Instead, gameplay is written as plain procedural C-style functions (proc*, in*, out*, entry* ) that use only Aqualead's low-level primitives:

• Fibers (ALFiber) — cooperative mini-threads; the whole game is a set of fibers yielding to each other at 60 Hz.
• Draw packets (ALDrawPacketGLES) — a recorded command stream interpreted by a dedicated render thread.
• Textures / sprites / sounds (ALTexture, ALSprite, ALSound) — thin handles over GLES/OpenAL.
• Archives and compression (ALArchiveImp, ALLzDecoder) — the asset pipeline (Chapter 14).

Platform backends follow an Imp naming pattern: one abstract class, one implementation per platform: ALSystemImpGLES (rendering), ALPadImpUnix (input), ALSoundImpOAL (audio), ALStreamImp (files/save). The port shim substitutes hardware at exactly these boundaries.

1.5The boot chain

From execve() to the title screen, control flows through six named stages:

main @ 0x001918c8
  -> ALInit @ 0x001987e0            ; 1280x720 default, ./Data, /var/lib/save, CLI flags
  -> heap + 120,000-byte fiber stack + GLES screen + platform init
  -> ALMain
       SW2001_verify                ; anti-clone dongle AES check (patched)
       DALInit -> MainTask @ 0x00198938
  -> MainTask
       open("/dev/input/event1")    ; power-switch watchdog fd
       load Warning.atx             ; caution screens
       load BG.aar, Effect.aar
       ps_main()
  -> ps_main                        ; task scheduler, controllers, save iface
       motherTask @ 0x001ffa18      ; the permanent 60 Hz frame boundary
         trainMain @ 0x00213a50     ; subsystem init, then task-99 process dispatch

The decompiled entry point: note the 120,000-byte fiber stack allocated inside main's own stack frame:

/* DGF process bootstrap. ALInit selects ./Data and /var/lib/save, creates the Aqualead
   heap/fiber and GLES screen, then ALMain starts the game. */

undefined4 main(undefined4 param_1,undefined4 param_2)
{
  ALSystemImp::IsALInit = 1;
  ALSystemImp::ArgParams = param_2;
  ALSystemImp::ArgCount = param_1;
  ALInit();                                          // flags, paths, screen size
  if (ALSystemImp::UseMemorySize == 0) {
    pAVar2 = ALHeapBaseImp::CreateMallocHeap();      // default: malloc-backed heap
  }
  else {
    pvVar4 = malloc(ALSystemImp::UseMemorySize);
    pAVar2 = ALHeap::Create(pvVar4,sVar1);
    ALHeapBaseImp::FreeFunc = 0x386295;
  }
  ALHeap::SetCurrent(pAVar2);
  ALFiber::InitStack(auStack_1d4d0,120000);          // 120 KB fiber stack on main's frame
  ALPropSetImp::Init();
  ALSystemImpGLES::InitOpenGLES(&pvStack_1d4d4);
  /* screen factory guard, ALScreenImp::Entry, ALSystemImp singleton … */
  ALInitPlatform();
  main::simp._1112_4_ = ALFiber::Create((_func_void_void_ptr *)0x3852d9,(void *)0x0);
  ALMain();                                          // dongle check, DALInit, MainTask
  ALSystemImp::ExitStatic();
  return *(undefined4 *)(ALSystem::_Imp + 0x440);
}

Command-line flags

ALInit parses dash-flags into globals that gate behavior all over the binary:

The SW2001 anti-clone dongle

The unit carries a small I²C AES authentication chip; SW2001_verify (in the only DWARF-covered code!) challenges it at boot and refuses to run the game on unauthorized hardware. The four-byte patch in the playable binary turns the verification into return 1 (the classic single-instruction license check bypass. A reimplementation simply omits this step; it has zero effect on gameplay.

1.6How this report was produced

Three instruments, cross-checked:

• Ghidra (with the ReVa MCP bridge) — primary decompiler; 19,258 functions analyzed; prior round-trip annotations preserved in the program database.
• Binary Ninja (BNDB) — second decompiler; every load-bearing claim in this report was verified to agree, and disagreements are flagged where they matter.
• Live runs — the stock binary executes on desktop Linux under a small LD_PRELOAD shim that replaces only the hardware touchpoints (§below). The game is not modified: menus, physics, scoring and rendering run original code, and every screenshot in this report comes from those runs.

What the shim replaces, andand what that proves

The original hardware exposes exactly four game-facing services. Replacing each one without touching the binary is a live probe of the game's true platform contract:

Capture-harness disclosure

Full transparency about how this report's screenshots were produced, because two of the techniques touch game state:

• Emulation — the stock armhf binary runs under qemu-user with a Debian armhf sysroot (Mesa llvmpipe, stock OpenAL) at 0.5–10 fps. A guest-memory peek/poke tool (guest base + /proc/pid/mem) reads and writes game globals live (the same technique documented for the port project, used here to verify every address quoted in this report against the running game.
• Caution-screen skip — the three boot caution screens are pure timed fades (DispBG: 60+240+60 frames each, no key read). The harness holds the -menuloop flag global (0x6c874c) high through MainTask's check, which skips them (a documented flag path, not a code patch).
• Departure assistance — the audio-completion deadlock (Chapter 6) was released by writing GameConditionBk / gameStatus[0], and two captures used the -undead debug flag (a shipped command-line option) so penalty spam during high-speed positioning could not end the run. The physics, judgments, HUD and rendering in every screenshot are unmodified game code reacting to real inputs; some of those inputs were memory writes instead of lever movements.

1.7The binary in numbers