https://github.com/binsync/example.bsproj
An example BinSync project for testing and validation
https://github.com/binsync/example.bsproj
Last synced: 5 months ago
JSON representation
An example BinSync project for testing and validation
- Host: GitHub
- URL: https://github.com/binsync/example.bsproj
- Owner: binsync
- Created: 2024-03-09T19:00:14.000Z (over 2 years ago)
- Default Branch: binsync/__root__
- Last Pushed: 2025-10-08T00:52:50.000Z (9 months ago)
- Last Synced: 2025-10-08T02:44:39.696Z (9 months ago)
- Size: 58.6 KB
- Stars: 0
- Watchers: 1
- Forks: 4
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Example BinSync Project
An example BinSync project for testing and validation
## BinSync Project Format
A BinSync project is a directory (folder) that is a Git project and conatins at least 2 things:
1. a `binsync/root` branch
2. a `binay_hash`: a md5 hash of the thing you are reversing (in that root branch)
After this every branch starting with `binsync/` is a User branch containg user artifact changes.
Each branch layout will look something like this depending on what the user has worked on:
```tree
.
├── structs
│ └── mahaloz_struct.toml
├── patches.toml
├── metadata.toml
├── global_vars.toml
├── functions
│ └── 0040071d.toml
├── enums.toml
├── comments.toml
└── binary_hash
```
Each toml describes the changes the user has made as well as timestamps and commits.
A good example branch to look at is the [binsync/mahaloz](https://github.com/binsync/example.bsproj/tree/binsync/mahaloz) branch which contains a few changes in functions and structs.
## Good practice
- put the binary people are reversing in the `main` branch or any non `binsync/` branch, since that file may be copied
- ALWAYS when you work on the binary in your decompiler, first copy it out of here so files like ida files dont polute the repo