https://github.com/gui-yom/hlbc
Hashlink bytecode disassembler, analyzer, decompiler and assembler.
https://github.com/gui-yom/hlbc
analysis bytecode cli decompiler disassembler gui hashlink haxe
Last synced: 3 months ago
JSON representation
Hashlink bytecode disassembler, analyzer, decompiler and assembler.
- Host: GitHub
- URL: https://github.com/gui-yom/hlbc
- Owner: Gui-Yom
- License: mit
- Created: 2022-05-08T23:25:48.000Z (over 3 years ago)
- Default Branch: master
- Last Pushed: 2024-08-14T18:56:52.000Z (about 1 year ago)
- Last Synced: 2025-07-01T23:07:50.306Z (3 months ago)
- Topics: analysis, bytecode, cli, decompiler, disassembler, gui, hashlink, haxe
- Language: Rust
- Homepage: https://gui-yom.github.io/hlbc/
- Size: 1.3 MB
- Stars: 70
- Watchers: 3
- Forks: 11
- Open Issues: 7
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
Hashlink bytecode tools
This repository contains a collection of Rust crates and cli tools to load, disassemble, decompile and
analyze Hashlink bytecode.
## About
[Hashlink](https://hashlink.haxe.org/) is a VM used as a compilation target for the Haxe language. Hashlink is
successfully used to run popular games from developer [**Shiro Games**](https://shirogames.com/) 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 :
- `.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.
- `.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](https://github.com/Gui-Yom/hlbc/wiki) 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](https://github.com/HaxeFoundation/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 :
- https://haxe.org/blog/hashlink-indepth/
- https://haxe.org/blog/hashlink-in-depth-p2/
## 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.