xboxdevwiki - User contributions [en]

NV2A/Vertex Shader

2025-12-19T21:34:40Z

Thrimbor: Add pipeline diagram

The Xbox implements the 2 GL extensions [https://www.opengl.org/registry/specs/NV/vertex_program.txt NV_vertex_program] and [https://www.opengl.org/registry/specs/NV/vertex_program1_1.txt NV_vertex_program1_1] (with some modifications).
This article will mainly focus on actual encoding on hardware as the behaviour is mostly outlined in those GL extensions already.

== Operating modes ==

* Fixed / Programmable
* Writeable / Read-Only constants
* Low-constants only / all constants
* Vertex processing / State program

== Pipeline ==

[[File:Vertex_processor.png|352px]]

== Registers ==

=== Input registers ===

There are 16 input registers v[0] to v[15].

They normally [[NV2A/Vertex attributes|map to the vertex attributes]]. However, in the case of vertex state programs, v[0] is fed from LAUNCH_DATA (PGRAPH Methods 0x1E80, 0x1E84, 0x1E88, 0x1E8C for XYZW respectively) instead.

=== Output registers ===

11 output registers o[<RegName>] (initialized to XYZ=0x00000000 W=0x3F800000).

{|class="wikitable"
|+Output registers
|-
!Index
!GL Name
!D3D Name
!Meaning
|-
|0
|HPOS
|oPos
|Homogeneous clip space position
|-
|3
|COL0
|oD0
|Primary color (front-facing)
|-
|4
|COL1
|oD1
|Secondary color (front-facing)
|-
|5
|FOGC
|oFog
|Fog coordinate
|-
|6
|PSIZ
|oPts
|Point size
|-
|7
|BFC0
|oB0
|Back-facing primary color
|-
|8
|BFC1
|oB1
|Back-facing secondary color
|-
|9
|TEX0
|oT0
|Texture coordinate set 0
|-
|10
|TEX1
|oT1
|Texture coordinate set 1
|-
|11
|TEX2
|oT2
|Texture coordinate set 2
|-
|12
|TEX3
|oT3
|Texture coordinate set 3
|}

=== Address register ===

A0.x exists as documented in the GL extension.

=== Temporary registers ===

There are 12 temporary registers: R0 to R11 (initialized to XYZW=0x00000000), as documented in the GL extension.
Additionally, o[HPOS] is mirrored as R12 and can be used as source operand; so effectively you have 13 temporaries

=== Constant space ===

There are 192 constant registers in two seperate blocks with 96 constants each.
They can be accessed through the PGRAPH RDI: select=0x17. Each constant slot is 4x DWORD, ordered as WZYX.
Alternatively they can be uploaded through PGRAPH method [FIXME], with 4x DWORD, ordered XYZW.

In nvidia vertex programs only 96 constants are normally accessible. Microsoft exposed the 96 additional constant registers in D3D shaders through c[-96] to c[-1].
This documentation uses the GL terminology instead and expose the new registers as c[96] to c[191]. This means c[0] to c[191] valid.

== Instructions ==

In total, there are 136 instruction slots.

Each slot consists of 16 bytes, we consider those as 4 seperate little-endian DWORDS describing the operation. Word 0 is inused.

{| class="wikitable"
|+Fields
|-
!Meaning
!Word
!Offset (bits)
!Size (bits)
|-
|ILU Operation
|1
|25
|3
|-
|MAC Operation
|1
|21
|4
|-
|Constant index
|1
|13
|8
|-
|Input index
|1
|9
|4
|-
|Source 1 negate
|1
|8
|1
|-
|Source 1 swizzle X
|1
|6
|2
|-
|Source 1 swizzle Y
|1
|4
|2
|-
|Source 1 swizzle Z
|1
|2
|2
|-
|Source 1 swizzle W
|1
|0
|2
|-
|Source 1 register
|2
|28
|4
|-
|Source 1 mux
|2
|26
|2
|-
|Source 2 negate
|2
|25
|1
|-
|Source 2 swizzle X
|2
|23
|2
|-
|Source 2 swizzle Y
|2
|21
|2
|-
|Source 2 swizzle Z
|2
|19
|2
|-
|Source 2 swizzle W
|2
|17
|2
|-
|Source 2 register
|2
|13
|4
|-
|Source 2 mux
|2
|11
|2
|-
|Source 3 negate
|2
|10
|1
|-
|Source 3 swizzle X
|2
|8
|2
|-
|Source 3 swizzle Y
|2
|6
|2
|-
|Source 3 swizzle Z
|2
|4
|2
|-
|Source 3 swizzle W
|2
|2
|2
|-
|Source 3 register (Hi)
|2
|0
|2
|-
|Source 3 register (Lo)
|3
|30
|2
|-
|Source 3 mux
|3
|28
|2
|-
|Destination MAC mask
|3
|24
|4
|-
|Destination temporary register
|3
|20
|4
|-
|Destination ILU mask
|3
|16
|4
|-
|Destination overall mask
|3
|12
|4
|-
|Destination select
|3
|11
|1
|-
|Destination output register
|3
|3
|8
|-
|Destination mux
|3
|2
|1
|-
|Relative constant addressing
|3
|1
|1
|-
|Final instruction marker (EOF)
|3
|0
|1
|}

{| class="wikitable"
|+Swizzle table
|-
!Value
!Meaning
|-
|0
|X
|-
|1
|Y
|-
|2
|Z
|-
|3
|W
|}

=== Functional units ===

==== Inverse Logic Unit (ILU) ====

{| class="wikitable"
|+ILU Operations
|-
!Value
!Meaning
|-
|0
|NOP
|-
|1
|MOV
|-
|2
|RCP
|-
|3
|RCC
|-
|4
|RSQ
|-
|5
|EXP
|-
|6
|LOG
|-
|7
|LIT
|}

==== Multiply-Accumulate (MAC) ====

{| class="wikitable"
|+MAC Operations
|-
!Value
!Meaning
|-
|0
|NOP
|-
|1
|MOV
|-
|2
|MUL
|-
|3
|ADD
|-
|4
|MAD
|-
|5
|DP3
|-
|6
|DPH
|-
|7
|DP4
|-
|8
|DST
|-
|9
|MIN
|-
|10
|MAX
|-
|11
|SLT
|-
|12
|SGE
|-
|13
|ARL
|}

== Related links ==

* nvidia resources
** [https://web.archive.org/web/20191214200729/https://www.nvidia.com/attach/6559 WhereIsThatVertexShaderInstruction.pdf] / [https://web.archive.org/web/20191214200738/https://www.nvidia.com/attach/6560 WhereIsThatVertexShaderInstruction.doc]
* [https://github.com/envytools/envytools/blob/master/nvhw/pgraph_celsius_xfrm.c Code which appears to implement bit-accurate emulation of some instructions]{{FIXME|reason=Unconfirmed, needs testing}}

[[Category:NV2A]]

File:Vertex processor.png

2025-12-19T21:31:53Z

Thrimbor: Overview of the vertex processor pipeline

Overview of the vertex processor pipeline

APU

2025-07-22T20:47:32Z

Thrimbor: Dead link fix

The [[MCPX]] contains an APU (Audio Processing Unit).

The APU consists of 3 main components for audio-processing:

* VP: A fixed-function block, that generates 32 channel mono audio from voices; the audio is output to the GP MIXBUF.
* GP: A programmable DSP, it is intended for general-purpose audio processing (programmable audio effects for example).
* EP: A programmable DSP, it is intended for audio encoding (5.1 AC3 encoding for example).

VP and GP are connected by the MIXBUF, but GP and EP are entirely independent, and no special-purpose memory area connects them.
Therefore, the communication between the GP and EP typically happens through programmable DMA transfers (via FIFO or scratch memory).

The GP and EP are based on the same DSP architecture, run at the same clockrate, and have the same functionality (the EP has less memory, and no direct access to the MIXBUF). So, theoretically, nothing prevents the GP from doing EP tasks or vice versa{{FIXME|reason=I have not seen counter-arguments}}.

The APU does only audio-processing but no audio output. Hence, one of the DSPs typically uses programmable DMA to transfer the finished audio to system memory, where it can be read by other components (such as AC97).

All audio processing by the APU is typically done in 24bit PCM at 48000Hz.
An APU audio frame is 32 samples long. Therefore, there are 1500 frames per second, with a duration of 0.{{overline|6}}ms each.
The MIXBUF holds 1024 samples (32 channels * 32 samples/channel).

=== Glossary ===

* PRD = Physical Resource Descriptor (Same thing as SGE?!)
* SGE = Scatter Gather Entry
* SSL = Stream Segment List

== Frontend Engine (FE) ==

== Voice Processor (VP) ==

A powerful voice processor. There can be up to 256 voices [http://www.gamasutra.com/blogs/BrianSchmidt/20111117/90625/Designing_the_Boot_Sound_for_the_Original_Xbox.php][https://web.archive.org/web/20010410003338/http://www.nvnews.net/previews/mcpx/mcpx.shtml] and 64[http://www.nvidia.com/object/IO_20010530_6177.html] of those can be 3D.

Per-voice settings:
* Input type (8bit, 16bit, 24bit, ADPCM)
* 8 target bins, each with controllable volume for this voice
* [[wikipedia:Head-related transfer function|Head-related transfer function]] (HRTF)
* [[wikipedia:Low-frequency oscillation|Low-frequency oscillation]] (LFO)
* Pitch (~187.5 Hz to ~12285920.7 Hz)
* Optionally one of the following filters modes:
** For 2D Mono:
*** DLS2 Low-Pass
*** Parametric Equalizer
*** DLS2 Low-Pass + Parametric Equalizer
** For 2D Stereo:
*** DLS2 Low-Pass
*** Parametric Equalizer
** For 3D:
*** DLS2 Low-Pass + I3DL2 Reverb
*** Parametric Equalizer + I3DL2 Reverb
*** I3DL2 Reverb
* 2 Envelopes (DAHDSR: Delay, Attack, Hold, Decay, Sustain, Release)
** Amplitude Envelope
** Pitch / DLS2 Low-Pass Cutoff Envelope
* Tracking of certain parameters
** Volume
** LFO parameters
** DLS2 Low-Pass parameters?{{FIXME|reason=Not 100% sure, also not sure if this also works for the other filters}}

There are 32 bins which these voices will be mixed into.

=== Related APU memory ===

* VPV = VP Voices
* VPHT = VP HRTF Target
* VPHC = VP HRTF Current
* VPSGE = VP SGEs
* VPSSL = VP SSLs

=== Voice lists ===

The voices are kept in a single-linked list. There are 3 voice lists:

* 2D
* 3D
* MP (Multipass?)

=== Voice structure ===

This is 0x80 bytes

==== Pitch calculation ====

The 16 bit signed pitch value (''p'') can be converted to and from a unsigned frequency in Hz (''f'') using the following formulas:

<pre>
p = 4096 * log2(f / 48000)
f = pow2(p / 4096) * 48000
</pre>

=== LFO ===

=== Tracking ===

Some of the parameters of the VP can be controlled by setting timing parameters.
New values will then be slowly be adapted over time.
{{FIXME}}

=== Envelopes ===

There are seperate segments of the envelopes, 2 registers (CUR and COUNT) per envelope keeps track of this and control the envelopes level (LVL):

* 0: Off = Envelope is not used
* 1: Delay = Time where envelope stays at 0% until attack
** COUNT register counts down from DELAYTIME.
* 2: Attack = Rate at which the envelope goes from 0 to 100%
** COUNT register counts up to ATTACKRATE.
** LVL seems to be linear.
* 3: Hold = Time the envelope stays at 100%
** COUNT register counts down from HOLDTIME.
* 4: Decay = Rate at which the envelope goes from 100% to 0%
** COUNT register counts down from DECAYRATE.
** The LVL is not linear, it's a curve which drops steep at first and then slowly becomes level[https://docs.google.com/spreadsheets/d/1fNsfkvBfnlRQ9XplNnTgmh8jBaWJ56bvh2AVWn8B_k0/edit?usp=sharing]
** The best approximation I could come up with so far is: <code>255*pow(0.99988799,(DECAYRATE*16-COUNT)*4096/DECAYRATE)</code>.
** When the output level (not LVL!) reaches the sustain level the decay section is over (In my example above, this happens when the output level is less than 0.2 away from the sustain level; so if sustain is 0, the voice would switch to the sustain segment when a value below 0.2 is reached)
** Writes to the LVL register are ignored
** Writes to count (any value?) impact the LVL
** If the COUNT is larger than the decayrate the envelope will switch to the sustain state
** If the COUNT results in a smaller output level than the sustainlevel the envelope will switch to the sustain state
* 5: Sustain = Level at which the envelope stays while the voice is being played
** COUNT register writes are ignored, it will stay at 0
** LVL register writes are ignored, it will stay at the current sustain level
* 6: Release = Rate at which the envelope goes from current level to 0%
** Can start at any time{{FIXME|reason=the voice state PERSIST has to do with this. Voice is released using NV1BA0_PIO_VOICE_RELEASE ?}}
** COUNT register starts at RELEASERATE, regardless of the current sustain level
** COUNT register counts down{{FIXME|reason=What happens when it reaches 0? DirectSound seems to turn off voice - or is the hw doing that?}}
** LVL is not updated during this phase (it will keep it's previous value)
** Writes to LVL have an impact on the output volume
** If the COUNT register is higher than the releaserate, the output will be silent and LVL will drop to zero
** The actual output level is probably determined like: <code>int(COUNT * LVL / (RELEASERATE * 16))</code>{{FIXME|reason=Test..}}{{FIXME|reason=Unknown output shape}}
** COUNT will keep counting until 0 even after the output level has hit 0
* 7: Force Release = Unknown still{{FIXME}}
** Seems to happen during invalid conditions? Happened to me when modifying ebo during playback{{citation needed|reason=Need to find out why this happens}}
** LVL and COUNT seem to be ignored during this, but writes go through? Output level seems to stay at 100% ? (I only got repeating 32 samples during this and the whole Xbox crashed shortly after)

All durations are described using unsigned 12-bit times/rates. The level of sustain is stored unsigned in 8-bit.
The COUNT register is stored in unsigned 16-bit.

The 12-bit times/rates are multiplied by 16 when loading them into the 16-bit COUNT register.
The COUNT register counts at 1500 Hz[https://docs.google.com/spreadsheets/d/11jxeJ9aey_TVkyiMmmd6SKuow4j4GR9E9fRZ6HXc2WU/edit#gid=396423867].
A unit in the COUNT register is therefore 0.{{overline|6}} ms.

The 12-bit values of the envelope sections are given in units of 0.{{overline|6}} ms * 16 = 10.{{overline|6}} ms.
This can also be written as 512 / (48000 Hz) = 10.{{overline|6}} ms.
The maximum length of an envelope section is therefore 4095 * 10.{{overline|6}} ms = 43.68 seconds.

As the envelope counter runs at a fixed clock speed, it is independent of the voice pitch and duration.

If the Amplitude Envelope COUNT hits 0 during release, DirectSound{{FIXME|reason=Is this a hardware thing? I guess it makes sense..}} already deletes the voice, regardless of the Filter Envelope.

The sustain level can be changed during playback.
Also the attack register can be changed to a lower value while the counter is counting up, however, if the COUNTER does not compare equal to the set value, it will keep counting, even after an overflow. It will not leave the attack phase and keep counting until it sees value COUNTER / 16 in the attack register. If the attack register is set to a higher value while counting, the volume is going down again.
Also, if the attack register value is zero while counting, there won't be any audio output during the attack phase.
This indicates that the COUNT register is used to calculate the actual value from the current rates.

The initial state of each envelope can be controlled by the NV1BA0_PIO_VOICE_ON command. It can either be: DISABLE, DELAY, ATTACK or HOLD.

==== Amplitude Envelope ====

The amplitude envelope is mixed with the volume during mixing. The volume registers are not modified.
{{FIXME|reason=Is it multiplied on? Is it added? subtracted?}}
It is not yet known how many bits of the envelope state are used.

==== Filter Envelope ====

{{FIXME|reason=Research}}

The pitch scale is multiplied with the current envelope state and added to the current pitch during mixing. The pitch registers are not modified.

<pre>
f = 2^((signed_pitch+signed_pitch_mod*32*envelope_state_float)/4096)*48000 # envelope_state_float: [0, 1]
</pre>

It is not yet known how many bits of the envelope state are used.

=== Filters ===

==== DLS2 ====

Formulas from DirectSound

<pre>
FreqToHardwareCoeff(frequency): # Input in Hz
if (frequency < 30) { return 0x8000 }
if (frequency > 8000) { return 0x0000 }
FC = 2 * sin(PI * frequency / 48000)
octaves = 4096 * log2(FC)
return octaves & 0xFFFF
hardware_coefficient[0] = FreqToHardwareCoeff(frequency)
</pre>

<pre>
dBToHardwareCoeff(resonance): # Input in dB
resonance = min(resonance, 22.5)
Q = pow(10, -0.05 * resonance)
return min(0xFFFF)
hardware_coefficient[1] = dBToHardwareCoeff(resonance_in_db)
</pre>

Stuff from the DLS2 spec:{{FIXME|reason=Untested / unconfirmed. Most info comes from Merry of Citra}}

There are 2 coeffiecents per channel:

* F_c (Cutoff frequency)
* resonance

From Page 8 of "DLS 2.2 Version 1.0"[https://www.midi.org/specifications/item/dls-level-2-specification]

* b_1 = -2 * r * cos(θ)
* b_2 = r * r
* K = g * (1 + b_1 + b_2)

<pre>
y[i] = K * x[i] - b_1 * y[i-1] - b_2 * y[i-2]
</pre>

Where y[i-2] and y[i-1] are the last two frames of the output and x[i] the current input.

=== Operation ===

Voices are stored in VPV.
Input data (from the CPU) is loaded using VPSGE.
Voices are then processed and written to the GP MIXBUF.

== Global Processor (GP) ==

The GP is a DSP to do programmable audio processing on the voice bins.

The GP DSP seems to run at 160 MHz.

=== MIXBUF ===

The MIXBUF is a 0x400 word (24-Bit, stored as 32-Bit) section. It is split into 32 * 0x20 words.
Each 0x20 word block represents one of the 32 voice bins of the VP.
The 0x20 words are 24-Bit PCM mono samples to be played back at 48kHz. The duration of each frame is hence 0.{{overline|6}}ms.

=== Memory map ===

=== Related APU memory ===

* GPS = GP Scratch (?)
* GPF = GP FIFO

== Encode Processor (EP) ==

The EP is a DSP to encode the audio signal.

=== Memory map ===

=== Related APU memory ===

* EPS = EP Scratch (?)
* EPF = EP FIFO

== Usage in DirectSound ==

''This topic deserves it's own article{{FIXME}}''

The bins are used {{FIXME|reason=How?}}
DirectSound allows to load custom GP DSP code for a filter / effects chain.
{{FIXME|reaon=Will GP DSP automatically download code or is code pushed to it?}}
The GP waits for the frame interrupt which signals that MIXBUF data is available. It then goes through the filter chain.
At the end of the chain, the GP DSP will verify that the execution didn't take longer than the frame duration.

The GP will then issue 6 DMA requests to output the processed frames to a ringbuffer in scratch space.
The frameformat will be the same format as the GP MIXBUF format (also 0x20 words per channel).
Each ringbuffer is 0x200 words and therefore holds the last 16 frames.
Therefore, the ringbuffer region is 6 * 0x800 Bytes = 0x3000 Bytes in physical memory.

The order of the channels in the ringbuffer is (also DMA order):

* 0: Front Left
* 1: Center{{citation needed}}
* 2: Front Right
* 3: Rear Left{{citation needed}}
* 4: Rear Right{{citation needed}}
* 5: [[Wikipedia:Low-frequency effects|Low-frequency effects]] (LFE){{citation needed}}

The EP maps the same data to its own scratch space. It is assumed that it will DMA this region to its own internal memory.
The EP then AC3 encodes the audio data{{citation needed}} and writes it to the EP FIFO memory{{FIXME|How does this happen? DMA?}}.
{{FIXME|reason=When does this happen and what happens to stereo? headphones? mono?}}
The data is then send to the ACI AC97 using EP FIFO channels 0 (PCM) and 1 (SPDIF){{citation needed}}.
The EP code is loaded by DirectSound. The EP is not programmable using DirectSound APIs.

=== Modifications for Boot Animation ===

During the [[Boot Animation]] a different version of DirectSound is used.
The EP is disabled in this case.
The data is send to the ACI AC97 using GP FIFO channel 0 (PCM).
There is no AC3 / SPDIF during the boot animation[https://web.archive.org/web/20190123092902/http://www.gamasutra.com/blogs/BrianSchmidt/20111117/90625/Designing_the_Boot_Sound_for_the_Original_Xbox.php]{{citation needed|reason=Link to brians gamasutra stuff}}.

== Related notes ==

* [[ACI]]
* [[DSP]]
* [[Xbox ADPCM]]
* [http://www.nvidia.com/object/apu.html Information at NVIDIAs website]
* [http://www.nvidia.com/attach/9004 "Technical Brief: NVIDIA nForce MCP Audio Processing Unit" by NVIDIA]
* [https://github.com/JayFoxRox/xbox-tools/blob/master/python-scripts/ Scripts to inspect APU registers and voice buffers]
* Filter information
** [https://de.mathworks.com/help/audio/examples/parametric-equalizer-design.html Something about Parametric Equalizers]
** [https://github.com/kcat/openal-soft/blob/master/Alc/effects/reverb.c Mentions I3DL2 Reverb]
** [https://www.midi.org/specifications/item/dls-level-2-specification DLS2 low-pass filter with resonance and dynamic filter cutoff frequency]

[[Category:APU]]

CPU

2024-01-02T00:37:19Z

Thrimbor: Add links to the Intel Technology Journal talking about the P3

The CPU in the Xbox was a custom Pentium III running at 733MHz. The 'custom' part of this was that the Pentium III in the Xbox only had a 128KB L2 cache instead of the usual 256KB. This allowed Microsoft to buy them at a bit of a discount and Intel to shift a few more CPUs{{citation needed}}.

== References ==

* [http://www.intel.com/content/dam/support/us/en/documents/processors/mobile/celeron/sb/28365403.pdf Mobile Intel® Celeron® Processor (0.18μ) in BGA2 and Micro-PGA2 Packages] This datasheet is for the mobile version Coppermine with 256kB L2 cache. It does not contain the Xbox Coppermine-128 with 128kB L2 cache at 733MHz (S-Spec SL5SN). No such datasheet exists. Both differences are pin compatible.
* [https://www.intel.com/content/dam/support/us/en/documents/processors/mobile/celeron/sb/24542154.pdf Mobile Intel® Celeron® Processor (0.18μ and 0.13μ) Specification Update] This document should contain the errata for the Xbox CPU.
* [https://en.wikipedia.org/wiki/List_of_Intel_Pentium_III_microprocessors#"Coppermine"_(180_nm) Wikipedia - List of Intel Pentium III microprocessors: "Coppermine" (180 nm)]
* [https://www.google.com/patents/US20050282621 CPU upgrading adapter for a Microsoft XboxTM game machine] US Patent Application 20050282621 by Friendtech, filed 2003-08-21.

Articles from the Intel Technology Journal about the Pentium III architecture:
* [https://web.archive.org/web/20000815203117/http://developer.intel.com/technology/itj/q21999.htm Intel Technology Journal Q2 1999]
* [https://web.archive.org/web/20001006215908/http://developer.intel.com/technology/itj/q21999/pdf/simd_ext.pdf The Internet Streaming SIMD Extensions]
* [https://web.archive.org/web/20031104144423/http://developer.intel.com/technology/itj/q21999/pdf/impliment.pdf Pentium III Processor Implementation Tradeoffs]
* [https://web.archive.org/web/20001006220034/http://developer.intel.com/technology/itj/q21999/pdf/serial_number.pdf Pentium III Processor Serial Number Feature and Applications]
* [https://web.archive.org/web/20001006220114/http://developer.intel.com/technology/itj/q21999/pdf/3d_stack.pdf Architecture of a 3D Software Stack for Peak Pentium III Processor Performance]
* [https://web.archive.org/web/20001006220154/http://developer.intel.com/technology/itj/q21999/pdf/apps_simd.pdf Applications Tuning for Streaming SIMD Extensions]
* [https://web.archive.org/web/20030331192409/http://developer.intel.com/technology/itj/Q21999/pdf/vtune.pdf Programming Methods for the Pentium® III Processor’s Streaming SIMD Extensions Using the VTune Performance Enhancement Environment]

Resources

2023-10-25T14:06:04Z

Thrimbor: Fix dead links

== Xbox Post-Mortems by developers ==

=== Xbox Launch ===

* GDC2002: [https://www.powershow.com/download/6f1ff7-NmE2O/Xbox_Launch_Lessons_Learned_powerpoint_ppt_presentation Xbox Launch: Lessons Learned] ([https://www.gdcvault.com/play/1022522/Xbox-Launch-Lessons Audio])

=== Post processing ===

* CEDEC2002: [https://web.archive.org/web/20031212044938/http://www.daionet.gr.jp/~masa/column/2002-09-22.html DOUBLE-S.T.E.A.L techniques] ''(Japanese)''
* GDC2003: [https://web.archive.org/web/20031212140633/http://www.daionet.gr.jp/~masa/column/2003-03-21.html Frame Buffer Postprocessing Effects in DOUBLE-S.T.E.A.L (Wreckless)] ''(English)''

=== HDR rendering ===

* GDC2004: [https://web.archive.org/web/20060404103630/http://www.daionet.gr.jp/~masa/column/2004-04-04.html Practical Implementation of High Dynamic Range Rendering]

=== Deferred Shading ===

* https://web.archive.org/web/20201024153643/https://sites.google.com/site/richgel99/index#TOC-Shrek-Xbox-and-Deferred-Shading
* https://web.archive.org/web/20201024153427/https://sites.google.com/site/richgel99/home
* https://web.archive.org/web/20201123202956/https://sites.google.com/site/richgel99/home/xbox-1-g-buffer-attribute-packing-pixel-shader
* https://web.archive.org/web/20171008031141/http://www.tenacioussoftware.com/gdc_2004_deferred_shading.ppt

== Random resources about Xbox hacking ==
* [https://events.ccc.de/congress/2005/fahrplan/attachments/591-paper_xbox.pdf Michael Steils Xbox Presentation from C3 in 2005]
* https://media.ccc.de/v/19C3-399-xbox-linux
* https://media.ccc.de/v/22C3-559-en-xbox_hacking
* https://www.youtube.com/watch?v=6fOjGLCctEY
* [http://www.bunniestudios.com/bunnie/proj/anatak/xboxmod.html Bunnies original Xbox page]
* [https://www.nostarch.com/xboxfree Bunnies "Hacking the Xbox" e-book for free]
* [http://web.archive.org/web/20010417064218/ddj.com/articles/2000/0008/0008a/0008a.htm?topic=graphics Article about Xbox Graphics (before release) from Dr. Dobbs]
* [http://www.anandtech.com/show/853 Technical article about the Xbox by AnandTech]
* [https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20video%20and%20slides/DEF%20CON%2030%20-%20Tristan%20Miller%20-%20Reversing%20the%20Original%20Xbox%20Live%20Protocols.mp4 Reversing the Original Xbox Live Protocols] presented by [[User:monocasa]] at DEF CON 30 (2022)

== History ==
* [https://www.youtube.com/watch?v=rUODlNffWmU 3 Xbox Bosses Share Secrets of the Console's Past (Video)]
* [https://www.youtube.com/watch?v=iWQb7LGH71s Xbox Assembly Line Tour (Video)]
* [https://www.youtube.com/watch?v=_gOoI57q72M XBox Oral History Panel with Nick Baker, Todd Holmdahl, and Albert Penello (Video)]
* [https://www.youtube.com/watch?v=2VCb-y7MC5U?t=1248 Behind the Code - Interview with Nick Baker (Video) intresting xbox part starts 20:48]

== Background knowledge about related topics ==

=== Graphics programming ===

* Meltdown 2001 (Microsoft Game development conference): [https://web.archive.org/web/20060203201117/https://www.microsoft.com/mscorp/corpevents/meltdown2001/presentations.asp Presentation slides]
* GDC2001: [http://developer.download.nvidia.com/assets/gamedev/docs/GDC2K1_DX8_Pixel_Shaders.pdf DirectX8 Pixel Shaders]
* [https://web.archive.org/web/20200130052343/http://download.nvidia.com/developer/Papers/ Papers by nvidia from Xbox era]
* [https://web.archive.org/web/20191214222749/http://download.nvidia.com/developer/presentations/ Presentation slides by nvidia from Xbox era]
* [https://web.archive.org/web/20200130053050/http://download.nvidia.com/developer/movies/ Presentation recordings by nvidia from Xbox era]
* [https://web.archive.org/web/20191214215356/http://download.nvidia.com/developer/NVTextureSuite/ Texturing tools by nvidia from Xbox era]
* [https://web.archive.org/web/20191214215706/http://download.nvidia.com/developer/Tools/ Tools by nvidia from Xbox era]
* https://web.archive.org/web/20191214215240/http://download.nvidia.com/developer/Third_Party/
* http://iquilezles.org/www/index.htm
* https://web.archive.org/web/20150408045127/http://freespace.virgin.net/hugo.elias/
* http://www.mvps.org/directx/indexes/
* https://www.gdcvault.com/play/247/CRYSIS-Next-Gen ''(Contains some parts which are also applicable to original Xbox)''
* [https://www.valvesoftware.com/en/publications Publications by Valve Software]
* http://graphics.uni-konstanz.de/publikationen/Luft2006ImageEnhancementUnsharp/Luft2006ImageEnhancementUnsharp.pdf
* [https://web.archive.org/web/20090518092325/http://www.daionet.gr.jp:80/~masa/column/index.html Masa's Column (DOUBLE-S.T.E.A.L / Wrecked developer)]
* [https://fgiesen.wordpress.com/ Blog by ryg]
* [http://filmicworlds.com/blog/ Filmic Worlds]
* [https://web.archive.org/web/20191208134031/https://gpuopen.com/archive/gamescgi/cubemapgen/ AMD CubeMapGen tool for mipmapping cubemaps]

Xbe

2022-07-30T17:52:20Z

Thrimbor: "Standard Windows format" is actually a UNIX timestamp

{{DISPLAYTITLE:XBE}}
XBE files (XBox Executable) are the main files that are executed in the Xbox System. In official games, these files are created by game developers, and then signed by Microsoft.

The file structure is adapted from Windows PE files. It is very similar, however it has important changes for the Xbox. The file is composed of an image header, a certificate, a collection of section headers, a collection of library versions, thread local storage data, a Microsoft bitmap, and the sections that contain the code and resources.

= Image Header =

The image header contains the information that describes where the other parts of the executable are located within the file, and how the executable should be treated and loaded. It has the following layout (all fields are little-endian):

{| class="wikitable
|-
! Offset
! Size
! Name
! Description
|-
! 0x0000
! 0x0004
| Magic Number
| This field must always equal 0x48454258 ("XBEH")
|-
! 0x0004
! 0x0100
| Digital Signature
| 256 Bytes. This is where a game is signed. Only on officially signed games is this field worthwhile.
|-
! 0x0104
! 0x0004
| Base Address
| Address at which to load this .XBE. Typically this will be 0x00010000.
|-
! 0x0108
! 0x0004
| Size of Headers
| Number of bytes that should be reserved for headers.
|-
! 0x010C
! 0x0004
| Size of Image
| Number of bytes that should be reserved for this image.
|-
! 0x0110
! 0x0004
| Size of Image Header
| Number of bytes that should be reserved for the image header. The header size varies by XDK version, but is at least 0x178.
|-
! 0x0114
! 0x0004
| TimeDate
| Time and Date when this image was created. UNIX timestamp format.
|-
! 0x0118
! 0x0004
| Certificate Address
| Address to a [[#Certificate|Certificate]] structure, after the .XBE is loaded into memory.
|-
! 0x011C
! 0x0004
| Number of Sections
| Number of sections contained in this .XBE.
|-
! 0x0120
! 0x0004
| Section Headers Address
| Address to an array of SectionHeader structures, after the .XBE is loaded into memory.
|-
! 0x0124
! 0x0004
| Initialization Flags
| Various flags for this .XBE file. Known flags are:

MountUtilityDrive = 0x00000001
FormatUtilityDrive = 0x00000002
Limit64Megabytes = 0x00000004
DontSetupHarddisk = 0x00000008
|-
! 0x0128
! 0x0004
| Entry Point
| Address to the Image entry point, after the .XBE is loaded into memory. This is where execution starts.

This value is encoded with an XOR key. Considering this is far too weak to be considered security, I assume this XOR is a clever method for discerning between Debug/Retail .XBE files without adding another field to the .XBE header. The XOR key is dependant on the build:

Beta = 0xE682F45B, Debug = 0x94859D4B, Retail = 0xA8FC57AB

To encode an entry point, you simply XOR the real entry point with either Debug or Retail key, depending on if you want the XBox to see this as a Debug or Retail executable.

To decode an entry point, you XOR with the debug key, then check if it is a valid entry point. If it is not, then you try again with the retail key.

Note: The Kernel Image Thunk Address member of this header must also be encoded as described later in this document.
|-
! 0x012C
! 0x0004
| TLS Address
| Address to a [[#TLS Table|TLS]] (Thread Local Storage) structure.
|-
! 0x0130
! 0x0004
| Stack Size
| Default stack size. As the Xbox does not allow for stacks to grow, this needs to be copied from the SizeOfStackReserve PE field, not SizeOfStackCommit!
|-
! 0x0134
! 0x0004
| PE Heap Reserve
| Copied from the PE file this .XBE was created from.
|-
! 0x0138
! 0x0004
| PE Heap Commit
| Copied from the PE file this .XBE was created from.
|-
! 0x013C
! 0x0004
| PE Base Address
| Copied from the PE file this .XBE was created from.
|-
! 0x0140
! 0x0004
| PE Size of Image
| Copied from the PE file this .XBE was created from.
|-
! 0x0144
! 0x0004
| PE Checksum
| Copied from the PE file this .XBE was created from.
|-
! 0x0148
! 0x0004
| PE TimeDate
| Copied from the PE file this .XBE was created from (UNIX timestamp format).
|-
! 0x014C
! 0x0004
| Debug PathName Address
| Address to the debug pathname (i.e. "D:\Nightlybuilds\011026.0\code\build\xbox\Release\simpsons.exe").
|-
! 0x0150
! 0x0004
| Debug FileName Address
| Address to the debug filename (i.e. "simpsons.exe")
|-
! 0x0154
! 0x0004
| Address to the UTF-16 debug filename (i.e. L"simpsons.exe")
| UTF-16 Debug FileName Address
|-
! 0x0158
! 0x0004
| Kernel Image Thunk Address
| Address to the Kernel Image Thunk Table, after the .XBE is loaded into memory. This is how .XBE files import kernel functions and data.

This value is encoded with an XOR key. Considering this is far too weak to be considered security, I assume this XOR is a clever method for discerning between Debug/Retail .XBE files without adding another field to the .XBE header. The XOR key is dependant on the build:

Beta = 0x46437DCD, Debug = 0xEFB1F152, Retail = 0x5B6D40B6

To encode a kernel thunk address, you simply XOR the real address with either Debug or Retail key, depending on if you want the XBox to see this as a Debug or Retail executable.

To decode a kernel thunk address, you XOR with the debug key, then check if it is a valid address. If it is not, then you try again with the retail key.

The Kernel Thunk Table itself is simply an array of pointers to Kernel imports. There are 366 possible imports, and the table is terminated with a zero dword (0x00000000). Typically the values in this table can be generated with the following formula:

KernelThunkTable[v] = ImportThunk + 0x80000000;

so, for example, the import PsCreateSystemThreadEx, which has a thunk value of 255 (0xFF) would be...

KernelThunkTable[v] = 0xFF + 0x80000000; // (0x800000FF)

When the .XBE is loaded by the OS (or the CXBX Emulator), all kernel imports are replaced by a valid function or data type address. In the case of CXBX, the import table entry at which (KernelThunkTable[v] & 0x1FF == 0xFF) will be replaced by &cxbx_PsCreateSystemThreadEx (which is a wrapper function).

Note: The Entry Point member of this header must also be encoded as described earlier in this document.
|-
! 0x015C
! 0x0004
| Non-Kernel Import Directory Address
| Address to the Non-Kernel Import Directory. It is typically safe to set this to zero.
|-
! 0x0160
! 0x0004
| Number of Library Versions
| Number of Library Versions pointed to by Library Versions Address.
|-
! 0x0164
! 0x0004
| Library Versions Address
| Address to an array of LibraryVersion structures, after the .XBE is loaded into memory.
|-
! 0x0168
! 0x0004
| Kernel Library Version Address
| Address to a LibraryVersion structure, after the .XBE is loaded into memory.
|-
! 0x016C
! 0x0004
| XAPI Library Version Address
| Address to a LibraryVersion structure, after the .XBE is loaded into memory.
|-
! 0x0170
! 0x0004
| Logo Bitmap Address
| Address to the Logo Bitmap (Typically a "Microsoft" logo). The format of this image is described here. This field can be set to zero, meaning there is no bitmap present.
|-
! 0x0174
! 0x0004
| Logo Bitmap Size
| Size (in bytes) of the Logo Bitmap data. The format of this image is described here.
|-
! 0x0178
! 0x0008
| Unknown1
| The meaning of this field hasn't been figured out yet. It only exists on XBEs built with an XDK version >= 5028.
|-
! 0x0180
! 0x0004
| Unknown2
| The meaning of this field hasn't been figured out yet. It only exists on XBEs built with an XDK version >= 5455.
|}

== LibraryVersion Table ==
{| class="wikitable
|-
! Offset
! Size
! Name
! Description
|-
! 0x0000
! 0x0008
| Library Name
| 8-byte ASCII-name of this library. (i.e. "XAPILIB")
|-
! 0x0008
! 0x0002
| Major Version
| Major version for this library (2-byte WORD).
|-
! 0x000A
! 0x0002
| Minor Version
| Minor version for this library (2-byte WORD).
|-
! 0x000C
! 0x0002
| Build Version
| Build version for this library (2-byte WORD).
|-
! 0x000E
! 0x0002
| Library Flags
| Various flags for this library. The fields are:

QFEVersion = 0x1FFF (13-Bit Mask)
Approved = 0x6000 (02-Bit Mask)
Debug Build = 0x8000 (01-Bit Mask)
|}

== TLS Table ==

The TLS Table contains all the information needed by the XBE to properly set up thread-local storage. It is structurally identical to the TLS Directory found in PE32 files<ref>https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-tls-section</ref>, and can be directly copied from there. If the XBE does not use any thread-local storage, this table may be omitted, and the respective field in the image header set to zero.

{| class="wikitable
|-
! Offset
! Size
! Name
! Description
|-
! 0x0000
! 0x0004
| Raw Data Start
| Absolute (i.e. not an RVA) address of start of the TLS variable data in the program image.
|-
! 0x0004
! 0x0004
| Raw Data End
| Absolute (i.e. not an RVA) address of end of the TLS variable data in the program image.
|-
! 0x0008
! 0x0004
| Address of Index
| Absolute (i.e. not an RVA) address of the TLS Index variable.
|-
! 0x000C
! 0x0004
| Address of Callbacks
| Absolute (i.e. not an RVA) address of the null-terminated TLS callback functions table.
|-
! 0x0010
! 0x0004
| Size of Zero Fill
| The number of bytes following the raw data that should be set to zero in memory.
|-
! 0x0014
! 0x0004
| Characteristics
| Describes alignment.
|}

= Certificate =

Each Xbox executable has a certificate that contains information about the title.

* Time and date when the certificate was created
* Title ID
* Title name
* Alternative title IDs
* Allowed types of media that the executable can be run from (HD, DVD, CD, etc.)
* Game region
* Game ratings
* Disk number
* Version
* LAN key raw data used for [[System Link]]
* Signature key raw data (used to sign [[Xbox Savegame System|savegames]])
* Alternate signature keys
* Original size of the certificate
* Online service name (not present in early executables)
* Run time security flags (not present in early executables)

=== Title ID ===

A title ID is usually 2 ASCII letters for the publisher, followed by a u16 integer game number (Above 2000 for non-original Xbox games)

{| class=wikitable
! Publisher ID !! Name
|-
| AC || Acclaim Entertainment
|-
| AH || ARUSH Entertainment
|-
| AQ || Aqua System
|-
| AS || ASK
|-
| AT || Atlus
|-
| AV || Activision
|-
| AY || Aspyr Media
|-
| BA || Bandai
|-
| BL || Black Box
|-
| BM || BAM! Entertainment
|-
| BR || Broccoli Co.
|-
| BS || Bethesda Softworks
|-
| BU || Bunkasha Co.
|-
| BV || Buena Vista Games
|-
| BW || BBC Multimedia
|-
| BZ || Blizzard
|-
| CC || Capcom
|-
| CK || Kemco Corporation {{citation needed|reason=Did they realy swapped the ASCII letters? is KC a curced acroniem in Japan? Just want to be sure its Kemco|date=May 2017}}
|-
| CM || Codemasters
|-
| CV || Crave Entertainment
|-
| DC || DreamCatcher Interactive
|-
| DX || Davilex
|-
| EA || Electronic Arts (EA)
|-
| EC || Encore inc
|-
| EL || Enlight Software
|-
| EM || Empire Interactive
|-
| ES || Eidos Interactive
|-
| FI || Fox Interactive
|-
| FS || From Software
|-
| GE || Genki Co.
|-
| GV || Groove Games
|-
| HE || Tru Blu (Entertainment division of Home Entertainment Suppliers)
|-
| HP || Hip games
|-
| HU || Hudson Soft
|-
| HW || Highwaystar
|-
| IA || Mad Catz Interactive
|-
| IF || Idea Factory
|-
| IG || Infogrames
|-
| IL || [[Interlex Corporation]]
|-
| IM || Imagine Media
|-
| IO || Ignition Entertainment
|-
| IP || Interplay Entertainment
|-
| IX || InXile Entertainment {{citation needed}}
|-
| JA || Jaleco
|-
| JW || JoWooD
|-
| KB || Kemco {{citation needed|reason=CK is also Kemco, is this a diferent subsidairy or country based? Just want to be sure its Kemco|date=May 2017}}
|-
| KI || Kids Station Inc. {{citation needed|reason=Games info page was in japanese, I dont read japanese. but this seemed very logicaly the publisher, can a japanese reader confirm?|date=May 2017}}
|-
| KN || Konami
|-
| KO || KOEI
|-
| KU || Kobi and/or GAE (formerly Global A Entertainment){{citation needed|reason=What name did the publisher use at the time of release?|date=May 2017}}
|-
| LA || LucasArts
|-
| LS || Black Bean Games (publishing arm of Leader S.p.A.)
|-
| MD || Metro3D
|-
| ME || Medix
|-
| MI || Microïds
|-
| MJ || Majesco Entertainment
|-
| MM || Myelin Media
|-
| MP || MediaQuest {{citation needed|reason=Where is the P? I dont trust my source yet... but seems close|date=May 2017}}
|-
| MS || Microsoft Game Studios
|-
| MW || Midway Games
|-
| MX || Empire Interactive {{citation needed|reason=What happend to the publisher, who published this game?|date=May 2017}}
|-
| NK || NewKidCo
|-
| NL || NovaLogic
|-
| NM || Namco
|-
| OX || Oxygen Interactive
|-
| PC || Playlogic Entertainment
|-
| PL || Phantagram Co., Ltd.
|-
| RA || Rage
|-
| SA || Sammy
|-
| SC || SCi Games
|-
| SE || SEGA
|-
| SN || SNK
|-
| SS || Simon & Schuster
|-
| SU || Success Corporation
|-
| SW || Swing! Deutschland
|-
| TA || Takara
|-
| TC || Tecmo
|-
| TD || The 3DO Company (or just 3DO)
|-
| TK || Takuyo
|-
| TM || TDK Mediactive
|-
| TQ || THQ
|-
| TS || Titus Interactive
|-
| TT || Take-Two Interactive Software
|-
| US || Ubisoft
|-
| VC || Victor Interactive Software
|-
| VN || Vivendi Universal (just took Interplays publishing rights) {{citation needed}}
|-
| VU || Vivendi Universal Games
|-
| VV || Vivendi Universal Games {{citation needed}}
|-
| WE || Wanadoo Edition
|-
| WR || Warner Bros. Interactive Entertainment {{citation needed}}
|-
| XI || XPEC Entertainment and Idea Factory
|-
| XK || ''Xbox kiosk disk?'' {{citation needed}}
|-
| XL || ''Xbox special bundled or live demo disk?'' {{citation needed}}
|-
| XM || Evolved Games {{citation needed|reason=Probably not, game "Malice"|date=May 2017}}
|-
| XP || XPEC Entertainment
|-
| XR || Panorama
|-
| YB || YBM Sisa (South-Korea)
|-
| ZD || Zushi Games (formerly Zoo Digital Publishing)
|}

The title ID seems to double the information from the [[Xbox Game Disc]] mastering code etched into the ring or readable from the DMI.
The game number is expressed in 3 decimal digits here which suggests that it will always be below 1000.

'''Examples''':

[[FIFA Soccer 2003]]:
* DMI and mastering code: EA02302E (Meaning: publisher EA, game number 023, version 02, region Europe)
* Title ID: {{FIXME}}

[[Halo: Combat Evolved]]:
* DMI and mastering code: MS00402A (Meaning: publisher Microsoft, game number 004, version 02, region America)
* Title ID: 4D530004 [MS-004]

[[Halo: Combat Evolved]]:
* DMI and mastering code: MS00404E (Meaning: publisher Microsoft, game number 004, version 04, region Europe)
* Title ID: 4D530004 [MS-004]

== Allowed media types ==
Allowed media types off which the executable is allowed to be run from. The following values are known:
{| class=wikitable
! Media type !! Value
|-
|HARD_DISK || 0x00000001
|-
|DVD_X2 || 0x00000002
|-
|DVD_CD || 0x00000004
|-
|CD || 0x00000008
|-
|DVD_5_RO || 0x00000010
|-
|DVD_9_RO || 0x00000020
|-
|DVD_5_RW || 0x00000040
|-
|DVD_9_RW || 0x00000080
|-
|DONGLE || 0x00000100
|-
|MEDIA_BOARD || 0x00000200
|-
|NONSECURE_HARD_DISK || 0x40000000
|-
|NONSECURE_MODE || 0x80000000
|-
|MEDIA_MASK || 0x00FFFFFF
|}

= Sections =
The sections are described by the section headers. The section headers start right after the certificate and contain describe where in the file the actual sections reside. Each header contains a hash of the section that is checked by the Xbox to ensure the integrity of the sections.

At least two sections are always present in an Xbox executable: .text and .rdata. There might be more sections that contain either executable code or resources such as images, text, etc.

== .text ==

The .text section contains all x86 subroutines to be executed by the [[CPU|processor]].

== .rdata ==

The .rdata section contains the [[Kernel|kernel thunk table]]. The ordinals in the table are to be resolved to the kernel's actual calling routine, when loaded.

= Xbox Alpha executable format =

Binaries from early Xbox development (Alpha units), are using a different binary format. There are no known public tools that can read them.
Known differences include that the first bytes of the file are 'XE' instead the 'XBEH' from the final XBE format. The format is rumored to be more like the Windows PE format.{{citation needed}}

= Resources and links =
* [http://www.caustik.com/cxbx/download/xbe.htm .XBE File Format 1.1]

[[Category:Fileformats]]

Xbe

2021-10-06T17:13:26Z

Thrimbor: Add info about the LibraryVersion Table

{{DISPLAYTITLE:XBE}}
XBE files (XBox Executable) are the main files that are executed in the Xbox System. In official games, these files are created by game developers, and then signed by Microsoft.

The file structure is adapted from Windows PE files. It is very similar, however it has important changes for the Xbox. The file is composed of an image header, a certificate, a collection of section headers, a collection of library versions, thread local storage data, a Microsoft bitmap, and the sections that contain the code and resources.

= Image Header =

The image header contains the information that describes where the other parts of the executable are located within the file, and how the executable should be treated and loaded. It has the following layout (all fields are little-endian):

{| class="wikitable
|-
! Offset
! Size
! Name
! Description
|-
! 0x0000
! 0x0004
| Magic Number
| This field must always equal 0x48454258 ("XBEH")
|-
! 0x0004
! 0x0100
| Digital Signature
| 256 Bytes. This is where a game is signed. Only on officially signed games is this field worthwhile.
|-
! 0x0104
! 0x0004
| Base Address
| Address at which to load this .XBE. Typically this will be 0x00010000.
|-
! 0x0108
! 0x0004
| Size of Headers
| Number of bytes that should be reserved for headers.
|-
! 0x010C
! 0x0004
| Size of Image
| Number of bytes that should be reserved for this image.
|-
! 0x0110
! 0x0004
| Size of Image Header
| Number of bytes that should be reserved for the image header. The header size varies by XDK version, but is at least 0x178.
|-
! 0x0114
! 0x0004
| TimeDate
| Time and Date when this image was created. Standard windows format.
|-
! 0x0118
! 0x0004
| Certificate Address
| Address to a [[#Certificate|Certificate]] structure, after the .XBE is loaded into memory.
|-
! 0x011C
! 0x0004
| Number of Sections
| Number of sections contained in this .XBE.
|-
! 0x0120
! 0x0004
| Section Headers Address
| Address to an array of SectionHeader structures, after the .XBE is loaded into memory.
|-
! 0x0124
! 0x0004
| Initialization Flags
| Various flags for this .XBE file. Known flags are:

MountUtilityDrive = 0x00000001
FormatUtilityDrive = 0x00000002
Limit64Megabytes = 0x00000004
DontSetupHarddisk = 0x00000008
|-
! 0x0128
! 0x0004
| Entry Point
| Address to the Image entry point, after the .XBE is loaded into memory. This is where execution starts.

This value is encoded with an XOR key. Considering this is far too weak to be considered security, I assume this XOR is a clever method for discerning between Debug/Retail .XBE files without adding another field to the .XBE header. The XOR key is dependant on the build:

Debug = 0x94859D4B, Retail = 0xA8FC57AB

To encode an entry point, you simply XOR the real entry point with either Debug or Retail key, depending on if you want the XBox to see this as a Debug or Retail executable.

To decode an entry point, you XOR with the debug key, then check if it is a valid entry point. If it is not, then you try again with the retail key.

Note: The Kernel Image Thunk Address member of this header must also be encoded as described later in this document.
|-
! 0x012C
! 0x0004
| TLS Address
| Address to a [[#TLS Table|TLS]] (Thread Local Storage) structure.
|-
! 0x0130
! 0x0004
| Stack Size
| Default stack size. As the Xbox does not allow for stacks to grow, this needs to be copied from the SizeOfStackReserve PE field, not SizeOfStackCommit!
|-
! 0x0134
! 0x0004
| PE Heap Reserve
| Copied from the PE file this .XBE was created from.
|-
! 0x0138
! 0x0004
| PE Heap Commit
| Copied from the PE file this .XBE was created from.
|-
! 0x013C
! 0x0004
| PE Base Address
| Copied from the PE file this .XBE was created from.
|-
! 0x0140
! 0x0004
| PE Size of Image
| Copied from the PE file this .XBE was created from.
|-
! 0x0144
! 0x0004
| PE Checksum
| Copied from the PE file this .XBE was created from.
|-
! 0x0148
! 0x0004
| PE TimeDate
| Copied from the PE file this .XBE was created from.
|-
! 0x014C
! 0x0004
| Debug PathName Address
| Address to the debug pathname (i.e. "D:\Nightlybuilds\011026.0\code\build\xbox\Release\simpsons.exe").
|-
! 0x0150
! 0x0004
| Debug FileName Address
| Address to the debug filename (i.e. "simpsons.exe")
|-
! 0x0154
! 0x0004
| Address to the UTF-16 debug filename (i.e. L"simpsons.exe")
| UTF-16 Debug FileName Address
|-
! 0x0158
! 0x0004
| Kernel Image Thunk Address
| Address to the Kernel Image Thunk Table, after the .XBE is loaded into memory. This is how .XBE files import kernel functions and data.

This value is encoded with an XOR key. Considering this is far too weak to be considered security, I assume this XOR is a clever method for discerning between Debug/Retail .XBE files without adding another field to the .XBE header. The XOR key is dependant on the build:

Debug = 0xEFB1F152, Retail = 0x5B6D40B6

To encode a kernel thunk address, you simply XOR the real address with either Debug or Retail key, depending on if you want the XBox to see this as a Debug or Retail executable.

To decode a kernel thunk address, you XOR with the debug key, then check if it is a valid address. If it is not, then you try again with the retail key.

The Kernel Thunk Table itself is simply an array of pointers to Kernel imports. There are 366 possible imports, and the table is terminated with a zero dword (0x00000000). Typically the values in this table can be generated with the following formula:

KernelThunkTable[v] = ImportThunk + 0x80000000;

so, for example, the import PsCreateSystemThreadEx, which has a thunk value of 255 (0xFF) would be...

KernelThunkTable[v] = 0xFF + 0x80000000; // (0x800000FF)

When the .XBE is loaded by the OS (or the CXBX Emulator), all kernel imports are replaced by a valid function or data type address. In the case of CXBX, the import table entry at which (KernelThunkTable[v] & 0x1FF == 0xFF) will be replaced by &cxbx_PsCreateSystemThreadEx (which is a wrapper function).

Note: The Entry Point member of this header must also be encoded as described earlier in this document.
|-
! 0x015C
! 0x0004
| Non-Kernel Import Directory Address
| Address to the Non-Kernel Import Directory. It is typically safe to set this to zero.
|-
! 0x0160
! 0x0004
| Number of Library Versions
| Number of Library Versions pointed to by Library Versions Address.
|-
! 0x0164
! 0x0004
| Library Versions Address
| Address to an array of LibraryVersion structures, after the .XBE is loaded into memory.
|-
! 0x0168
! 0x0004
| Kernel Library Version Address
| Address to a LibraryVersion structure, after the .XBE is loaded into memory.
|-
! 0x016C
! 0x0004
| XAPI Library Version Address
| Address to a LibraryVersion structure, after the .XBE is loaded into memory.
|-
! 0x0170
! 0x0004
| Logo Bitmap Address
| Address to the Logo Bitmap (Typically a "Microsoft" logo). The format of this image is described here. This field can be set to zero, meaning there is no bitmap present.
|-
! 0x0174
! 0x0004
| Logo Bitmap Size
| Size (in bytes) of the Logo Bitmap data. The format of this image is described here.
|-
! 0x0178
! 0x0008
| Unknown1
| The meaning of this field hasn't been figured out yet. It only exists on XBEs built with an XDK version >= 5028.
|-
! 0x0180
! 0x0004
| Unknown2
| The meaning of this field hasn't been figured out yet. It only exists on XBEs built with an XDK version >= 5455.
|}

== LibraryVersion Table ==
{| class="wikitable
|-
! Offset
! Size
! Name
! Description
|-
! 0x0000
! 0x0008
| Library Name
| 8-byte ASCII-name of this library. (i.e. "XAPILIB")
|-
! 0x0008
! 0x0002
| Major Version
| Major version for this library (2-byte WORD).
|-
! 0x000A
! 0x0002
| Minor Version
| Minor version for this library (2-byte WORD).
|-
! 0x000C
! 0x0002
| Build Version
| Build version for this library (2-byte WORD).
|-
! 0x000E
! 0x0002
| Library Flags
| Various flags for this library. The fields are:

QFEVersion = 0x1FFF (13-Bit Mask)
Approved = 0x6000 (02-Bit Mask)
Debug Build = 0x8000 (01-Bit Mask)
|}

== TLS Table ==

The TLS Table contains all the information needed by the XBE to properly set up thread-local storage. It is structurally identical to the TLS Directory found in PE32 files<ref>https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-tls-section</ref>, and can be directly copied from there. If the XBE does not use any thread-local storage, this table may be omitted, and the respective field in the image header set to zero.

{| class="wikitable
|-
! Offset
! Size
! Name
! Description
|-
! 0x0000
! 0x0004
| Raw Data Start
| Absolute (i.e. not an RVA) address of start of the TLS variable data in the program image.
|-
! 0x0004
! 0x0004
| Raw Data End
| Absolute (i.e. not an RVA) address of end of the TLS variable data in the program image.
|-
! 0x0008
! 0x0004
| Address of Index
| Absolute (i.e. not an RVA) address of the TLS Index variable.
|-
! 0x000C
! 0x0004
| Address of Callbacks
| Absolute (i.e. not an RVA) address of the null-terminated TLS callback functions table.
|-
! 0x0010
! 0x0004
| Size of Zero Fill
| The number of bytes following the raw data that should be set to zero in memory.
|-
! 0x0014
! 0x0004
| Characteristics
| Describes alignment.
|}

= Certificate =

Each Xbox executable has a certificate that contains information about the title.

* Time and date when the certificate was created
* Title ID
* Title name
* Alternative title IDs
* Allowed types of media that the executable can be run from (HD, DVD, CD, etc.)
* Game region
* Game ratings
* Disk number
* Version
* LAN key raw data used for [[System Link]]
* Signature key raw data (used to sign [[Xbox Savegame System|savegames]])
* Alternate signature keys
* Original size of the certificate
* Online service name (not present in early executables)
* Run time security flags (not present in early executables)

=== Title ID ===

A title ID is usually 2 ASCII letters for the publisher, followed by a u16 integer game number (Above 2000 for non-original Xbox games)

{| class=wikitable
! Publisher ID !! Name
|-
| AC || Acclaim Entertainment
|-
| AH || ARUSH Entertainment
|-
| AQ || Aqua System
|-
| AS || ASK
|-
| AT || Atlus
|-
| AV || Activision
|-
| AY || Aspyr Media
|-
| BA || Bandai
|-
| BL || Black Box
|-
| BM || BAM! Entertainment
|-
| BR || Broccoli Co.
|-
| BS || Bethesda Softworks
|-
| BU || Bunkasha Co.
|-
| BV || Buena Vista Games
|-
| BW || BBC Multimedia
|-
| BZ || Blizzard
|-
| CC || Capcom
|-
| CK || Kemco Corporation {{citation needed|reason=Did they realy swapped the ASCII letters? is KC a curced acroniem in Japan? Just want to be sure its Kemco|date=May 2017}}
|-
| CM || Codemasters
|-
| CV || Crave Entertainment
|-
| DC || DreamCatcher Interactive
|-
| DX || Davilex
|-
| EA || Electronic Arts (EA)
|-
| EC || Encore inc
|-
| EL || Enlight Software
|-
| EM || Empire Interactive
|-
| ES || Eidos Interactive
|-
| FI || Fox Interactive
|-
| FS || From Software
|-
| GE || Genki Co.
|-
| GV || Groove Games
|-
| HE || Tru Blu (Entertainment division of Home Entertainment Suppliers)
|-
| HP || Hip games
|-
| HU || Hudson Soft
|-
| HW || Highwaystar
|-
| IA || Mad Catz Interactive
|-
| IF || Idea Factory
|-
| IG || Infogrames
|-
| IL || [[Interlex Corporation]]
|-
| IM || Imagine Media
|-
| IO || Ignition Entertainment
|-
| IP || Interplay Entertainment
|-
| IX || InXile Entertainment {{citation needed}}
|-
| JA || Jaleco
|-
| JW || JoWooD
|-
| KB || Kemco {{citation needed|reason=CK is also Kemco, is this a diferent subsidairy or country based? Just want to be sure its Kemco|date=May 2017}}
|-
| KI || Kids Station Inc. {{citation needed|reason=Games info page was in japanese, I dont read japanese. but this seemed very logicaly the publisher, can a japanese reader confirm?|date=May 2017}}
|-
| KN || Konami
|-
| KO || KOEI
|-
| KU || Kobi and/or GAE (formerly Global A Entertainment){{citation needed|reason=What name did the publisher use at the time of release?|date=May 2017}}
|-
| LA || LucasArts
|-
| LS || Black Bean Games (publishing arm of Leader S.p.A.)
|-
| MD || Metro3D
|-
| ME || Medix
|-
| MI || Microïds
|-
| MJ || Majesco Entertainment
|-
| MM || Myelin Media
|-
| MP || MediaQuest {{citation needed|reason=Where is the P? I dont trust my source yet... but seems close|date=May 2017}}
|-
| MS || Microsoft Game Studios
|-
| MW || Midway Games
|-
| MX || Empire Interactive {{citation needed|reason=What happend to the publisher, who published this game?|date=May 2017}}
|-
| NK || NewKidCo
|-
| NL || NovaLogic
|-
| NM || Namco
|-
| OX || Oxygen Interactive
|-
| PC || Playlogic Entertainment
|-
| PL || Phantagram Co., Ltd.
|-
| RA || Rage
|-
| SA || Sammy
|-
| SC || SCi Games
|-
| SE || SEGA
|-
| SN || SNK
|-
| SS || Simon & Schuster
|-
| SU || Success Corporation
|-
| SW || Swing! Deutschland
|-
| TA || Takara
|-
| TC || Tecmo
|-
| TD || The 3DO Company (or just 3DO)
|-
| TK || Takuyo
|-
| TM || TDK Mediactive
|-
| TQ || THQ
|-
| TS || Titus Interactive
|-
| TT || Take-Two Interactive Software
|-
| US || Ubisoft
|-
| VC || Victor Interactive Software
|-
| VN || Vivendi Universal (just took Interplays publishing rights) {{citation needed}}
|-
| VU || Vivendi Universal Games
|-
| VV || Vivendi Universal Games {{citation needed}}
|-
| WE || Wanadoo Edition
|-
| WR || Warner Bros. Interactive Entertainment {{citation needed}}
|-
| XI || XPEC Entertainment and Idea Factory
|-
| XK || ''Xbox kiosk disk?'' {{citation needed}}
|-
| XL || ''Xbox special bundled or live demo disk?'' {{citation needed}}
|-
| XM || Evolved Games {{citation needed|reason=Probably not, game "Malice"|date=May 2017}}
|-
| XP || XPEC Entertainment
|-
| XR || Panorama
|-
| YB || YBM Sisa (South-Korea)
|-
| ZD || Zushi Games (formerly Zoo Digital Publishing)
|}

The title ID seems to double the information from the [[Xbox Game Disc]] mastering code etched into the ring or readable from the DMI.
The game number is expressed in 3 decimal digits here which suggests that it will always be below 1000.

'''Examples''':

[[FIFA Soccer 2003]]:
* DMI and mastering code: EA02302E (Meaning: publisher EA, game number 023, version 02, region Europe)
* Title ID: {{FIXME}}

[[Halo: Combat Evolved]]:
* DMI and mastering code: MS00402A (Meaning: publisher Microsoft, game number 004, version 02, region America)
* Title ID: 4D530004 [MS-004]

[[Halo: Combat Evolved]]:
* DMI and mastering code: MS00404E (Meaning: publisher Microsoft, game number 004, version 04, region Europe)
* Title ID: 4D530004 [MS-004]

== Allowed media types ==
Allowed media types off which the executable is allowed to be run from. The following values are known:
{| class=wikitable
! Media type !! Value
|-
|HARD_DISK || 0x00000001
|-
|DVD_X2 || 0x00000002
|-
|DVD_CD || 0x00000004
|-
|CD || 0x00000008
|-
|DVD_5_RO || 0x00000010
|-
|DVD_9_RO || 0x00000020
|-
|DVD_5_RW || 0x00000040
|-
|DVD_9_RW || 0x00000080
|-
|DONGLE || 0x00000100
|-
|MEDIA_BOARD || 0x00000200
|-
|NONSECURE_HARD_DISK || 0x40000000
|-
|NONSECURE_MODE || 0x80000000
|-
|MEDIA_MASK || 0x00FFFFFF
|}

= Sections =
The sections are described by the section headers. The section headers start right after the certificate and contain describe where in the file the actual sections reside. Each header contains a hash of the section that is checked by the Xbox to ensure the integrity of the sections.

At least two sections are always present in an Xbox executable: .text and .rdata. There might be more sections that contain either executable code or resources such as images, text, etc.

== .text ==

The .text section contains all x86 subroutines to be executed by the [[CPU|processor]].

== .rdata ==

The .rdata section contains the [[Kernel|kernel thunk table]]. The ordinals in the table are to be resolved to the kernel's actual calling routine, when loaded.

= Xbox Alpha executable format =

Binaries from early Xbox development (Alpha units), are using a different binary format. There are no known public tools that can read them.
Known differences include that the first bytes of the file are 'XE' instead the 'XBEH' from the final XBE format. The format is rumored to be more like the Windows PE format.{{citation needed}}

= Resources and links =
* [http://www.caustik.com/cxbx/download/xbe.htm .XBE File Format 1.1]

[[Category:Fileformats]]

Xbe

2021-05-11T18:59:18Z

Thrimbor: Resources and links shouldn't be a subsection of Xbox Alpha executable format

{{DISPLAYTITLE:XBE}}
XBE files (XBox Executable) are the main files that are executed in the Xbox System. In official games, these files are created by game developers, and then signed by Microsoft.

The file structure is adapted from Windows PE files. It is very similar, however it has important changes for the Xbox. The file is composed of an image header, a certificate, a collection of section headers, a collection of library versions, thread local storage data, a Microsoft bitmap, and the sections that contain the code and resources.

= Image Header =

The image header contains the information that describes where the other parts of the executable are located within the file, and how the executable should be treated and loaded. It has the following layout (all fields are little-endian):

{| class="wikitable
|-
! Offset
! Size
! Name
! Description
|-
! 0x0000
! 0x0004
| Magic Number
| This field must always equal 0x48454258 ("XBEH")
|-
! 0x0004
! 0x0100
| Digital Signature
| 256 Bytes. This is where a game is signed. Only on officially signed games is this field worthwhile.
|-
! 0x0104
! 0x0004
| Base Address
| Address at which to load this .XBE. Typically this will be 0x00010000.
|-
! 0x0108
! 0x0004
| Size of Headers
| Number of bytes that should be reserved for headers.
|-
! 0x010C
! 0x0004
| Size of Image
| Number of bytes that should be reserved for this image.
|-
! 0x0110
! 0x0004
| Size of Image Header
| Number of bytes that should be reserved for the image header. The header size varies by XDK version, but is at least 0x178.
|-
! 0x0114
! 0x0004
| TimeDate
| Time and Date when this image was created. Standard windows format.
|-
! 0x0118
! 0x0004
| Certificate Address
| Address to a [[#Certificate|Certificate]] structure, after the .XBE is loaded into memory.
|-
! 0x011C
! 0x0004
| Number of Sections
| Number of sections contained in this .XBE.
|-
! 0x0120
! 0x0004
| Section Headers Address
| Address to an array of SectionHeader structures, after the .XBE is loaded into memory.
|-
! 0x0124
! 0x0004
| Initialization Flags
| Various flags for this .XBE file. Known flags are:

MountUtilityDrive = 0x00000001
FormatUtilityDrive = 0x00000002
Limit64Megabytes = 0x00000004
DontSetupHarddisk = 0x00000008
|-
! 0x0128
! 0x0004
| Entry Point
| Address to the Image entry point, after the .XBE is loaded into memory. This is where execution starts.

This value is encoded with an XOR key. Considering this is far too weak to be considered security, I assume this XOR is a clever method for discerning between Debug/Retail .XBE files without adding another field to the .XBE header. The XOR key is dependant on the build:

Debug = 0x94859D4B, Retail = 0xA8FC57AB

To encode an entry point, you simply XOR the real entry point with either Debug or Retail key, depending on if you want the XBox to see this as a Debug or Retail executable.

To decode an entry point, you XOR with the debug key, then check if it is a valid entry point. If it is not, then you try again with the retail key.

Note: The Kernel Image Thunk Address member of this header must also be encoded as described later in this document.
|-
! 0x012C
! 0x0004
| TLS Address
| Address to a [[#TLS Table|TLS]] (Thread Local Storage) structure.
|-
! 0x0130
! 0x0004
| Stack Size
| Default stack size. As the Xbox does not allow for stacks to grow, this needs to be copied from the SizeOfStackReserve PE field, not SizeOfStackCommit!
|-
! 0x0134
! 0x0004
| PE Heap Reserve
| Copied from the PE file this .XBE was created from.
|-
! 0x0138
! 0x0004
| PE Heap Commit
| Copied from the PE file this .XBE was created from.
|-
! 0x013C
! 0x0004
| PE Base Address
| Copied from the PE file this .XBE was created from.
|-
! 0x0140
! 0x0004
| PE Size of Image
| Copied from the PE file this .XBE was created from.
|-
! 0x0144
! 0x0004
| PE Checksum
| Copied from the PE file this .XBE was created from.
|-
! 0x0148
! 0x0004
| PE TimeDate
| Copied from the PE file this .XBE was created from.
|-
! 0x014C
! 0x0004
| Debug PathName Address
| Address to the debug pathname (i.e. "D:\Nightlybuilds\011026.0\code\build\xbox\Release\simpsons.exe").
|-
! 0x0150
! 0x0004
| Debug FileName Address
| Address to the debug filename (i.e. "simpsons.exe")
|-
! 0x0154
! 0x0004
| Address to the UTF-16 debug filename (i.e. L"simpsons.exe")
| UTF-16 Debug FileName Address
|-
! 0x0158
! 0x0004
| Kernel Image Thunk Address
| Address to the Kernel Image Thunk Table, after the .XBE is loaded into memory. This is how .XBE files import kernel functions and data.

This value is encoded with an XOR key. Considering this is far too weak to be considered security, I assume this XOR is a clever method for discerning between Debug/Retail .XBE files without adding another field to the .XBE header. The XOR key is dependant on the build:

Debug = 0xEFB1F152, Retail = 0x5B6D40B6

To encode a kernel thunk address, you simply XOR the real address with either Debug or Retail key, depending on if you want the XBox to see this as a Debug or Retail executable.

To decode a kernel thunk address, you XOR with the debug key, then check if it is a valid address. If it is not, then you try again with the retail key.

The Kernel Thunk Table itself is simply an array of pointers to Kernel imports. There are 366 possible imports, and the table is terminated with a zero dword (0x00000000). Typically the values in this table can be generated with the following formula:

KernelThunkTable[v] = ImportThunk + 0x80000000;

so, for example, the import PsCreateSystemThreadEx, which has a thunk value of 255 (0xFF) would be...

KernelThunkTable[v] = 0xFF + 0x80000000; // (0x800000FF)

When the .XBE is loaded by the OS (or the CXBX Emulator), all kernel imports are replaced by a valid function or data type address. In the case of CXBX, the import table entry at which (KernelThunkTable[v] & 0x1FF == 0xFF) will be replaced by &cxbx_PsCreateSystemThreadEx (which is a wrapper function).

Note: The Entry Point member of this header must also be encoded as described earlier in this document.
|-
! 0x015C
! 0x0004
| Non-Kernel Import Directory Address
| Address to the Non-Kernel Import Directory. It is typically safe to set this to zero.
|-
! 0x0160
! 0x0004
| Number of Library Versions
| Number of Library Versions pointed to by Library Versions Address.
|-
! 0x0164
! 0x0004
| Library Versions Address
| Address to an array of LibraryVersion structures, after the .XBE is loaded into memory.
|-
! 0x0168
! 0x0004
| Kernel Library Version Address
| Address to a LibraryVersion structure, after the .XBE is loaded into memory.
|-
! 0x016C
! 0x0004
| XAPI Library Version Address
| Address to a LibraryVersion structure, after the .XBE is loaded into memory.
|-
! 0x0170
! 0x0004
| Logo Bitmap Address
| Address to the Logo Bitmap (Typically a "Microsoft" logo). The format of this image is described here. This field can be set to zero, meaning there is no bitmap present.
|-
! 0x0174
! 0x0004
| Logo Bitmap Size
| Size (in bytes) of the Logo Bitmap data. The format of this image is described here.
|-
! 0x0178
! 0x0008
| Unknown1
| The meaning of this field hasn't been figured out yet. It only exists on XBEs built with an XDK version >= 5028.
|-
! 0x0180
! 0x0004
| Unknown2
| The meaning of this field hasn't been figured out yet. It only exists on XBEs built with an XDK version >= 5455.
|}

== TLS Table ==

The TLS Table contains all the information needed by the XBE to properly set up thread-local storage. It is structurally identical to the TLS Directory found in PE32 files<ref>https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-tls-section</ref>, and can be directly copied from there. If the XBE does not use any thread-local storage, this table may be omitted, and the respective field in the image header set to zero.

{| class="wikitable
|-
! Offset
! Size
! Name
! Description
|-
! 0x0000
! 0x0004
| Raw Data Start
| Absolute (i.e. not an RVA) address of start of the TLS variable data in the program image.
|-
! 0x0004
! 0x0004
| Raw Data End
| Absolute (i.e. not an RVA) address of end of the TLS variable data in the program image.
|-
! 0x0008
! 0x0004
| Address of Index
| Absolute (i.e. not an RVA) address of the TLS Index variable.
|-
! 0x000C
! 0x0004
| Address of Callbacks
| Absolute (i.e. not an RVA) address of the null-terminated TLS callback functions table.
|-
! 0x0010
! 0x0004
| Size of Zero Fill
| The number of bytes following the raw data that should be set to zero in memory.
|-
! 0x0014
! 0x0004
| Characteristics
| Describes alignment.
|}

= Certificate =

Each Xbox executable has a certificate that contains information about the title.

* Time and date when the certificate was created
* Title ID
* Title name
* Alternative title IDs
* Allowed types of media that the executable can be run from (HD, DVD, CD, etc.)
* Game region
* Game ratings
* Disk number
* Version
* LAN key raw data used for [[System Link]]
* Signature key raw data (used to sign [[Xbox Savegame System|savegames]])
* Alternate signature keys
* Original size of the certificate
* Online service name (not present in early executables)
* Run time security flags (not present in early executables)

=== Title ID ===

A title ID is usually 2 ASCII letters for the publisher, followed by a u16 integer game number (Above 2000 for non-original Xbox games)

{| class=wikitable
! Publisher ID !! Name
|-
| AC || Acclaim Entertainment
|-
| AH || ARUSH Entertainment
|-
| AQ || Aqua System
|-
| AS || ASK
|-
| AT || Atlus
|-
| AV || Activision
|-
| AY || Aspyr Media
|-
| BA || Bandai
|-
| BL || Black Box
|-
| BM || BAM! Entertainment
|-
| BR || Broccoli Co.
|-
| BS || Bethesda Softworks
|-
| BU || Bunkasha Co.
|-
| BV || Buena Vista Games
|-
| BW || BBC Multimedia
|-
| BZ || Blizzard
|-
| CC || Capcom
|-
| CK || Kemco Corporation {{citation needed|reason=Did they realy swapped the ASCII letters? is KC a curced acroniem in Japan? Just want to be sure its Kemco|date=May 2017}}
|-
| CM || Codemasters
|-
| CV || Crave Entertainment
|-
| DC || DreamCatcher Interactive
|-
| DX || Davilex
|-
| EA || Electronic Arts (EA)
|-
| EC || Encore inc
|-
| EL || Enlight Software
|-
| EM || Empire Interactive
|-
| ES || Eidos Interactive
|-
| FI || Fox Interactive
|-
| FS || From Software
|-
| GE || Genki Co.
|-
| GV || Groove Games
|-
| HE || Tru Blu (Entertainment division of Home Entertainment Suppliers)
|-
| HP || Hip games
|-
| HU || Hudson Soft
|-
| HW || Highwaystar
|-
| IA || Mad Catz Interactive
|-
| IF || Idea Factory
|-
| IG || Infogrames
|-
| IL || [[Interlex Corporation]]
|-
| IM || Imagine Media
|-
| IO || Ignition Entertainment
|-
| IP || Interplay Entertainment
|-
| IX || InXile Entertainment {{citation needed}}
|-
| JA || Jaleco
|-
| JW || JoWooD
|-
| KB || Kemco {{citation needed|reason=CK is also Kemco, is this a diferent subsidairy or country based? Just want to be sure its Kemco|date=May 2017}}
|-
| KI || Kids Station Inc. {{citation needed|reason=Games info page was in japanese, I dont read japanese. but this seemed very logicaly the publisher, can a japanese reader confirm?|date=May 2017}}
|-
| KN || Konami
|-
| KO || KOEI
|-
| KU || Kobi and/or GAE (formerly Global A Entertainment){{citation needed|reason=What name did the publisher use at the time of release?|date=May 2017}}
|-
| LA || LucasArts
|-
| LS || Black Bean Games (publishing arm of Leader S.p.A.)
|-
| MD || Metro3D
|-
| ME || Medix
|-
| MI || Microïds
|-
| MJ || Majesco Entertainment
|-
| MM || Myelin Media
|-
| MP || MediaQuest {{citation needed|reason=Where is the P? I dont trust my source yet... but seems close|date=May 2017}}
|-
| MS || Microsoft Game Studios
|-
| MW || Midway Games
|-
| MX || Empire Interactive {{citation needed|reason=What happend to the publisher, who published this game?|date=May 2017}}
|-
| NK || NewKidCo
|-
| NL || NovaLogic
|-
| NM || Namco
|-
| OX || Oxygen Interactive
|-
| PC || Playlogic Entertainment
|-
| PL || Phantagram Co., Ltd.
|-
| RA || Rage
|-
| SA || Sammy
|-
| SC || SCi Games
|-
| SE || SEGA
|-
| SN || SNK
|-
| SS || Simon & Schuster
|-
| SU || Success Corporation
|-
| SW || Swing! Deutschland
|-
| TA || Takara
|-
| TC || Tecmo
|-
| TD || The 3DO Company (or just 3DO)
|-
| TK || Takuyo
|-
| TM || TDK Mediactive
|-
| TQ || THQ
|-
| TS || Titus Interactive
|-
| TT || Take-Two Interactive Software
|-
| US || Ubisoft
|-
| VC || Victor Interactive Software
|-
| VN || Vivendi Universal (just took Interplays publishing rights) {{citation needed}}
|-
| VU || Vivendi Universal Games
|-
| VV || Vivendi Universal Games {{citation needed}}
|-
| WE || Wanadoo Edition
|-
| WR || Warner Bros. Interactive Entertainment {{citation needed}}
|-
| XI || XPEC Entertainment and Idea Factory
|-
| XK || ''Xbox kiosk disk?'' {{citation needed}}
|-
| XL || ''Xbox special bundled or live demo disk?'' {{citation needed}}
|-
| XM || Evolved Games {{citation needed|reason=Probably not, game "Malice"|date=May 2017}}
|-
| XP || XPEC Entertainment
|-
| XR || Panorama
|-
| YB || YBM Sisa (South-Korea)
|-
| ZD || Zushi Games (formerly Zoo Digital Publishing)
|}

The title ID seems to double the information from the [[Xbox Game Disc]] mastering code etched into the ring or readable from the DMI.
The game number is expressed in 3 decimal digits here which suggests that it will always be below 1000.

'''Examples''':

[[FIFA Soccer 2003]]:
* DMI and mastering code: EA02302E (Meaning: publisher EA, game number 023, version 02, region Europe)
* Title ID: {{FIXME}}

[[Halo: Combat Evolved]]:
* DMI and mastering code: MS00402A (Meaning: publisher Microsoft, game number 004, version 02, region America)
* Title ID: 4D530004 [MS-004]

[[Halo: Combat Evolved]]:
* DMI and mastering code: MS00404E (Meaning: publisher Microsoft, game number 004, version 04, region Europe)
* Title ID: 4D530004 [MS-004]

== Allowed media types ==
Allowed media types off which the executable is allowed to be run from. The following values are known:
{| class=wikitable
! Media type !! Value
|-
|HARD_DISK || 0x00000001
|-
|DVD_X2 || 0x00000002
|-
|DVD_CD || 0x00000004
|-
|CD || 0x00000008
|-
|DVD_5_RO || 0x00000010
|-
|DVD_9_RO || 0x00000020
|-
|DVD_5_RW || 0x00000040
|-
|DVD_9_RW || 0x00000080
|-
|DONGLE || 0x00000100
|-
|MEDIA_BOARD || 0x00000200
|-
|NONSECURE_HARD_DISK || 0x40000000
|-
|NONSECURE_MODE || 0x80000000
|-
|MEDIA_MASK || 0x00FFFFFF
|}

= Sections =
The sections are described by the section headers. The section headers start right after the certificate and contain describe where in the file the actual sections reside. Each header contains a hash of the section that is checked by the Xbox to ensure the integrity of the sections.

At least two sections are always present in an Xbox executable: .text and .rdata. There might be more sections that contain either executable code or resources such as images, text, etc.

== .text ==

The .text section contains all x86 subroutines to be executed by the [[CPU|processor]].

== .rdata ==

The .rdata section contains the [[Kernel|kernel thunk table]]. The ordinals in the table are to be resolved to the kernel's actual calling routine, when loaded.

= Xbox Alpha executable format =

Binaries from early Xbox development (Alpha units), are using a different binary format. There are no known public tools that can read them.
Known differences include that the first bytes of the file are 'XE' instead the 'XBEH' from the final XBE format. The format is rumored to be more like the Windows PE format.{{citation needed}}

= Resources and links =
* [http://www.caustik.com/cxbx/download/xbe.htm .XBE File Format 1.1]

[[Category:Fileformats]]

Xbe

2021-05-11T18:57:25Z

Thrimbor: Add info about TLS

{{DISPLAYTITLE:XBE}}
XBE files (XBox Executable) are the main files that are executed in the Xbox System. In official games, these files are created by game developers, and then signed by Microsoft.

The file structure is adapted from Windows PE files. It is very similar, however it has important changes for the Xbox. The file is composed of an image header, a certificate, a collection of section headers, a collection of library versions, thread local storage data, a Microsoft bitmap, and the sections that contain the code and resources.

= Image Header =

The image header contains the information that describes where the other parts of the executable are located within the file, and how the executable should be treated and loaded. It has the following layout (all fields are little-endian):

{| class="wikitable
|-
! Offset
! Size
! Name
! Description
|-
! 0x0000
! 0x0004
| Magic Number
| This field must always equal 0x48454258 ("XBEH")
|-
! 0x0004
! 0x0100
| Digital Signature
| 256 Bytes. This is where a game is signed. Only on officially signed games is this field worthwhile.
|-
! 0x0104
! 0x0004
| Base Address
| Address at which to load this .XBE. Typically this will be 0x00010000.
|-
! 0x0108
! 0x0004
| Size of Headers
| Number of bytes that should be reserved for headers.
|-
! 0x010C
! 0x0004
| Size of Image
| Number of bytes that should be reserved for this image.
|-
! 0x0110
! 0x0004
| Size of Image Header
| Number of bytes that should be reserved for the image header. The header size varies by XDK version, but is at least 0x178.
|-
! 0x0114
! 0x0004
| TimeDate
| Time and Date when this image was created. Standard windows format.
|-
! 0x0118
! 0x0004
| Certificate Address
| Address to a [[#Certificate|Certificate]] structure, after the .XBE is loaded into memory.
|-
! 0x011C
! 0x0004
| Number of Sections
| Number of sections contained in this .XBE.
|-
! 0x0120
! 0x0004
| Section Headers Address
| Address to an array of SectionHeader structures, after the .XBE is loaded into memory.
|-
! 0x0124
! 0x0004
| Initialization Flags
| Various flags for this .XBE file. Known flags are:

MountUtilityDrive = 0x00000001
FormatUtilityDrive = 0x00000002
Limit64Megabytes = 0x00000004
DontSetupHarddisk = 0x00000008
|-
! 0x0128
! 0x0004
| Entry Point
| Address to the Image entry point, after the .XBE is loaded into memory. This is where execution starts.

This value is encoded with an XOR key. Considering this is far too weak to be considered security, I assume this XOR is a clever method for discerning between Debug/Retail .XBE files without adding another field to the .XBE header. The XOR key is dependant on the build:

Debug = 0x94859D4B, Retail = 0xA8FC57AB

To encode an entry point, you simply XOR the real entry point with either Debug or Retail key, depending on if you want the XBox to see this as a Debug or Retail executable.

To decode an entry point, you XOR with the debug key, then check if it is a valid entry point. If it is not, then you try again with the retail key.

Note: The Kernel Image Thunk Address member of this header must also be encoded as described later in this document.
|-
! 0x012C
! 0x0004
| TLS Address
| Address to a [[#TLS Table|TLS]] (Thread Local Storage) structure.
|-
! 0x0130
! 0x0004
| Stack Size
| Default stack size. As the Xbox does not allow for stacks to grow, this needs to be copied from the SizeOfStackReserve PE field, not SizeOfStackCommit!
|-
! 0x0134
! 0x0004
| PE Heap Reserve
| Copied from the PE file this .XBE was created from.
|-
! 0x0138
! 0x0004
| PE Heap Commit
| Copied from the PE file this .XBE was created from.
|-
! 0x013C
! 0x0004
| PE Base Address
| Copied from the PE file this .XBE was created from.
|-
! 0x0140
! 0x0004
| PE Size of Image
| Copied from the PE file this .XBE was created from.
|-
! 0x0144
! 0x0004
| PE Checksum
| Copied from the PE file this .XBE was created from.
|-
! 0x0148
! 0x0004
| PE TimeDate
| Copied from the PE file this .XBE was created from.
|-
! 0x014C
! 0x0004
| Debug PathName Address
| Address to the debug pathname (i.e. "D:\Nightlybuilds\011026.0\code\build\xbox\Release\simpsons.exe").
|-
! 0x0150
! 0x0004
| Debug FileName Address
| Address to the debug filename (i.e. "simpsons.exe")
|-
! 0x0154
! 0x0004
| Address to the UTF-16 debug filename (i.e. L"simpsons.exe")
| UTF-16 Debug FileName Address
|-
! 0x0158
! 0x0004
| Kernel Image Thunk Address
| Address to the Kernel Image Thunk Table, after the .XBE is loaded into memory. This is how .XBE files import kernel functions and data.

This value is encoded with an XOR key. Considering this is far too weak to be considered security, I assume this XOR is a clever method for discerning between Debug/Retail .XBE files without adding another field to the .XBE header. The XOR key is dependant on the build:

Debug = 0xEFB1F152, Retail = 0x5B6D40B6

To encode a kernel thunk address, you simply XOR the real address with either Debug or Retail key, depending on if you want the XBox to see this as a Debug or Retail executable.

To decode a kernel thunk address, you XOR with the debug key, then check if it is a valid address. If it is not, then you try again with the retail key.

The Kernel Thunk Table itself is simply an array of pointers to Kernel imports. There are 366 possible imports, and the table is terminated with a zero dword (0x00000000). Typically the values in this table can be generated with the following formula:

KernelThunkTable[v] = ImportThunk + 0x80000000;

so, for example, the import PsCreateSystemThreadEx, which has a thunk value of 255 (0xFF) would be...

KernelThunkTable[v] = 0xFF + 0x80000000; // (0x800000FF)

When the .XBE is loaded by the OS (or the CXBX Emulator), all kernel imports are replaced by a valid function or data type address. In the case of CXBX, the import table entry at which (KernelThunkTable[v] & 0x1FF == 0xFF) will be replaced by &cxbx_PsCreateSystemThreadEx (which is a wrapper function).

Note: The Entry Point member of this header must also be encoded as described earlier in this document.
|-
! 0x015C
! 0x0004
| Non-Kernel Import Directory Address
| Address to the Non-Kernel Import Directory. It is typically safe to set this to zero.
|-
! 0x0160
! 0x0004
| Number of Library Versions
| Number of Library Versions pointed to by Library Versions Address.
|-
! 0x0164
! 0x0004
| Library Versions Address
| Address to an array of LibraryVersion structures, after the .XBE is loaded into memory.
|-
! 0x0168
! 0x0004
| Kernel Library Version Address
| Address to a LibraryVersion structure, after the .XBE is loaded into memory.
|-
! 0x016C
! 0x0004
| XAPI Library Version Address
| Address to a LibraryVersion structure, after the .XBE is loaded into memory.
|-
! 0x0170
! 0x0004
| Logo Bitmap Address
| Address to the Logo Bitmap (Typically a "Microsoft" logo). The format of this image is described here. This field can be set to zero, meaning there is no bitmap present.
|-
! 0x0174
! 0x0004
| Logo Bitmap Size
| Size (in bytes) of the Logo Bitmap data. The format of this image is described here.
|-
! 0x0178
! 0x0008
| Unknown1
| The meaning of this field hasn't been figured out yet. It only exists on XBEs built with an XDK version >= 5028.
|-
! 0x0180
! 0x0004
| Unknown2
| The meaning of this field hasn't been figured out yet. It only exists on XBEs built with an XDK version >= 5455.
|}

== TLS Table ==

The TLS Table contains all the information needed by the XBE to properly set up thread-local storage. It is structurally identical to the TLS Directory found in PE32 files<ref>https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-tls-section</ref>, and can be directly copied from there. If the XBE does not use any thread-local storage, this table may be omitted, and the respective field in the image header set to zero.

{| class="wikitable
|-
! Offset
! Size
! Name
! Description
|-
! 0x0000
! 0x0004
| Raw Data Start
| Absolute (i.e. not an RVA) address of start of the TLS variable data in the program image.
|-
! 0x0004
! 0x0004
| Raw Data End
| Absolute (i.e. not an RVA) address of end of the TLS variable data in the program image.
|-
! 0x0008
! 0x0004
| Address of Index
| Absolute (i.e. not an RVA) address of the TLS Index variable.
|-
! 0x000C
! 0x0004
| Address of Callbacks
| Absolute (i.e. not an RVA) address of the null-terminated TLS callback functions table.
|-
! 0x0010
! 0x0004
| Size of Zero Fill
| The number of bytes following the raw data that should be set to zero in memory.
|-
! 0x0014
! 0x0004
| Characteristics
| Describes alignment.
|}

= Certificate =

Each Xbox executable has a certificate that contains information about the title.

* Time and date when the certificate was created
* Title ID
* Title name
* Alternative title IDs
* Allowed types of media that the executable can be run from (HD, DVD, CD, etc.)
* Game region
* Game ratings
* Disk number
* Version
* LAN key raw data used for [[System Link]]
* Signature key raw data (used to sign [[Xbox Savegame System|savegames]])
* Alternate signature keys
* Original size of the certificate
* Online service name (not present in early executables)
* Run time security flags (not present in early executables)

=== Title ID ===

A title ID is usually 2 ASCII letters for the publisher, followed by a u16 integer game number (Above 2000 for non-original Xbox games)

{| class=wikitable
! Publisher ID !! Name
|-
| AC || Acclaim Entertainment
|-
| AH || ARUSH Entertainment
|-
| AQ || Aqua System
|-
| AS || ASK
|-
| AT || Atlus
|-
| AV || Activision
|-
| AY || Aspyr Media
|-
| BA || Bandai
|-
| BL || Black Box
|-
| BM || BAM! Entertainment
|-
| BR || Broccoli Co.
|-
| BS || Bethesda Softworks
|-
| BU || Bunkasha Co.
|-
| BV || Buena Vista Games
|-
| BW || BBC Multimedia
|-
| BZ || Blizzard
|-
| CC || Capcom
|-
| CK || Kemco Corporation {{citation needed|reason=Did they realy swapped the ASCII letters? is KC a curced acroniem in Japan? Just want to be sure its Kemco|date=May 2017}}
|-
| CM || Codemasters
|-
| CV || Crave Entertainment
|-
| DC || DreamCatcher Interactive
|-
| DX || Davilex
|-
| EA || Electronic Arts (EA)
|-
| EC || Encore inc
|-
| EL || Enlight Software
|-
| EM || Empire Interactive
|-
| ES || Eidos Interactive
|-
| FI || Fox Interactive
|-
| FS || From Software
|-
| GE || Genki Co.
|-
| GV || Groove Games
|-
| HE || Tru Blu (Entertainment division of Home Entertainment Suppliers)
|-
| HP || Hip games
|-
| HU || Hudson Soft
|-
| HW || Highwaystar
|-
| IA || Mad Catz Interactive
|-
| IF || Idea Factory
|-
| IG || Infogrames
|-
| IL || [[Interlex Corporation]]
|-
| IM || Imagine Media
|-
| IO || Ignition Entertainment
|-
| IP || Interplay Entertainment
|-
| IX || InXile Entertainment {{citation needed}}
|-
| JA || Jaleco
|-
| JW || JoWooD
|-
| KB || Kemco {{citation needed|reason=CK is also Kemco, is this a diferent subsidairy or country based? Just want to be sure its Kemco|date=May 2017}}
|-
| KI || Kids Station Inc. {{citation needed|reason=Games info page was in japanese, I dont read japanese. but this seemed very logicaly the publisher, can a japanese reader confirm?|date=May 2017}}
|-
| KN || Konami
|-
| KO || KOEI
|-
| KU || Kobi and/or GAE (formerly Global A Entertainment){{citation needed|reason=What name did the publisher use at the time of release?|date=May 2017}}
|-
| LA || LucasArts
|-
| LS || Black Bean Games (publishing arm of Leader S.p.A.)
|-
| MD || Metro3D
|-
| ME || Medix
|-
| MI || Microïds
|-
| MJ || Majesco Entertainment
|-
| MM || Myelin Media
|-
| MP || MediaQuest {{citation needed|reason=Where is the P? I dont trust my source yet... but seems close|date=May 2017}}
|-
| MS || Microsoft Game Studios
|-
| MW || Midway Games
|-
| MX || Empire Interactive {{citation needed|reason=What happend to the publisher, who published this game?|date=May 2017}}
|-
| NK || NewKidCo
|-
| NL || NovaLogic
|-
| NM || Namco
|-
| OX || Oxygen Interactive
|-
| PC || Playlogic Entertainment
|-
| PL || Phantagram Co., Ltd.
|-
| RA || Rage
|-
| SA || Sammy
|-
| SC || SCi Games
|-
| SE || SEGA
|-
| SN || SNK
|-
| SS || Simon & Schuster
|-
| SU || Success Corporation
|-
| SW || Swing! Deutschland
|-
| TA || Takara
|-
| TC || Tecmo
|-
| TD || The 3DO Company (or just 3DO)
|-
| TK || Takuyo
|-
| TM || TDK Mediactive
|-
| TQ || THQ
|-
| TS || Titus Interactive
|-
| TT || Take-Two Interactive Software
|-
| US || Ubisoft
|-
| VC || Victor Interactive Software
|-
| VN || Vivendi Universal (just took Interplays publishing rights) {{citation needed}}
|-
| VU || Vivendi Universal Games
|-
| VV || Vivendi Universal Games {{citation needed}}
|-
| WE || Wanadoo Edition
|-
| WR || Warner Bros. Interactive Entertainment {{citation needed}}
|-
| XI || XPEC Entertainment and Idea Factory
|-
| XK || ''Xbox kiosk disk?'' {{citation needed}}
|-
| XL || ''Xbox special bundled or live demo disk?'' {{citation needed}}
|-
| XM || Evolved Games {{citation needed|reason=Probably not, game "Malice"|date=May 2017}}
|-
| XP || XPEC Entertainment
|-
| XR || Panorama
|-
| YB || YBM Sisa (South-Korea)
|-
| ZD || Zushi Games (formerly Zoo Digital Publishing)
|}

The title ID seems to double the information from the [[Xbox Game Disc]] mastering code etched into the ring or readable from the DMI.
The game number is expressed in 3 decimal digits here which suggests that it will always be below 1000.

'''Examples''':

[[FIFA Soccer 2003]]:
* DMI and mastering code: EA02302E (Meaning: publisher EA, game number 023, version 02, region Europe)
* Title ID: {{FIXME}}

[[Halo: Combat Evolved]]:
* DMI and mastering code: MS00402A (Meaning: publisher Microsoft, game number 004, version 02, region America)
* Title ID: 4D530004 [MS-004]

[[Halo: Combat Evolved]]:
* DMI and mastering code: MS00404E (Meaning: publisher Microsoft, game number 004, version 04, region Europe)
* Title ID: 4D530004 [MS-004]

== Allowed media types ==
Allowed media types off which the executable is allowed to be run from. The following values are known:
{| class=wikitable
! Media type !! Value
|-
|HARD_DISK || 0x00000001
|-
|DVD_X2 || 0x00000002
|-
|DVD_CD || 0x00000004
|-
|CD || 0x00000008
|-
|DVD_5_RO || 0x00000010
|-
|DVD_9_RO || 0x00000020
|-
|DVD_5_RW || 0x00000040
|-
|DVD_9_RW || 0x00000080
|-
|DONGLE || 0x00000100
|-
|MEDIA_BOARD || 0x00000200
|-
|NONSECURE_HARD_DISK || 0x40000000
|-
|NONSECURE_MODE || 0x80000000
|-
|MEDIA_MASK || 0x00FFFFFF
|}

= Sections =
The sections are described by the section headers. The section headers start right after the certificate and contain describe where in the file the actual sections reside. Each header contains a hash of the section that is checked by the Xbox to ensure the integrity of the sections.

At least two sections are always present in an Xbox executable: .text and .rdata. There might be more sections that contain either executable code or resources such as images, text, etc.

== .text ==

The .text section contains all x86 subroutines to be executed by the [[CPU|processor]].

== .rdata ==

The .rdata section contains the [[Kernel|kernel thunk table]]. The ordinals in the table are to be resolved to the kernel's actual calling routine, when loaded.

= Xbox Alpha executable format=

Binaries from early Xbox development (Alpha units), are using a different binary format. There are no known public tools that can read them.
Known differences include that the first bytes of the file are 'XE' instead the 'XBEH' from the final XBE format. The format is rumored to be more like the Windows PE format.{{citation needed}}

== Resources and links ==
* [http://www.caustik.com/cxbx/download/xbe.htm .XBE File Format 1.1]
{{reflist}}

[[Category:Fileformats]]

Xbe

2021-05-11T18:18:51Z

Thrimbor: Add full image header table. Mostly taken from caustik, but with fixes and enhancements

{{DISPLAYTITLE:XBE}}
XBE files (XBox Executable) are the main files that are executed in the Xbox System. In official games, these files are created by game developers, and then signed by Microsoft.

The file structure is adapted from Windows PE files. It is very similar, however it has important changes for the Xbox. The file is composed of an image header, a certificate, a collection of section headers, a collection of library versions, thread local storage data, a Microsoft bitmap, and the sections that contain the code and resources.

= Image Header =

The image header contains the information that describes where the other parts of the executable are located within the file, and how the executable should be treated and loaded. It has the following layout (all fields are little-endian):

{| class="wikitable
|-
! Offset
! Size
! Name
! Description
|-
! 0x0000
! 0x0004
| Magic Number
| This field must always equal 0x48454258 ("XBEH")
|-
! 0x0004
! 0x0100
| Digital Signature
| 256 Bytes. This is where a game is signed. Only on officially signed games is this field worthwhile.
|-
! 0x0104
! 0x0004
| Base Address
| Address at which to load this .XBE. Typically this will be 0x00010000.
|-
! 0x0108
! 0x0004
| Size of Headers
| Number of bytes that should be reserved for headers.
|-
! 0x010C
! 0x0004
| Size of Image
| Number of bytes that should be reserved for this image.
|-
! 0x0110
! 0x0004
| Size of Image Header
| Number of bytes that should be reserved for the image header. The header size varies by XDK version, but is at least 0x178.
|-
! 0x0114
! 0x0004
| TimeDate
| Time and Date when this image was created. Standard windows format.
|-
! 0x0118
! 0x0004
| Certificate Address
| Address to a [[#Certificate|Certificate]] structure, after the .XBE is loaded into memory.
|-
! 0x011C
! 0x0004
| Number of Sections
| Number of sections contained in this .XBE.
|-
! 0x0120
! 0x0004
| Section Headers Address
| Address to an array of SectionHeader structures, after the .XBE is loaded into memory.
|-
! 0x0124
! 0x0004
| Initialization Flags
| Various flags for this .XBE file. Known flags are:

MountUtilityDrive = 0x00000001
FormatUtilityDrive = 0x00000002
Limit64Megabytes = 0x00000004
DontSetupHarddisk = 0x00000008
|-
! 0x0128
! 0x0004
| Entry Point
| Address to the Image entry point, after the .XBE is loaded into memory. This is where execution starts.

This value is encoded with an XOR key. Considering this is far too weak to be considered security, I assume this XOR is a clever method for discerning between Debug/Retail .XBE files without adding another field to the .XBE header. The XOR key is dependant on the build:

Debug = 0x94859D4B, Retail = 0xA8FC57AB

To encode an entry point, you simply XOR the real entry point with either Debug or Retail key, depending on if you want the XBox to see this as a Debug or Retail executable.

To decode an entry point, you XOR with the debug key, then check if it is a valid entry point. If it is not, then you try again with the retail key.

Note: The Kernel Image Thunk Address member of this header must also be encoded as described later in this document.
|-
! 0x012C
! 0x0004
| TLS Address
| Address to a TLS (Thread Local Storage) structure.
|-
! 0x0130
! 0x0004
| Stack Size
| Default stack size. As the Xbox does not allow for stacks to grow, this needs to be copied from the SizeOfStackReserve PE field, not SizeOfStackCommit!
|-
! 0x0134
! 0x0004
| PE Heap Reserve
| Copied from the PE file this .XBE was created from.
|-
! 0x0138
! 0x0004
| PE Heap Commit
| Copied from the PE file this .XBE was created from.
|-
! 0x013C
! 0x0004
| PE Base Address
| Copied from the PE file this .XBE was created from.
|-
! 0x0140
! 0x0004
| PE Size of Image
| Copied from the PE file this .XBE was created from.
|-
! 0x0144
! 0x0004
| PE Checksum
| Copied from the PE file this .XBE was created from.
|-
! 0x0148
! 0x0004
| PE TimeDate
| Copied from the PE file this .XBE was created from.
|-
! 0x014C
! 0x0004
| Debug PathName Address
| Address to the debug pathname (i.e. "D:\Nightlybuilds\011026.0\code\build\xbox\Release\simpsons.exe").
|-
! 0x0150
! 0x0004
| Debug FileName Address
| Address to the debug filename (i.e. "simpsons.exe")
|-
! 0x0154
! 0x0004
| Address to the UTF-16 debug filename (i.e. L"simpsons.exe")
| UTF-16 Debug FileName Address
|-
! 0x0158
! 0x0004
| Kernel Image Thunk Address
| Address to the Kernel Image Thunk Table, after the .XBE is loaded into memory. This is how .XBE files import kernel functions and data.

This value is encoded with an XOR key. Considering this is far too weak to be considered security, I assume this XOR is a clever method for discerning between Debug/Retail .XBE files without adding another field to the .XBE header. The XOR key is dependant on the build:

Debug = 0xEFB1F152, Retail = 0x5B6D40B6

To encode a kernel thunk address, you simply XOR the real address with either Debug or Retail key, depending on if you want the XBox to see this as a Debug or Retail executable.

To decode a kernel thunk address, you XOR with the debug key, then check if it is a valid address. If it is not, then you try again with the retail key.

The Kernel Thunk Table itself is simply an array of pointers to Kernel imports. There are 366 possible imports, and the table is terminated with a zero dword (0x00000000). Typically the values in this table can be generated with the following formula:

KernelThunkTable[v] = ImportThunk + 0x80000000;

so, for example, the import PsCreateSystemThreadEx, which has a thunk value of 255 (0xFF) would be...

KernelThunkTable[v] = 0xFF + 0x80000000; // (0x800000FF)

When the .XBE is loaded by the OS (or the CXBX Emulator), all kernel imports are replaced by a valid function or data type address. In the case of CXBX, the import table entry at which (KernelThunkTable[v] & 0x1FF == 0xFF) will be replaced by &cxbx_PsCreateSystemThreadEx (which is a wrapper function).

Note: The Entry Point member of this header must also be encoded as described earlier in this document.
|-
! 0x015C
! 0x0004
| Non-Kernel Import Directory Address
| Address to the Non-Kernel Import Directory. It is typically safe to set this to zero.
|-
! 0x0160
! 0x0004
| Number of Library Versions
| Number of Library Versions pointed to by Library Versions Address.
|-
! 0x0164
! 0x0004
| Library Versions Address
| Address to an array of LibraryVersion structures, after the .XBE is loaded into memory.
|-
! 0x0168
! 0x0004
| Kernel Library Version Address
| Address to a LibraryVersion structure, after the .XBE is loaded into memory.
|-
! 0x016C
! 0x0004
| XAPI Library Version Address
| Address to a LibraryVersion structure, after the .XBE is loaded into memory.
|-
! 0x0170
! 0x0004
| Logo Bitmap Address
| Address to the Logo Bitmap (Typically a "Microsoft" logo). The format of this image is described here. This field can be set to zero, meaning there is no bitmap present.
|-
! 0x0174
! 0x0004
| Logo Bitmap Size
| Size (in bytes) of the Logo Bitmap data. The format of this image is described here.
|-
! 0x0178
! 0x0008
| Unknown1
| The meaning of this field hasn't been figured out yet. It only exists on XBEs built with an XDK version >= 5028.
|-
! 0x0180
! 0x0004
| Unknown2
| The meaning of this field hasn't been figured out yet. It only exists on XBEs built with an XDK version >= 5455.
|}

= Certificate =

Each Xbox executable has a certificate that contains information about the title.

* Time and date when the certificate was created
* Title ID
* Title name
* Alternative title IDs
* Allowed types of media that the executable can be run from (HD, DVD, CD, etc.)
* Game region
* Game ratings
* Disk number
* Version
* LAN key raw data used for [[System Link]]
* Signature key raw data (used to sign [[Xbox Savegame System|savegames]])
* Alternate signature keys
* Original size of the certificate
* Online service name (not present in early executables)
* Run time security flags (not present in early executables)

=== Title ID ===

A title ID is usually 2 ASCII letters for the publisher, followed by a u16 integer game number (Above 2000 for non-original Xbox games)

{| class=wikitable
! Publisher ID !! Name
|-
| AC || Acclaim Entertainment
|-
| AH || ARUSH Entertainment
|-
| AQ || Aqua System
|-
| AS || ASK
|-
| AT || Atlus
|-
| AV || Activision
|-
| AY || Aspyr Media
|-
| BA || Bandai
|-
| BL || Black Box
|-
| BM || BAM! Entertainment
|-
| BR || Broccoli Co.
|-
| BS || Bethesda Softworks
|-
| BU || Bunkasha Co.
|-
| BV || Buena Vista Games
|-
| BW || BBC Multimedia
|-
| BZ || Blizzard
|-
| CC || Capcom
|-
| CK || Kemco Corporation {{citation needed|reason=Did they realy swapped the ASCII letters? is KC a curced acroniem in Japan? Just want to be sure its Kemco|date=May 2017}}
|-
| CM || Codemasters
|-
| CV || Crave Entertainment
|-
| DC || DreamCatcher Interactive
|-
| DX || Davilex
|-
| EA || Electronic Arts (EA)
|-
| EC || Encore inc
|-
| EL || Enlight Software
|-
| EM || Empire Interactive
|-
| ES || Eidos Interactive
|-
| FI || Fox Interactive
|-
| FS || From Software
|-
| GE || Genki Co.
|-
| GV || Groove Games
|-
| HE || Tru Blu (Entertainment division of Home Entertainment Suppliers)
|-
| HP || Hip games
|-
| HU || Hudson Soft
|-
| HW || Highwaystar
|-
| IA || Mad Catz Interactive
|-
| IF || Idea Factory
|-
| IG || Infogrames
|-
| IL || [[Interlex Corporation]]
|-
| IM || Imagine Media
|-
| IO || Ignition Entertainment
|-
| IP || Interplay Entertainment
|-
| IX || InXile Entertainment {{citation needed}}
|-
| JA || Jaleco
|-
| JW || JoWooD
|-
| KB || Kemco {{citation needed|reason=CK is also Kemco, is this a diferent subsidairy or country based? Just want to be sure its Kemco|date=May 2017}}
|-
| KI || Kids Station Inc. {{citation needed|reason=Games info page was in japanese, I dont read japanese. but this seemed very logicaly the publisher, can a japanese reader confirm?|date=May 2017}}
|-
| KN || Konami
|-
| KO || KOEI
|-
| KU || Kobi and/or GAE (formerly Global A Entertainment){{citation needed|reason=What name did the publisher use at the time of release?|date=May 2017}}
|-
| LA || LucasArts
|-
| LS || Black Bean Games (publishing arm of Leader S.p.A.)
|-
| MD || Metro3D
|-
| ME || Medix
|-
| MI || Microïds
|-
| MJ || Majesco Entertainment
|-
| MM || Myelin Media
|-
| MP || MediaQuest {{citation needed|reason=Where is the P? I dont trust my source yet... but seems close|date=May 2017}}
|-
| MS || Microsoft Game Studios
|-
| MW || Midway Games
|-
| MX || Empire Interactive {{citation needed|reason=What happend to the publisher, who published this game?|date=May 2017}}
|-
| NK || NewKidCo
|-
| NL || NovaLogic
|-
| NM || Namco
|-
| OX || Oxygen Interactive
|-
| PC || Playlogic Entertainment
|-
| PL || Phantagram Co., Ltd.
|-
| RA || Rage
|-
| SA || Sammy
|-
| SC || SCi Games
|-
| SE || SEGA
|-
| SN || SNK
|-
| SS || Simon & Schuster
|-
| SU || Success Corporation
|-
| SW || Swing! Deutschland
|-
| TA || Takara
|-
| TC || Tecmo
|-
| TD || The 3DO Company (or just 3DO)
|-
| TK || Takuyo
|-
| TM || TDK Mediactive
|-
| TQ || THQ
|-
| TS || Titus Interactive
|-
| TT || Take-Two Interactive Software
|-
| US || Ubisoft
|-
| VC || Victor Interactive Software
|-
| VN || Vivendi Universal (just took Interplays publishing rights) {{citation needed}}
|-
| VU || Vivendi Universal Games
|-
| VV || Vivendi Universal Games {{citation needed}}
|-
| WE || Wanadoo Edition
|-
| WR || Warner Bros. Interactive Entertainment {{citation needed}}
|-
| XI || XPEC Entertainment and Idea Factory
|-
| XK || ''Xbox kiosk disk?'' {{citation needed}}
|-
| XL || ''Xbox special bundled or live demo disk?'' {{citation needed}}
|-
| XM || Evolved Games {{citation needed|reason=Probably not, game "Malice"|date=May 2017}}
|-
| XP || XPEC Entertainment
|-
| XR || Panorama
|-
| YB || YBM Sisa (South-Korea)
|-
| ZD || Zushi Games (formerly Zoo Digital Publishing)
|}

The title ID seems to double the information from the [[Xbox Game Disc]] mastering code etched into the ring or readable from the DMI.
The game number is expressed in 3 decimal digits here which suggests that it will always be below 1000.

'''Examples''':

[[FIFA Soccer 2003]]:
* DMI and mastering code: EA02302E (Meaning: publisher EA, game number 023, version 02, region Europe)
* Title ID: {{FIXME}}

[[Halo: Combat Evolved]]:
* DMI and mastering code: MS00402A (Meaning: publisher Microsoft, game number 004, version 02, region America)
* Title ID: 4D530004 [MS-004]

[[Halo: Combat Evolved]]:
* DMI and mastering code: MS00404E (Meaning: publisher Microsoft, game number 004, version 04, region Europe)
* Title ID: 4D530004 [MS-004]

== Allowed media types ==
Allowed media types off which the executable is allowed to be run from. The following values are known:
{| class=wikitable
! Media type !! Value
|-
|HARD_DISK || 0x00000001
|-
|DVD_X2 || 0x00000002
|-
|DVD_CD || 0x00000004
|-
|CD || 0x00000008
|-
|DVD_5_RO || 0x00000010
|-
|DVD_9_RO || 0x00000020
|-
|DVD_5_RW || 0x00000040
|-
|DVD_9_RW || 0x00000080
|-
|DONGLE || 0x00000100
|-
|MEDIA_BOARD || 0x00000200
|-
|NONSECURE_HARD_DISK || 0x40000000
|-
|NONSECURE_MODE || 0x80000000
|-
|MEDIA_MASK || 0x00FFFFFF
|}

= Sections =
The sections are described by the section headers. The section headers start right after the certificate and contain describe where in the file the actual sections reside. Each header contains a hash of the section that is checked by the Xbox to ensure the integrity of the sections.

At least two sections are always present in an Xbox executable: .text and .rdata. There might be more sections that contain either executable code or resources such as images, text, etc.

== .text ==

The .text section contains all x86 subroutines to be executed by the [[CPU|processor]].

== .rdata ==

The .rdata section contains the [[Kernel|kernel thunk table]]. The ordinals in the table are to be resolved to the kernel's actual calling routine, when loaded.

= Xbox Alpha executable format=

Binaries from early Xbox development (Alpha units), are using a different binary format. There are no known public tools that can read them.
Known differences include that the first bytes of the file are 'XE' instead the 'XBEH' from the final XBE format. The format is rumored to be more like the Windows PE format.{{citation needed}}

== Resources and links ==
* [http://www.caustik.com/cxbx/download/xbe.htm .XBE File Format 1.1]

[[Category:Fileformats]]