Skip to content

Latest commit

 

History

History
91 lines (71 loc) · 4.13 KB

README.md

File metadata and controls

91 lines (71 loc) · 4.13 KB
Raw

hlbc

Hashlink bytecode tools


This repository contains a collection of Rust crates and cli tools to load, disassemble, decompile and analyze Hashlink bytecode.




About

Hashlink is a VM used as a compilation target for the Haxe language. Hashlink is successfully used to run popular games from developer Shiro Games like Northgard, Dune: Spice Wars and Wartales.

hlbc intends to help the motivated to develop mods and tools for those games.

Those games are packaged with the following model :

  • <game>.exe: A very light executable that contains the Hashlink VM
  • hlboot.dat: The actual bytecode file Hashlink is configured to load on startup. This is the file you want to load in hlbc. It doesn't contain any game assets, this is just code.
  • <lib>.hdll: This is your average native code dll, except it can work with the VM.

Repository structure

  • data/ : Haxe source files to test the tools
  • crates/hlbc/ : Core library to load and disassemble bytecode
  • crates/cli/ : CLI frontend for hlbc
  • crates/decompiler/ : Decompiler library
  • crates/derive/ : helper proc macros for hlbc
  • crates/gui/ : GUI to explore bytecode visually
  • crates/indexing/ : bits and pieces to search through the bytecode

Wiki

A wiki detailing the specifics of Hashlink bytecode is available here or by using the command wiki in the CLI.

Planned

  • Finishing the decompiler (for loops mainly)
  • C API
  • Adding more features to the GUI and improving UX
  • Looking for a better GUI framework

Contact

Questions ? Inquiries ? Help ? Use GitHub discussions, send an email or Discord : limelion.

Credits & references

Development of this project would not have been possible without the hashlink source code. Most of the deserialization code is directly adapted from the original C code reading bytecode files. There is no real documentation for the bytecode or the inner workings of Hashlink, so reading through the source code was the main source of information.

There are also 2 blog articles on the Haxe website that proved to be interesting albeit a bit outdated :

Why Rust

I should probably have used Haxe in the first place, that would have been the logical choice as tooling for a language is best done (I suppose) in that same language. But Rust makes it a joy to develop with its enums, match statements and macros (I think those features are present in Haxe too, although I'm not at all familiar with this language). Also, the Rust ecosystem feels much more alive.

One of the downside of using Rust here is that I can't pass references everywhere. The bytecode is a large graph where every element can reference another, this by definition does not play well with Rust borrow-checking rules. To cope with this, bytecode handling is working with the arena pattern. The Bytecode struct owns every element and we use indexes ( wrapped in custom types) throughout the codebase. This might be a bit cumbersome to pass code: &Bytecode and calling code.get() everywhere but it works without ever dealing with lifetimes anywhere.