A WIP decompilation of Dinosaur Planet for the Nintendo 64

Overview

Dinosaur Planet

A WIP decompilation of Dinosaur Planet for the Nintendo 64

Note: To use this repository, you must already have a ROM for the game.

OS:

Linux (Debian / Ubuntu)
Windows 10 (WSL)

Prerequisites:

sudo apt install -y build-essential git binutils-mips-linux-gnu python3
pip3 install -r requirements.txt

To use

  1. Place the Dinosaur Planet ROM into the root of the repository as baserom.z64.
  2. Set up tools and extract the ROM: make setup
  3. Re-build the ROM: make
Comments
  • TActor is missing 13 bytes worth of data between `linkedActor` and `positionMirror2`

    TActor is missing 13 bytes worth of data between `linkedActor` and `positionMirror2`

    With the struct defined as it is currently, my memory dumping script (which matches the C header exactly) prints output that looks like the following, for example:

    "TActor_0": {
      "name": "Krystal",
      "address": "0x806ED020",
      "fields": {
        "rotation": [-25166, 0, 0],
        "unk0x6": 2,
        "scale": 0.0494999997317791,
        "position": [2108.28564453125, -41.19002151489258, 16808.6328125],
        "positionMirror": [2108.28564453125, -41.19002151489258, 16808.6328125],
        "speed": [0, 0, 0],
        "ptr0x30": "0x00000000",
        "unk0x34": 65535,
        "linkedActor": "0x800EC398",
        "unk0x3c": [68, 255, 0],
        "unk0x44": 68,
        "unk0x46": 18432,
        "ptr0x48": "0x00000100",
        "unk0x4c": 520094208,
        "ptr0x50": "0x00000000",
        "ptr0x54": "0x00803981",
        "unk0x58": 3900731102,
        "ptr0x5c": "0x7C000000",
        "ptr0x60": "0x00806286",
        "ptr0x64": "0x08806ED9",
        "ptr0x68": "0xD8806EDE",
        "ptr0x6c": "0x38802529",
        "ptr0x70": "0xD0806EDF",
        "unk0x74": 545287903,
        "positionMirror2": [-2199023255552, 0, 1.1794696944357306e-38],
        "positionMirror3": [2.3158967801400164e-36, -1.2252182749418445e-27, -4.008937194294739e-26],
    

    however, since positionMirror2 and positionMirror3 are actually always the same as position and positionMirror when the game is running, clearly that's not correct output. Looking into it in the debugger, I realized that the actual amount of space between linkedActor and positionMirror2 in practice is 68 bytes (or 44 if using hex format values, as shown in the image I've attached) whereas the C header definition currently only adds up to 55 bytes across the following section:

    u8 unk0x3c[3];
    UNK_TYPE_16 unk0x44;
    UNK_TYPE_16 unk0x46;
    void* ptr0x48;
    UNK_TYPE_32 unk0x4c;
    void* ptr0x50;
    void* ptr0x54;
    UNK_TYPE_32 unk0x58;
    void* ptr0x5c;
    void* ptr0x60;
    void* ptr0x64;
    void* ptr0x68;
    void* ptr0x6c;
    void* ptr0x70;
    UNK_TYPE_32 unk0x74;
    

    After adjusting my script to reflect what I was actually seeing in memory, it then produced output that looks like this, which has the correct values for positionMirror2 and positionMirror3, as well as what look to me like more meaningful values for the surrounding fields:

    "TActor_0": {
      "name": "Krystal",
      "address": "0x806ED020",
      "fields": {
        "rotation": [-25166, 0, 0],
        "unk0x6": 2,
        "scale": 0.0494999997317791,
        "position": [2108.28564453125, -41.19002151489258, 16808.6328125],
        "positionMirror": [2108.28564453125, -41.19002151489258, 16808.6328125],
        "speed": [0, 0, 0],
        "ptr0x30": "0x00000000",
        "unk0x34": 65535,
        "linkedActor": "0x800EC398",
        "unk0x3c": 17663,
        "unk0x3e": 0,
        "unk0x40": 17480,
        "unk0x42": 0,
        "unk0x44": 65567,
        "unk0x48": 131072,
        "ptr0x4c": "0x00000000",
        "ptr0x50": "0x803981E8",
        "ptr0x54": "0x806EDE7C",
        "ptr0x58": "0x00000000",
        "ptr0x5c": "0x80628608",
        "ptr0x60": "0x806ED9D8",
        "ptr0x64": "0x806EDE38",
        "ptr0x68": "0x802529D0",
        "ptr0x6c": "0x806EDF20",
        "ptr0x70": "0x806EDFD4",
        "ptr0x74": "0x00000000",
        "ptr0x78": "0x00000000",
        "ptr0x7c": "0x806ED104",
        "positionMirror2": [2108.28564453125, -41.19002151489258, 16808.6328125],
        "positionMirror3": [2108.28564453125, -41.19002151489258, 16808.6328125],
    

    If you want, I can make a PR that updates the C header definition with the same adjustments I did for my script. Figured I'd open an issue for it first though as there was a fair amount of background info that needed explaining.

    DebugView

    opened by Akira13641 8
  • Add input.c and match/document pretty much all of it

    Add input.c and match/document pretty much all of it

    Split out a bottom chunk of segment_D280.c that looks like all input related functions.

    Also includes some minor updates to main.c related to input function usage.

    opened by Francessco121 1
  • Deobfuscate `TActor.ptr0x38` field

    Deobfuscate `TActor.ptr0x38` field

    This was figured out by the examining the output of the dump-actor-lists-to-JSON script I posted on the coding-reverse-engineering Discord channel yesterday (I'm ssds there, to be clear).

    Specifically, for example, if you look at this partial snippet from an entry for Krystal:

    "TActor_0": {
      "name": "Krystal",
      "address": "0x805F8018",
      "fields": {
        "rotation": [-31233, 0, 0],
        "unk0x6": 2,
        "scale": 0.0494999997317791,
        "position": [971.0263671875, 431.73724365234375, 17771.861328125],
        "positionMirror": [971.0263671875, 431.73724365234375, 17771.861328125],
        "speed": [0, 0, 0],
        "ptr0x30": "0x00000000",
        "unk0x34": 65535,
        "ptr0x38": "0x80101C18",
    

    The ptr0x38 field for her there is the address of another TActor object for which the relevant snippet looks like this:

    "TActor_2": {
      "name": "TriggerArea",
      "address": "0x80101C18",
      "fields": {
        "rotation": [21760, 0, 0],
        "unk0x6": 2,
        "scale": 1,
        "position": [1151.096435546875, 367.7933044433594, 17801.52734375],
        "positionMirror": [1151.096435546875, 367.7933044433594, 17801.52734375],
        "speed": [0, 0, 0],
        "ptr0x30": "0x00000000",
        "unk0x34": 65280,
        "ptr0x38": "0x800F9950",
    

    which in turn has a ptr0x38 field set to the address of a third TActor object for which the relevant snippet looks like this:

    "TActor_3": {
      "name": "TriggerPlane",
      "address": "0x800F9950",
      "fields": {
        "rotation": [-8192, 0, 0],
        "unk0x6": 2,
        "scale": 1.875,
        "position": [1129.2900390625, 348.3329162597656, 17473.705078125],
        "positionMirror": [1129.2900390625, 348.3329162597656, 17473.705078125],
        "speed": [0, 0, 0],
        "ptr0x30": "0x00000000",
        "unk0x34": 65280,
        "ptr0x38": "0x00000000",
    

    So in that case, it goes Krystal -> TriggerArea -> TriggerPlane, with TriggerPlane being "the end of the road" so to speak as it does not have a meaningfully initialized ptr0x38 field.

    opened by Akira13641 1
  • Update progress.py

    Update progress.py

    • Updated progress.py to account for DLL functions and to provide an option for outputting the current progress as a JSON file
    • Sped up DLL function analysis by ~30%
    • Fix Dockerfile build failing when setting the UID to an existing user (e.g. root)
    • Add progress shield to README
    opened by Francessco121 0
  • Fixed permuter support

    Fixed permuter support

    Switching to Ninja sort of broke support for decomp-permuter, this PR makes adjustments to the build system to support permuter and patches permuter to work with DLL code.

    • Added permuter_settings.toml
    • Replaced GCC during build with custom header_deps.py script (also lets Ninja see .asmproc.d dependencies)
    • Added decomp-permuter as a Git submodule (a forked version that works with DLL assembly)
    • Added dino.py shortcuts for permuter
    • dll.py now emits R_MIPS_CALL16 relocations as needed
    opened by Francessco121 0
  • Incremental DLL decomp

    Incremental DLL decomp

    This PR introduces support for building partially decomp'd DLLs.

    • GLOBAL_ASM support for DLL C files.
    • Ability to link the original .data, .rodata, and .bss sections of a DLL.
    • Ability to specify symbols per DLL.
    • Ability to write custom linker scripts per DLL.
    • dino.py extract will now 'split' DLL code similarly to splat.
    • New dino.py setup-dll <dll> command to init an environment for decomp'ing a DLL.
    • New tools for inspecting DLL-related binaries:
      • tools/dlldump.py
      • tools/dlltab.py
      • tools/dllimports.py
    • Fork of asm_processor with asm .reloc directive support.
    • Updated version of elf2dll with minor bug fixes.
    • A few newly decomp'd DLLs:
      • 82
      • 83
      • 223 (CannonClaw)
    opened by Francessco121 0
  • Small tool updates

    Small tool updates

    • Prevent Dockerfile usage creating files as root
    • Small config clean up
    • dino.py now generates expected/, which contains matching object files for each source. Needed by diff.py to diff by object file.
    • Add --use-cache flag for ./dino.py extract
    • Fix ./dino.py diff not passing arguments to diff.py correctly
    • ./dino.py extract now automatically re-configures the build script
    opened by Francessco121 0
  • Match/organize a bunch of libultra functions

    Match/organize a bunch of libultra functions

    This isn't everything, but it's a bunch that easily matched from libreultra. I noted any changes that I had to make to get it to match. I also tried following the file names and folder structure of libreultra for consistency.

    Some other notable changes:

    • The makefile now supports building files with -O1 and -O2 -g0 depending on the name of the parent folder (O1 and g0 respectively).
    • Renamed _bcopy to bcopy.
    • Renamed _sqrtf to sqrtf.
    • Renamed _bcmp to bcmp.
    • Renamed matrix_perspective to guPerspectiveF (as far as I can tell, it's what that is, but I wasn't able to get it to fully match from the libreultra version).
    opened by Francessco121 0
  • Match rest of crash.c + a DLL system function

    Match rest of crash.c + a DLL system function

    • Matches remaining functions in crash.c
    • Fixes OSThread and OSSched definitions (there was 128 unknown bytes defined in OSSched that were actually part of the OSThread field before it)
    • Matched find_executing_dll (aka func_8000BD1C, which is called by a crash function)
    opened by Francessco121 0
  • Add required dependencies for progress.py

    Add required dependencies for progress.py

    I noticed progress.py didn't have the proper dependencies listed in requirements.txt. I added them so that they are installed during first-time setup.

    opened by Sunlitspace542 0
  • Add contribution guide

    Add contribution guide

    This adds a CONTRIBUTING.md file explaining how the decomp works, what to know beforehand, and how to contribute. Also includes a list of resources like the MIPS and N64 manuals.

    My goal here is to make it easier for new people (especially those who have never done a decomp before) to come onboard and get started.

    Leaving this as a draft for now because I think there's probably better ways to word some of this and hopefully others have some suggestions 😄.


    Edit: I think this is in pretty good shape for a first iteration, can always change this later!

    opened by Francessco121 0
Owner
null
[WIP] A Riru module tries to enable Magisk hide for isolated processes.

Riru-IsolatedMagiskHider Background Many applications now detect Magisk for security, Magisk provided "Magisk Hide" to prevent detection, but isolated

残页 554 Nov 22, 2022
A WIP "Vulnerable by Design" kext for iOS/macOS to play & learn *OS kernel exploitation

Vulnerable Kext A WIP (work-in progress) "Vulnerable by Design" kext for iOS/macOS to play/learn with *OS kernel exploitation Usage Documentation can

Chaithu 220 Oct 26, 2022
✔️The smallest header-only GUI library(4 KLOC) for all platforms

Welcome to GUI-lite The smallest header-only GUI library (4 KLOC) for all platforms. 中文 Lightweight ✂️ Small: 4,000+ lines of C++ code, zero dependenc

null 6.5k Nov 24, 2022
A decompilation of the Nintendo Switch version of Captain Toad: Treasure Tracker [v1.3.0].

cttt-decomp A decompilation of the Nintendo Switch version of Captain Toad: Treasure Tracker [v1.3.0]. Build Instructions Obtain a clean copy of a mai

shibbs 14 Aug 17, 2022
Source code for Amiga intro Planet Disco Balls

Planet Jazz - Planet Disco Balls (Amiga A500 Intro Source) What is it? This is the 68000 assembler source code for the Planet Jazz "Planet Disco Balls

Jonathan Bennett 21 Oct 1, 2022
Generate a fictive and unique planet in ascii art with your gnupg fingerprint

GF2PA GPG Fingerprint 2 Planet Ascii Description Examples Usage Compilation Execution Other examples Description Generate a fictive and unique planet

null 4 Mar 12, 2022
Nintendo DS(i) ROM editor for the Nintendo DS(i) consoles themselves

NitroEdit NDS(i) ROM editor for the Nintendo DS(i) consoles themselves NitroEdit is a NDS(i) ROM editor for the Nintendo DS(i) consoles themselves, wh

XorTroll 39 Aug 19, 2022
A decompilation of Banjo Kazooie. (MIRROR of https://gitlab.com/banjo.decomp/banjo-kazooie)

banjo Building Grab tools git submodule update --init --recursive Drop in US v1.0 as baserom.us.v10.z64 (sha1sum: 1fe1632098865f639e22c11b9a81ee8f29c7

Nintendo 64 Decompilation Projects 166 Nov 21, 2022
Decompilation of 3D Pinball for Windows – Space Cadet

Decompilation of 3D Pinball for Windows – Space Cadet

Muzychenko Andrey 2.3k Nov 27, 2022
PaRappa the Rapper Decompilation

PaRappaSource PaRappa the Rapper Decompilation Compiling The instructions for this should largely be the same as PSXFunkin without the iso makes. You

null 14 Oct 31, 2022
A decompilation of Guxt (2007 game by Studio Pixel)

Guxt Decompilation Project WIP. Mostly based on work of @tilderain. Reverse engineering of remaining parts and various fixups was done by me (Alula).

null 2 May 25, 2022
Decompilation of The Legend of Zelda: Ocarina of Time

The Legend of Zelda: Ocarina of Time - WARNING! - This repository is a work in progress, and while it can be used to make certain changes, it's still

Zelda Reverse Engineering Team 3.9k Nov 18, 2022
Hex-Rays microcode plugin for automated simplification of Windows Kernel decompilation.

NtRays NtRays is a Hex-Rays microcode plugin for automated simplification of Windows Kernel decompilation. Features Cleanup of instrumentation and sch

Can Bölük 349 Nov 21, 2022
An in-progress matching decompilation of Final Fantasy VII For the PSX.

FFVII An in-progress decompilation of the original US release of Final Fantasy VII on the PSX. Building (Linux) Install build dependencies The build p

null 16 Oct 4, 2022
An in-progress decompilation of the 1.1 US release of Silent Hill on the Playstation 1.

Silent Hill Decompilation Project An in-progress decompilation of the 1.1 US release of Silent Hill on the Playstation 1. Building (Linux) Install bui

Nicolas 34 Oct 30, 2022
Ezfrags - Decompilation of the CS:GO cheat ezfrags

Ezfrags Ezfrags was the first cheat of a lot of people, and probably their last. This cheat is so popular that it became a meme in the CS:GO community

null 14 Jul 7, 2022
A Super Mario 64 decompilation, brought to you by a bunch of clever folks.

Super Mario 64 This repo contains a full decompilation of Super Mario 64 (J), (U), (E), and (SH). Naming and documentation of the source code and data

Nintendo 64 Decompilation Projects 6.5k Nov 27, 2022
Decompilation of the Berry Fix Program included in Pokémon Emerald and FireRed/LeafGreen

Berry Fix This is a decompilation of the "Berry Program" multiboot image which comes compressed within Pokémon FireRed, LeafGreen, and Emerald. It is

null 8 Nov 13, 2022
[WIP] A Riru module tries to enable Magisk hide for isolated processes.

Riru-IsolatedMagiskHider Background Many applications now detect Magisk for security, Magisk provided "Magisk Hide" to prevent detection, but isolated

残页 554 Nov 22, 2022
A WIP "Vulnerable by Design" kext for iOS/macOS to play & learn *OS kernel exploitation

Vulnerable Kext A WIP (work-in progress) "Vulnerable by Design" kext for iOS/macOS to play/learn with *OS kernel exploitation Usage Documentation can

Chaithu 220 Oct 26, 2022