Jekyll2026-05-12T16:22:14+00:00http://mvinetwork.co.uk/feed.xmlMVIBarnaby Smith's personal dev blog.Barnaby SmithBattle Sister’s BLAST - Creating a highly efficient render engine for Meta Quest2026-05-11T00:00:00+00:002026-05-11T00:00:00+00:00http://mvinetwork.co.uk/2026/05/11/battle-sisters-blast

Warhammer 40,000: Battle Sister was a launch title for Quest 2 (as well as releasing on Quest 1 and later Steam). Battle Sister used a novel render engine, combining an edit time baking solution and runtime batcher that achieved extremely low drawcall counts for environments as well as optimised fillrate and minimal overdraw.

This blog post describes the background for BLAST’s development as well as a high level technical overview of how it worked. Please note this is written from memory and there may be some minor inaccuracies.

Posted with kind permission of Soul Assembly.

The Problem Space

Following the release of Drop Dead: Dual Strike as a launch title for Oculus Quest in 2019, we started pre-production on the next game. At that time, we weren’t sure what the next title would be but we understood certain challenges on standalone VR that we wanted to research systemic solutions to.

We knew that particular constraints were:

  • Draw Calls
  • Overdraw and Fill Rate Limits

Common solutions to these constraints include static batching, atlases and occlusion culling.

Atlases are a good solution but they make it more complicated to handle tiling and they can’t be that large before you are forced to create a new atlas. If hand authored, they are also inflexible when you decide to add or remove assets to levels.

We had evaluated Unity’s occlusion culling several times on mobile and not found a consistent performance benefit, often it resulted in poorer performance.

Static batching is well implemented in Unity, but did not give us the level of control to achieve our overall vision for performance.

In addition we were also interested in seamless level streaming for considerably bigger maps and longer levels, wanting to avoid being constrained to short levels like Drop Dead or having repeated hard load screens.

Around this time Unity announced Native Mesh Access (Unity 2019.3), an efficient way to manipulate mesh data via CPU jobs that works well on mobile devices where CPU and GPU RAM is shared.

We were also evaluating the use of texture arrays as a solution for collapsing draw calls with similar material/shader setup that differed principally only in textures.

Other considerations included optimising vertex attribute size, order and splitting streams for better binning shader performance.

Introducing BLAST

Around the time that this initial research concluded, we had a proof of concept working as well as a green lit game (Warhammer 40,000: Battle Sister) to use it on!

During Battle Sister’s development we evolved this research into a technology called BLAST - a loose backronym for Batching, Lodding and Streaming Technologies.

BLAST is a rendering engine designed for Quest supporting extreme levels of batching, fine levels of occlusion and sorting, streaming assets in and out. Consisting of an editor baking tooling and a runtime engine using Jobs with Native Mesh Access and texture arrays. The majority of static environments in Battle Sister render in just 4 drawcalls and are aggressively optimised for fillrate compared to other typical approaches. BLAST essentially sidesteps most of Unity’s rendering stack and provides an alternate paradigm for rendering environments.

Levels were created with modular pieces, generally using a 3x3 meter footprint (both for floor pieces and walls). 3x3 was chosen as it accommodates typical door sizes and seems a good trade off between being too granular (resulting in tedious placement) and too large (resulting in poor culling or sorting opportunities). Snap points were also placed on many kit pieces allowing them to be snapped together in a footprint friendly way. Meshes were authored so that the wall thickness was baked in relative to the pivot/snap points, so they could be placed easily back to back and have the correct wall thickness.

Fallout 4’s Modular Level Design talk (as well as it’s Skyrim predecessor) was highly inspirational and is required watching for anyone making level design tools.

A Note on Level Streaming

Side by side with BLAST, a level streaming system was also implemented, inspired by Unreal’s model. Each mission was broken into multiple chunks, each with Art and Gameplay versions to allow for better source control concurrency. Cuboid level streaming volumes are hand placed. Multiple level streaming volumes can reference the same level chunk and reference counting is used, this means that concave play spaces can be made out of multiple volumes.

BLAST consisted of two elements:

  1. Editor
  2. Runtime

Editor

The editor consisted of a tooling window that allowed you to kick off BLAST bakes as well as inspect the output of the current bake (mainly how many merge groups it produced and what was packed in them).

Chapter 6: Nav Mesh Input
Chapter 6: Voxelised
Unique Color Preview Of A Test Level (3D Game Kit)

The bake process involved:

  1. A validation pre-step runs which checks that eligible assets (those not marked for exclusion, either explicitly or through a rule) are correctly configured. This prevents a lengthy wait to a bake failure due to a missing checkbox on an asset.
  2. Voxelise the nav mesh - Battle Sister used the nav mesh, not just for NPC movement but also for player teleportation. The nav mesh was considered a good analogue for where the player could go. BLAST’s first step is to voxelise the Nav Mesh into 2 meter cubes, with a limited stacking capability too in case the player is particularly tall or physically jumps. For lift shafts or areas the player can climb, voxelised volumes could also be placed, providing additional input.
  3. BLAST then walks through each voxel:
    1. For each voxel, the world that should be loaded corresponding to the level streaming volumes including the voxel is rendered using special replacement materials as a cubemap. As the cubemap camera reacts to mesh renderer LOD levels differently to a VR camera, we also calculate the correct LOD levels for VR and force the LOD Groups to use that.
      1. For opaque objects each object is given a unique colour in its replacement material, then a compute shader counts how many pixels of each object is visible. An object is considered visible if it exceeds a certain (fairly low) count. Multiple samples are taken within each voxel to allow for player/head movement (since the voxels are fairly large).
      2. Transparent objects (such as billboard quads used for lights) are then drawn, with each object representing a bit in a bit field. By using a bit field we can have multiple transparent objects layered together and still calculate their visibility. Multiple passes are applied as the number of transparent objects may exceed the size of the bit field. Opaque objects are still drawn, but in black.
      3. Opaque objects are then sorted front to back (as it’s more efficient when depth buffer rejection is used. Transparent objects are sorted back to front as this is required for correct layering.
  4. Voxel visibility is then locally merged by having each voxel inherit its neighbours visibility too, this avoids an issue where putting your head round a corner quickly could allow you to see the world pop in as it takes approximately 4 frames to update what is visible. While this increases overdraw in some cases, the game’s nature of push forward combat and the general performance benefits of BLAST meant this was an acceptable compromise.
  5. In addition, a very simple cell to cell visibility mapping was created. This had a limited view distance, but was used as a form of occlusion culling on dynamic objects. (If the object is inside a voxel that can be seen from your voxel then draw it). This was added very late in development and was a fairly simple/crude implementation, but had a tangible benefit.
  6. Texture array sizes are pre-calculated for each level so that they can be allocated when the level is loaded.
  7. The visibility data is written to disk as a proprietary binary format with the .bpvs extension (Binary Potentially Visible Set).
  8. Mesh data is written to disk as a proprietary binary format. In addition to optimising vertex attribute layout (and size), certain material data is also packed in as vertex attributes to allow more aggressive draw call merging. For example if two materials only differ in textures and a tint colour, then the textures are packed into the texture array and the tint colour is packed into a vertex attribute. For billboard quads, the world position of the pivot point is also baked, allowing the quads to be rotated independently even when merged.
  9. Asset bundles for the textures are generated or updated containing the assets required, to make it easy to load the textures at runtime

The editor tooling also included ways of previewing visibility at edit time by dropping in a gizmo “camera” that could be moved or rotated.

Build Time Stripping

When the level is built (including play in editor) it is automatically stripped of static mesh renderers that are rendered by BLAST. This process was fairly aggressive, stripping empty game objects and containers, leaving typically static colliders behind.

Collision is also simplified where possible. Coplanar colliders such as box colliders on walls were also automatically merged up to a certain distance limit.

This automatic stripping was one of the key requirements to ensure main thread integration time remained low when loading chunks in. (Note that scene load was entirely separate to BLAST loading in its own dependencies as you walk around cells and was mainly for the collision as well as dynamic objects not covered by BLAST).

Runtime

Player Perspective
No Culling
BLAST's Culling
Unity's Default Renderer
BLAST's Sorted

On mission load, BLAST initialises by loading the binary potentially visible set, which is then parsed into an efficient runtime data structure. I believe binary meshes and possibly some other resources (like reflection probes) also get loaded on mission load due to how fast it was to load them and the relatively high available memory on the Quest headset. Binary meshes are often repeated kit pieces, so many of them would be needed within the first few voxels anyway. Texture arrays are also allocated to the size of the maximum number of textures that are visible from a voxel, plus a small buffer so that we aren’t forced to immediately unload textures at high water moment areas and potentially end up in a streaming ping pong situation if a player is ducking in and out of cover.

As the player progresses through cells a number of operations occur. Firstly, we load any missing resources. Textures are streamed in from asset bundles, blitted into the correct texture array cell then the source texture unloaded. If textures have been previously loaded into texture array cells then the cell that hasn’t been used in the longest time is allocated to the new texture. BLAST tracks what textures are loaded in each texture array cell, marking cells as available if the player moves to a cell which doesn’t require that texture. The texture is still retained in memory however, in case the player then moves to a cell which needs it again. Note that BLAST intentionally doesn’t load all textures from a level into memory in order to keep memory usage more balanced.

A number of Burst compiled jobs are then initialised, with some dependencies between them. These jobs update the native mesh buffers, copying in the correct mesh data and setting the texture array index as a vertex attribute for all the vertices that match each material. Once the meshes are ready they are applied and begin rendering instead of the previous merged mesh. This process takes approximately 4 frames inclusive of the frame starting the jobs and the frame applying the final mesh.

Like the addition of culling dynamic objects based on containing cell visibility, another late addition was a form of coarse frustum culling. Meshes are classified in relation to the cell centre into 8 horizontal directions (cardinals + diagonals). Meshes that are very close or above/below are classified as visible in all directions. As the player turns their head we turn on/off the directions and update the mesh. This is fairly conservative in its tolerances due to the 4 frame delay, but again provided a small but measurable benefit.

Limitations

Certain assumptions in BLAST’s approach were made in 2019, assuming that the team would be working in an office full-time. Of course in early 2020, with Covid-19 these assumptions were instantly invalidated. In hindsight, I would have taken a different approach with some of BLAST’s architecture knowing that we were going to need to work remote first with people’s variable internet connections between their development machines and the office.

BLAST would also have benefited from a longer lead time before being used in production. A lot of the workflow challenges we faced were symptomatic of “flying the plane while building it”. Though this is a common problem in game development and certainly not unique to Battle Sister’s development. As a counter argument, BLAST’s development benefited from feedback from developers using it actively and with real world levels.

While the bucketing approach worked relatively well, not allowing looser texture sizes was somewhat constraining. In certain cases smaller textures were upscaled to prevent a bucket split. Looking forward, bindless rendering may be a better solution in the future to these kinds of problems.

While BLAST made rendering vastly more efficient it didn’t have any handling of vistas or playable level areas in the distance. Some form of HLOD integration (with proxy mesh generation via Simplygon) would have greatly expanded the quality and potential of large environments.

A considerable pain point for level design and environment art were that BLAST bakes were slow. Taking multiple samples per voxel across the size of Battle Sister’s levels, then classifying all the data could take a couple of hours for a large level. Considerable effort was put into optimising BLAST bakes but as levels grew in complexity and BLAST’s new capabilities also extended baking requirements it became a one step forward - one step backward situation.

Further to the bake time problems, BLAST did not provide an effective way to play these levels natively on Quest without a BLAST bake, resulting in a large iteration time loop. This was compounded with a similar problem with lightbakes, so wasn’t isolated to BLAST, but was far from an ideal workflow.

BLAST was also very picky about the format of meshes and textures it would ingest, requiring them to match in certain rules. For example BLAST could only merge textures into texture arrays at runtime if the ASTC compression level matched. This resulted in a very complicated validator to pick up issues that would prevent baking or cause runtime mismatches, given more time BLAST could have been developed to be more lenient and flexible with the data it ingested as well as creating better import pipelines.

Conclusion

Looking at RenderDoc captures from Battle Sister on Oculus Quest showed just how optimal environments were, not just in draw call count but in how tightly culled and well sorted the geometry being rendered was. This efficiency gave us huge amounts of budget to spend elsewhere on gameplay and VFX.

On reflection, I feel that BLAST over-optimised for the problem space and that we could have accepted a simpler workflow with coarser merging and less optimal fillrate. While this would have meant less budget for the rest of the game, the iteration speed boosts would have been worth it.

Finally, creating BLAST is one of the highlights of my career. I am hugely proud of what we accomplished with Battle Sister, as well as BLAST’s role in getting the game to performance.

]]>Barnaby SmithDesign Principles for VR Games2023-05-26T00:00:00+00:002023-05-26T00:00:00+00:00http://mvinetwork.co.uk/2023/05/26/design-principles-for-vr-gamesThis talk was originally given at University of Warwick.

]]>Barnaby SmithNotes for Unity Docs, 3 years on2020-12-01T00:00:00+00:002020-12-01T00:00:00+00:00http://mvinetwork.co.uk/2020/12/01/notes-for-unity-docs-3-years-on

It’s been a little over 3 years since I created a Chrome extension for shared notes on Unity Docs pages. In that time 465 notes have been posted by 111 different users! And every single note adds something meaningful to those pages, whether it’s a usage example, undocumented gotcha, example output, or a detailed writeup on a topic.

The notes are moderated by myself and my good friend Thom Ingram, but we’ve been fortunate that very little moderation needs to take place. The quality of the notes in particular are very high and it’s a fantastic feeling when working on a problem to load up the doc page and see a helpful comment that saves you hours of time.

Thank you to everyone who has posted a note or downloaded the extension. I’m also thankful for the lovely Unity Docs team for their support and I’m looking forward to reaching 500 notes soon!

If you’re a Chrome user and haven’t got the Chrome extension already you can download it here.

]]>Barnaby SmithIntroducing User Contributed Notes for Unity Docs2017-08-21T00:00:00+00:002017-08-21T00:00:00+00:00http://mvinetwork.co.uk/2017/08/21/introducing-user-contributed-notes-for-unity-docs

After years of wanting to be able to post and see user notes (such as examples, gotchas, additional detail) on Unity Docs I finally bit the bullet and wrote a browser extension for Chrome that allows you to comment on individual pages – Chrome

]]>Barnaby Smith5 Years Of #UnityTips2017-05-24T00:00:00+00:002017-05-24T00:00:00+00:00http://mvinetwork.co.uk/2017/05/24/5-years-of-unitytips5 years ago I set up a webpage which runs several times a day and pulls out all tweets using the following hashtags:

#UnityTip #UnityTips #Unity3DTip #Unity3DTips

At the time there wasn’t a standardised hashtag as #UnityTips has become now, so all of the four above were in use.

After a slow start the hashtag really exploded when Unity started #UnityTips Tuesday in May 2015 and that hashtag became the de facto standard.

To celebrate the 5 year mark I’ve gone through the database and created a list of 25 of the best #UnityTips that Unity developers have shared.

But first, let’s start with the most popular Unity Tip of all time, with over 7000 retweets!

How to fix z-fighting

And onto our 25 top tips:

Inspector Locking

See internal state with Debug Inspector

Add additional inspectors

Many fields support maths calculations

Better understand colour blindness with this image effect

Layers and tags support nesting

Profiler supports reordering groups

Export Substances into textures to permanently bake the substances in editor

Original Tweet Deleted: To convert a Substance to Standard Material in #Unity3d: From Inspector, select Cog Icon → Export Bitmaps

Alt click to expand/collapse recursively in tree views

Use ContextMenu attribute to add inspector methods to your own components

Original Tweet Deleted: Use the ContextMenu Attribute to execute methods in the editor.

Use [MenuItem] with CONTEXT to add inspector methods to built in components

Use [CreateAssetMenu] to add your scriptable object to the Create/ menu, avoiding boilerplate creation code

Add custom icons to a script and their instances through the inspector

Alternatively set icons for components by using the Gizmos/ folder

Restore scenes after a crash

Use Reset() to automatically hook up references or state

Hide/disable dependent fields in Inspector with Brecht Lecluyse’s attribute

Skyblade’s ScriptExecutionOrder attribute allows you to set order programatically

Set AudioSource pitch to negative to play backwards

Alt drag a scene into the hierarchy to add it an unloaded state

Use Editor.CreateEditor() to embed editors for scriptable objects or other objects

Create Colour Preset Libraries in Project to share them in source control

Use Copy/Paste Component to copy settings from play mode to edit time

Save and restore your selection with these shortcuts

Use the EditorOnly tag to strip out objects at build time

Thanks for reading these tips, I hope they were useful and remember to tweet your own tips using #UnityTips

For more Unity tips and tricks be sure to follow me on Twitter:

Follow @mvinetwork

]]>Barnaby SmithProcedural Planet Rendering2014-06-05T00:00:00+00:002014-06-05T00:00:00+00:00http://mvinetwork.co.uk/2014/06/05/procedural-planet-renderingThis talk was originally given at LUUG 29 (London Unity User Group) at University of Greenwich.

]]>Barnaby SmithColour Code Snippets2013-05-27T00:00:00+00:002013-05-27T00:00:00+00:00http://mvinetwork.co.uk/2013/05/27/colour-code-snippetsI’ve previously produced a number of mod tools for Dune 2000 that convert colours from various formats to 24 bit and back. Although most of the source code is already online, I thought I’d share the colour conversion C# source code in one place.

Convert 15 bit high colour to 24 bit true colour

This converts 15 bit (with 1 bit padding) colour to 24 bit, by first extracting the red, green and blue channels. In 15 bit colour, each channel has 5 bits meaning 25 = 32 permutations, but we want 8 bit colour for each channel which is 28 = 256 permutations, so we divide by the highest 5 bit value and multiply by the highest 8 bit value to convert the range from 0-31 to 0-255.

private Color ConvertColor(UInt16 colour)
{
    // bits = XRRRRRGGGGGBBBBB
    byte red = (byte)((colour >> 10) & 0x1f);
    byte green = (byte)((colour >> 5) & 0x1f);
    byte blue = (byte)(colour & 0x1f);
 
    red = Convert.ToByte(255.0f * (float)red / 31);
    green = Convert.ToByte(255.0f * (float)green / 31);
    blue = Convert.ToByte(255.0f * (float)blue / 31);
 
    return Color.FromArgb(red, green, blue);
}

Convert 24 bit true colour to 15 bit high colour

Similarly to convert to 15 bit, we convert each channel from 8 bit to 5 bit. Then we bit shift the red and green values and combine the three channels using a bitwise OR, so that we can fit all three 5 bit channels in the format XRRRRRGGGGGBBBBB.

private UInt16 ConvertColor(Color colour)
{
    int r = (int)((colour.R / 255.0f) * 31) << 10;
    int g = (int)((colour.G / 255.0f) * 31) << 5;
    int b = (int)((colour.B / 255.0f) * 31);
 
    int combined = r | g | b;
    return Convert.ToUInt16(combined);
}

Convert 24 bit true colour to existing palette

This algorithm calculates the entry in an existing palette which is closest to the target colour. The algorithm treats colours as points in 3 dimensional space – instead of x,y,z we use r,g,b – and uses Euclidean Distance (the distance in a straight line between two points) to calculate the closest colour. For efficiency, all distances are kept at their square values, since it is not necessary to use the relatively expensive square root operation in distance comparisons. The assumption here is that the palette is 24 bit, however if you have a 15 bit palette you could use the conversion technique described above to convert it to a 24 bit palette.

Color[] palette = new Color[256];
 
int GetNearestColorIndex(Color targetColor)
{
    int index = 0;
    // Set the initial color distance to the maximum
    double currentDistance = (255 * 255) * 3;
    Color paletteColor;
    for (int i = 0; i < palette.Length; i++)
    {
        paletteColor = palette[i];
        int redDistance = paletteColor.R - targetColor.R;
        int greenDistance = paletteColor.G - targetColor.G;
        int blueDistance = paletteColor.B - targetColor.B;
 
        // Calculate the square distance from the target colour to this palette entry
        int distance = (redDistance * redDistance) +
                            (greenDistance * greenDistance) +
                            (blueDistance * blueDistance);
 
        if (distance < currentDistance)
        {
            index = i;
            currentDistance = distance;
        }
    }
    return index;
}

Color GetNearestColor(Color targetColor)
{
    return palette[GetNearestColorIndex(targetColor)];
}
]]>Barnaby SmithCore Concepts Of Reverse Engineering: Part 5 – Data Types Practical2012-02-12T00:00:00+00:002012-02-12T00:00:00+00:00http://mvinetwork.co.uk/2012/02/12/core-concepts-of-reverse-engineering-part-5-data-types-practicalIn the last article I talked about some theory of how data types are stored in binary. Of particular importance were the concepts of endianness which defines the order of the bytes that make up a data type. This article will use XVI32 to practice determining and changing the values of data entries which make use of some of the data types we discussed in the last article.

Determining Data Values

I’ve put together a small sample file for this article, before continuing you’ll need to download it and open it in XVI32.

Download here

Once you have the file open in XVI32 you should see the hex and text values in the above screenshot.

To make this article more straightforward I’m going to tell you the actual structure of this file:

Remember that there are 8 bits to a byte, so get the number of bytes in a 32 bit integer you divide 32 by 8 and get 4.

In this part of the practical, you need to answer four questions:

  1. What is the decimal (base 10) value of the byte at offset 0?
  2. What is the decimal (base 10) value of the little-endian int16 at offset 1?
  3. What is the decimal (base 10) value of the big-endian int32 at offset 3?
  4. What is the decimal (base 10) value of the little-endian int32 at offset 7?

Tips for the struggling

If you struggle with question 1, reread part 2.

If you struggle with questions 2 or 4, reread part 4.

If you struggle with question 3, remember that the conversion is the same as for little-endian numbers only you don’t need to bother with reversing the order of the bytes.

Answers

The answers can be found here. If you didn’t get the same answer, check out the tips above.

Changing Data Values

Before starting this section, you need to make sure you’ve completed the questions above and got the correct answers to every question.

In this section, we want to change the values of the data entries encoded in this sample file. If you want to refresh your memory of making hex edits with XVI32, reread part 3 now. Remember to use overwrite mode in XVI32 rather than insert.

Again we have four exercises:

  1. Change the value of the byte to 54 (expressed as a decimal integer)
  2. Change the value of the little-endian int16 to 40 (expressed as a decimal integer)
  3. Change the value of the big-endian int32 to EDA0 (expressed as a hexadecimal)
  4. Change the value of the little-endian int32 to 6767 (expressed as a decimal integer)

If you struggle with any of these questions, the best idea is to reread the previous articles.

Answers

The answers can be found here. Open this file in XVI32 to compare against your own edits.

In this article you’ve determined the values of different data types and also changed those values. The skill you’ve just picked up means that you’re now able to hex edit a large range of data and files. Being able to determine the value of and edit data which occupies more than one byte is the most core practical skill in hex editing and reverse engineering binary files.

]]>Barnaby SmithCore Concepts Of Reverse Engineering: Part 3 – File Headers and Basic Hex Editing2012-02-04T00:00:00+00:002012-02-04T00:00:00+00:00http://mvinetwork.co.uk/2012/02/04/core-concepts-of-reverse-engineering-part-3-file-headers-and-basic-hex-editingIn the last post I discussed why hex editors are useful for working with binary files. I also talked about XVI32 my free hex editor of choice. During this series I will be using XVI32 for examples, so if you are not on a Windows machine or if you want to use a different hex editor then you will need to adapt my examples.

So if you haven’t done so already, download XVI32. XVI32 doesn’t need installing, you can just unzip it and run it from there but you may want to copy it to a more memorable location and set up any relevant shortcuts.

In this post I’ll be taking more of a practical approach, I’ll start by talking about file signatures and then we’ll open up a few common file formats and take a look inside.

File Signatures

An extension does not make a type.

Or to put it more clearly, just because a file has the extension .png doesn’t mean there’s actually a png image inside. This is a very important lesson, since it is incredibly common for games just to give a common file format a different extension. When I was browsing the Call of Duty 4 files I realised instantly when I opened a file format up in a hex editor that it was just a zip with a different extension, meaning I could unzip it and see the files inside.

So how did I realise it was a zip at a glance? What kind of technomagery is this? Many files have a signature at the very start saying what format they’re in. It doesn’t matter what the file is called or what extension it has, if it has a signature then you have a way of identifying the file type. These are often called magic numbers because a piece of text can be represented as a sufficiently long number. In fact, any and all data can be considered just a very, very long number, but I may be straying off the point.

There are a number of very common file signatures you’ll see, including:

Signature Hex Type
MZ   Executeable code (.exe)
PK 50 4B 03 04 Compressed Zip (.zip)
Rar!   Compressed Rar
BM   Bitmap Image (.bmp)
  FF D8 FF E0 ** ** 4A 4649 46 00 JPEG Image (.jpg, .jpeg)
%PDF 25 50 44 46 PDF Document (.pdf)
‰PNG   PNG Image (.png)
OggS   Ogg Vorbis Media e.g. audio, video (.ogg)

For a more extensive list of file signatures check this page out.

Some Examples

Before continuing there are three examples you need to download, in the case of the images you will need to right click the link and hit “save as” or the equivalent option on your browser.

Now for each of the examples, I want you to open it up in XVI32 and have a look inside.

Example 1

Once we open the first example in XVI32 we see that the file header starts with the per mil symbol followed by PNG in the text view. This file clearly is a PNG image.

Example 2

With example two, we see that the file signature is PK (named after the format’s author Phil Katz, but I often translate PK as Packed). This file is a zip as we can see in the table of signatures above.

Example 3

The final example has the file signature BM and is therefore a bitmap image. Ignore the F, that byte is actually part of a variable in the bitmap format that says how big the file is.

Example 3 In Depth

Let’s take a deeper look at the third example now that you’ve got it open. We know that the file is a bitmap image, so let’s take a look at it in Windows Photo Viewer. It’s a small image so you’ll have to zoom in.

If we open up the file in Paint, view it in Explorer or open its properties we’ll see the file is a 2 by 2 pixel image. I’ve created this small image to demonstrate the format more simply.

File Headers

In addition to the file signature, most files have a file header which includes some basic information about the file. In the case of an image this may include its dimensions and colour depth/quality. In the case of audio this may be the duration, number of channels and bit rate.

In the above image I’ve highlighted the file’s header. In the case of a Windows Bitmap the file header is 54 bytes long. To highlight a section in XVI32, select the first byte then select Edit -> Block chars and type 54 in decimal mode.

You can see a couple of 02’s in the header, so a reasonable assumption would be one represents width and one represents height. We can also see an 0x18 which as a decimal is 24, so another reasonable assumption is that this is the colour depth specifying 24 bit colour. For now don’t worry about colour depth, I’ll talk about colour in a dedicated article later in this series.

After the header we have 16 bytes. Now we know there are four pixels (2×2) pixels in the image, so it’d be sensible to assume that those four pixels are represented in these 16 bytes.

Opening the file in Paint, we can use the dropper tool to pick the colour of each pixel. By going to edit colour, we can then see the colour in its red, green and blue components. You can do this manually, or use the figures I’ve shown below. I’ve also converted the values to hex for you.

Top Left

Decimal Hex  
Red 34 22
Green 177 B1
Blue 76 4C

Top Right

Decimal Hex  
Red 255 FF
Green 242 F2
Blue 0 00

Bottom Left

Decimal Hex  
Red 255 FF
Green 127 7F
Blue 39 27

Bottom Right

Decimal Hex  
Red 237 ED
Green 28 1C
Blue 36 24

Now using the hex values worked out for each colour, we can spot them in the file. We can spot each three, in reverse order displayed as Blue, Green then Red. The reason for this different ordering is something I’ll talk about in a later article. We can also see that the bottom left pixel is first, followed by the bottom right pixel, then followed by two 00 bytes. Immediately after is the top left pixel, followed by the top right pixel and two more null (00) bytes.

Ignore the two sets of two null bytes, these are due to a nuance of a the bitmap format which means that it must pad the number of bytes representing a row of pixels to a multiple of 4 (so in this case we have 6 bytes representing a row, so it adds on 2 blank bytes to reach a total of 8 bytes and therefore a multiple of 4).

Editing Data

So now that we know where the colour data is in the file, let’s try changing it.

Let’s pick the top right pixel, which is yellow. Let’s change it to blue. Right now its represented as 00 F2 FF, so since this is in Blue Green Red order rather than Red Green Blue, changing the value to FF 00 00 will be a strong blue. To edit the values select the first byte in the “00 F2 FF” sequence and make sure that it says Overwrite in the status bar. If it says Insert then tap the insert key once. The insert key toggles between Overwrite and Insert modes. Now simply type FF 00 00 on your keyboard and hit save.

Opening the file up in Windows Photo Viewer and zooming in, we now see that the top right pixel is blue.

Congratulations, you have made your first successful and practical edit in a hex editor!

In this article, I’ve talked briefly about how to identify common file types regardless of their file extension. I’ve also shown some basic hex editing in a practical example – editing a bitmap image. In the next example I’m going to go into data types which combine multiple bytes to represent larger numbers.

]]>Barnaby SmithCore Concepts Of Reverse Engineering: Part 4 – Data Types2012-02-04T00:00:00+00:002012-02-04T00:00:00+00:00http://mvinetwork.co.uk/2012/02/04/core-concepts-of-reverse-engineering-part-4-data-typesA Brief Intro

The last post gave a practical example of hex editing. In the post before that I talked about bytes and hexadecimal numbers. This post continues that discussion of theory.

With regard to hexadecimal numbers, its important to note that you don’t need to be able to convert between hexadecimal and decimal in your head, or even on paper, using a calculator for the conversion is fine. All that’s important is to know that the same number can be written both as a decimal and as a hexadecimal. For example if I had a byte in my file which has the value AB, as a decimal this is 171. You may sometimes see numbers prefixed with 0x like 0xAB, this is simply standard notation for a hexadecimal number.

While being able to store a value up to 255 in a byte is useful, being able to store larger numbers is more useful. In this post, I shall discuss some basic types.

Signed and Unsigned Numbers

In mathematics, numbers can be either positive or negative. In computing, sometimes we’ll want numbers that can be either positive or negative, or sometimes we know that a number will always only ever be positive. Why differentiate the two you might ask? Storing whether a number is positive or negative takes up a small amount of data (specifically one bit). If all numbers were treated this way, we would be able to hold a smaller range of data even if we knew that data would never be negative, which while a small limitation is still wasteful.

Signed numbers are numbers which can be considered to have a positive/negative sign information. Supporting negative numbers comes at the expense of a smaller range of numbers that can be represented.

Unsigned numbers are numbers which must be of the same sign (typically positive). These numbers can support a larger range but at the cost of not being able to store both positive and negative values.

Integers

Integers are one of the most basic and ubiquitous data types in computing. They represent whole numbers such as 1, 5, 98 and cannot store fractional numbers such as 0.24, 1.7, 5.5. Integers can be signed or unsigned and come in various sizes. The most common sizes of ints are 16 bit, 32 bit and 64 bit. The number of bits refers to the size that the integer occupies, there are 8 bits to a byte and therefore a 16 bit integer is 2 bytes and a 32 bit integer is 4 bytes. By combining bytes together we extend the range of the data type significantly, the more bytes there are the more variations that can be stored. In the table below I show the range of the above three types of ints as both signed and unsigned numbers.

Little/Big Endian

When it came to writing say the number 123 as a hexadecimal byte, it was quite straight forward. We just worked out it was 7B using the calculator and that was it. If we now take the number 1234 which is bigger than the maximum value a byte can hold (255), we clearly now need to use an integer. So lets take a 32 bit integer which consists of four bytes. So if you put 1234 into your calculator and convert to hex you’ll get the result 4D2. If we stick some zeroes in front of it to occupy four bytes we would then get 00 00 04 D2. That’s great and this is a viable way of writing an integer however its not the only way.

Big endian means that the high numbers come first and the low numbers come last. For example with 1234, it’s quite a small number compared to what a 32 bit int can hold so its on the right side. Larger numbers would occupy further numbers towards the left.

Little endian numbers reverse the byte ordering so that the above example would be written as D2 04 00 00.

Its common for x86 architecture (PC) files and Intel Macs to be little endian and for PowerPC Macs and UNIX to use big endian. Particular file formats may choose to use little or big endian regardless of the architecture and operating system, however as a starting point I would assume the endianess matches the architecture.

In the case of Dune 2000 and most PC formats, files are stored in little endian. If you would like to read more about endianess try here.

Converting from decimal to a little endian 32 bit integer

  1. Convert to hex using calculator
  2. Prefix with ‘0’s until the number is represented as 4 bytes. (Has the structure 00 00 00 00).
  3. Reverse the bytes, each grouping is a byte. So 12 34 56 AB becomes AB 56 34 12

Converting from a little endian 32 bit integer to decimal

  1. Reverse the bytes, so AB 56 34 12 becomes 12 34 56 AB
  2. Convert to decimal using calculator

Bit Representations in Bytes

A byte is made up of 8 bits. Each bit holds a 1 or 0 value, so a byte that holds the value zero can be represented as 00000000. The value that each digit represents doubles from right to left, starting at 1.

Adding across we have zero lots of each number, so a byte with the bit representation 00000000 = 0 If we take a byte who’s bits have a value of 11111111 and use the above grid, we get:

Adding across we get 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1

Which if we add it up, we find that a byte with a bit representation of 11111111 is 255 – the max value of a byte. The number of bits is the reason for the number of variations a number can hold. Try continuing the table across to represent 16 bits rather than 8 bits, add up all the top row numbers and compare against the integer data type table above.

Let’s take another example:

A byte with bit representation 00110010

Adding across again we get 32 + 16 + 2 = 50

Bit Fields

While the above usage of bits in a byte is the most common, it can be considered just one possible interpretation of the bits in the byte. Data only has meaning when we give it meaning. For example we could say rather than the right most bit representing the value 1, it could mean whether or not a tank can move onto a terrain tile. We could then say that the second to right byte which represents the value 2 can mean whether a player can build structures on this terrain tile. This usage of the bits in a byte is called a bit field. While bit fields are decreasing in usage now that data limits are getting higher and higher, they still have importance in many areas where small data sizes are critical.

Sub-byte data types

On a related note, you may want to hold more data than a simple true/false but want to use less data than a full byte. If say your maximum value was 15, then you’d only need 4 bits. You could then hold two different 4 bit variables in a single byte, one after the other. Alternatively, if you needed to hold a number with a ranger larger than a byte but smaller than 2 bytes, say a 12 bit number and you also wanted to hold a 4 bit number, you could combine the two by making use of 2 bytes. The first number occupying the first byte and the first half of the second byte, while the second number occupies the second half of the second byte. The below table shows the first number in red and the second number in green.

What’s next?

This post has been quite heavy in theory, in the next post I will explore data types through practical examples. So if you felt this was a lot to take in, don’t worry there will be opportunity to practice what I’ve talked about here and hopefully make sure you get your head around it.

]]>Barnaby Smith