(adsbygoogle = window.adsbygoogle || []).push({}); # Black Ops 1 PS3 1.13 — Reverse-Engineered EBOOT, GSC Builtin SDK and Resynced Zombies SPRX

I have been working on a large Black Ops 1 Zombies reverse-engineering and SPRX development project for PS3.

The project is called **BO1-Resynced** and currently targets:

* Black Ops 1 PS3
* Update 1.13
* BLES01031
* Zombies
* Private, local and offline use
* Native C++ SPRX development

This is not just a basic mod menu with hardcoded memory options. The project now includes a documented EBOOT function catalog, GSC builtin database, asset databases, native runtime systems and a standalone developer SDK.

## Quick overview

Current project contents include:

* 12,746 discovered EBOOT functions
* 895 documented GSC global builtins and entity methods
* 61 typed or mapped engine bindings
* Native GSC VM builtin dispatcher
* Standalone BO1 PS3 C++ SDK
* Map-aware weapon, model, FX, sound and perk catalogs
* Native HUD and controller hooks
* Server-frame job and command queues
* Runtime completion and readback systems
* 8 main menu sections
* 40 dynamic subviews
* 78 currently connected menu options
* PPU compiler validation
* Automated regression tests
* Human-readable TTY diagnostics

## EBOOT.ELF reverse engineering

I extracted and analyzed the complete discovered function inventory from the BO1 1.13 PS3 EBOOT.ELF.

The database currently contains 12,746 function records.

Each record can contain:

* EBOOT entry address
* Original Ghidra `FUN_` name
* Generated semantic name
* Human-readable display name
* Subsystem classification
* Referenced strings
* Callers
* Callees
* Alias provenance
* Confidence level
* Known OPD information
* Known TOC information

The project uses the BO1 PS3 TOC:

```cpp
0x00A544B0
```

Native calls use PS3 ELFv1 function descriptors instead of blindly casting raw addresses.

Example documented subsystems include:

* Script VM
* Weapons
* Entities
* Zombies and AI
* Rendering and HUD
* Input
* Dvars
* Asset database
* FX
* Sound
* Navigation
* World and collision
* Networking
* Filesystem
* Internal engine systems

Not every internal function has its original Treyarch symbol name or a completely proven prototype.

Functions are therefore separated into confidence levels such as:

* Runtime verified
* Signature verified
* Typed binding
* Exact function entry
* String-reference derived
* Callgraph derived
* Heuristic
* Unknown

This prevents unknown functions from being falsely presented as safe callable APIs.

## GSC builtin and method database

I extracted and documented 895 native GSC entries.

These include both:

* Global GSC builtins
* Entity GSC methods

Examples include systems related to:

* Weapons
* Ammo
* Perks
* Entities
* Models
* FX
* Sound
* Projectiles
* Vectors
* Player state
* Script objects
* Traces
* Spawning
* Deleting entities

The database stores information such as:

* Builtin name
* Native EBOOT entry
* OPD
* Global or entity-method classification
* Known or expected parameters
* Known return type
* Script VM requirement
* Confidence level
* Example GSC syntax
* Runtime support status

## Native GSC VM execution

This SPRX does not currently rely on custom injected GSC scripts.

Supported builtins are called directly from the SPRX through the native BO1 GSC VM.

The runtime flow is approximately:

```text
SPRX feature
↓
Queue GSC command
↓
Server-frame dispatcher
↓
Build GSC VM argument stack
↓
Scr_AddString / Scr_AddInt / Scr_AddFloat / Scr_AddVector / Scr_AddEntity
↓
Call native global builtin or entity method
↓
Read return value
↓
Restore VM state
↓
Return completion result to the feature
```

The dispatcher supports:

* Queued execution
* Global builtins
* Entity methods
* Strings
* Integers
* Floats
* Vectors
* Entities
* Boolean results
* Integer results
* Object and entity results
* Completion IDs
* Readback verification
* Per-frame execution limits
* Map and lifecycle resets

Complex features can therefore be composed in native C++ by combining multiple builtins.

## Standalone BO1 SDK

A separate portable developer SDK has been exported from Phoenix.

The SDK contains:

* Public C++ headers
* Native typed API
* GSC VM dispatcher
* Engine layouts
* Semantic symbol headers
* Asset catalogs
* Fastfile resource catalogs
* Usage examples
* API documentation
* GSC calling documentation
* Confidence and safety rules
* SHA-256 manifest
* SDK verification scripts

Important SDK files include:

```text
BO1_SDK/
├── README.md
├── GETTING_STARTED.md
├── API_REFERENCE.md
├── GSC_VM_CALLING.md
├── GSC_EXAMPLES.md
├── include/
├── src/
├── catalogs/
├── docs/
├── examples/
├── verify_sdk.ps1
└── MANIFEST.sha256
```

The SDK explains:

* How to integrate it into an existing SPRX
* How PS3 ELFv1 descriptors work
* How to use the BO1 TOC
* How to initialize typed native bindings
* How to queue GSC builtins
* How to process the dispatcher from the server thread
* Which functions belong on render, game or server threads
* How runtime readback works
* Which APIs are verified and which are documentation-only

The public SDK units compile with the real PS3 Cell PPU compiler using:

```text
-Wall -Wextra -Werror
```

The validated SDK build currently reports no compiler warnings.

## Asset and fastfile catalogs

Phoenix contains generated asset catalogs extracted from local PS3 game and fastfile data.

Cataloged resource categories include:

* Weapons
* Pack-a-Punch weapon variants
* Models
* Zombie models
* Player models
* Script models
* FX
* Sounds
* Perks
* Maps
* DLC maps
* Map-specific resources
* Fastfile script references
* Entity and resource identifiers

The asset system is map-aware.

When a Zombies map is loaded, the menu can use the resources associated with that specific map instead of showing only one global list.

This allows the runtime to provide map-specific:

* Weapon lists
* Upgraded weapon lists
* FX lists
* Sound lists
* Model lists
* Perk identifiers

The catalogs are also usable as developer documentation even when a resource is not yet exposed as a runtime action.

## Runtime and hook system

Phoenix currently contains native hooks and runtime systems for:

* HUD rendering
* Text rendering
* Controller input
* Input suppression
* Server-frame processing
* Runtime context detection
* Private-host validation
* Map lifecycle detection
* Job queues
* GSC command queues
* Runtime events
* Human-readable TTY logging
* Feature completion readback

Important hooks include systems around:

* Draw2D
* Controller state construction
* G_RunFrame
* Server-side feature execution

Gameplay mutations are scheduled from the server-frame context instead of being executed from random SPRX threads.

## Weapon and inventory systems

Implemented or connected inventory functionality includes:

* Give weapon
* Take weapon
* Switch weapon
* Give maximum ammo
* Has-weapon verification
* Set perk
* Unset perk
* Clear perks
* Has-perk verification
* Map-aware Weapon Vault
* Pack-a-Punch weapon browser
* Inventory completion readback

Weapon and perk actions are verified after mutation instead of assuming that the native call succeeded.

## FX Studio

The FX runtime supports:

* Map-aware FX selection
* Native `loadfx`
* Native `playfx`
* Position and direction parameters
* Asynchronous FX loading
* FX completion handling
* One-shot effects
* Runtime cleanup
* FX browser integration

The FX browser can select an exact cataloged effect and play it through the GSC VM.

## Sound Studio

Sound Studio currently supports:

* Map-aware sound selection
* Next Map Sound
* Play Selected Sound
* Timed sound loops
* Configurable loop intervals
* GSC VM completion verification
* Clean loop stopping
* Map-change cleanup
* Safe Reset cleanup
* Human-readable TTY messages

Example diagnostic markers include:

```text
PHX|GELUID_STUDIO|LOOP_GESTART
PHX|GELUID_STUDIO|GELUID_BEVESTIGD
PHX|GELUID_STUDIO|LOOP_GESTOPT
```

## Projectile Lab

Projectile Lab is connected to real native GSC builtin execution.

The flow uses:

```text
getplayerangles
↓
anglestoforward
↓
magicbullet
```

Available controls include:

* Map-aware projectile weapon
* Projectile distance
* Launch height
* Volley size from 1 to 8
* Single volley
* Automatic volleys
* Completion verification
* Owner cleanup
* Runtime capability probing

Example TTY events include:

```text
PHX|PROJECTIEL_STUDIO|VOLLEY_INGEPLAND
PHX|PROJECTIEL_STUDIO|VOLLEY_BEVESTIGD
PHX|PROJECTIEL_STUDIO|VOLLEY_MISLUKT
PHX|PROJECTIEL_STUDIO|AUTO_GESTART
PHX|PROJECTIEL_STUDIO|AUTO_GESTOPT
```

## World and entity systems

The world bridge currently supports a native flow similar to:

```text
codespawn("script_model", origin)
↓
Receive entity result
↓
setmodel(entity, model)
```

World functionality includes:

* Script-model creation
* Model assignment
* Entity handles
* Entity deletion
* Runtime ownership
* Map reset
* Asynchronous completion
* Object Builder foundations
* Vendor terminal placement

## Vendor and terminal system

Phoenix contains a Zombies Supply Terminal runtime.

Current terminals support:

* Map-aware weapons
* Map-aware perks
* Proximity detection
* Square-button interaction
* One purchase/action at a time
* Give-weapon verification
* Give-perk verification
* Map-change cleanup
* Edge-triggered interaction messages
* Unique runtime handle namespaces

The score functions from `_zombiemode_score.gsc` have been located and documented.

However, paid vendor support remains disabled until the exact entity-thread or script-field calling ABI is fully proven.

The current terminal implementation is therefore free and functional rather than using an unsafe guessed score call.

## Companion and Turret Lab

The Companion/Turret section includes an **Overhead Cannon** feature.

This combines:

* Live player view angles
* Direction-vector calculation
* Map-aware magic bullets
* Configurable firing height
* Configurable burst size
* Configurable interval
* Automatic firing
* Runtime readback
* Lifecycle reset
* Human-readable TTY events

It is currently a player-directed cannon.

Automatic zombie targeting is kept separate until entity enumeration and targeting are completely validated.

## Zombie and wave systems

Current zombie-related systems include:

* Zombie entity classification
* Zombie health manipulation
* Freeze systems
* Speed profiles
* Magnet-style behavior
* Wave profiles
* Insta-kill policies
* AI velocity research
* Kill Active Horde

`Kill Active Horde`:

* Scans active entities
* Targets only validated zombie actor types
* Ignores unrelated entities
* Changes living zombie health to zero
* Reads the health value back
* Reports the number of affected zombies through TTY

## Developer browsers

Phoenix includes several internal developer and reverse-engineering browsers.

These include:

### Engine Binding Browser

Displays:

* Binding name
* EBOOT address
* Runtime state
* Required thread
* Prototype classification
* Required capability

Binding states include:

```text
MAP
SIG
READY
FAIL
OFF
```

### Script Browser

Displays all cataloged GSC entries with:

* Global or method classification
* Builtin name
* Native entry
* OPD
* GSC VM status

### Weapon Vault

Displays map-aware weapon identifiers and can execute supported give-weapon actions.

### Pack-a-Punch Lab

Displays upgraded weapon identifiers separately.

### FX Browser

Displays exact FX names and paths and can queue supported FX.

### Asset Browser

Displays models, perks, sounds and other cataloged resources.

### Dvar Explorer

Displays known and candidate Dvars with safe read-only handling where necessary.

### Developer Probes

Displays:

* Typed engine bindings
* Offline EBOOT function records
* Addresses
* Thread requirements
* Capability state
* Runtime status

## Testing and validation

The project uses both host-side and PS3 PPU compilation tests.

Validation includes:

* Native unit tests
* Runtime harnesses
* Menu contract tests
* Provider tests
* Queue tests
* GSC VM tests
* Inventory tests
* FX tests
* Projectile tests
* Vendor tests
* Zombie tests
* Runtime event tests
* Portable SDK tests
* Export manifest verification
* PPU compile checks
* Compiler warning checks

The current menu architecture contains:

* 8 root views
* 40 dynamic subviews
* 78 connected main options

## Current limitations

The project is still under development.

Important limitations:

* Not every EBOOT function has its original name.
* Not every function prototype is proven.
* Heuristic functions are documentation-only.
* Only verified or supported functions are exposed as callable APIs.
* Some advanced map script logic must be reconstructed from native builtins.
* Custom GSC scripts are not currently used.
* Paid vendor score handling remains locked until its calling ABI is proven.
* Some AI, pathfinding and targeting systems are still being researched.
* Full live feature testing depends on the custom EBOOT loader keeping the SPRX resident.

The project does not expose an unsafe arbitrary-address call function.

## Project goal

The goal is to build more than one private mod menu.

The long-term goal is to create a reusable Black Ops 1 PS3 development and reverse-engineering package containing:

* A documented EBOOT database
* GSC builtin documentation
* Typed native bindings
* Safe GSC builtin execution
* Asset catalogs
* Fastfile resource catalogs
* Hooking documentation
* Runtime examples
* A portable C++ SDK
* A complete Zombies feature framework

This should allow other BO1 PS3 developers to build their own SPRX projects without manually rediscovering every address, OPD, TOC, builtin and asset from the beginning.

This is currently a private local development project. More technical details, screenshots and SDK information may be added as the runtime validation progresses.