Inspiration
I was very frustrated with the speed as well as the time and disk space that modern disassemblers take when it comes to creating readable assembly from an executable. With slightly faster disassemblers priced a ridiculous amount, it seemed very difficult to have a tool that is free, open-source, and is able to make light-work of a executable when I needed it to.
What it does
lzd uses a lazy region-based disassembling technique, where instead of disassembling the entire binary, it is parsed into smaller regions that are then passed to worker threads that specifically handle that region and disassemble it asynchronously. Additionally lzd can parse symbols, as well as strings and tokens even quicker, allowing for users to provide a binary and have a disassembly within milliseconds.
How we built it
I build lzd using c17, ncurses (a terminal-based-ui library) as well as capstone (decoding engine).
Challenges we ran into
When using capstone as a github submodule, there were various issues with linking and Makefile mis-interpreting which library was to be linked (apt or vendor/), causing me to spend roughly 2 hours attempting to fix the build issue. This reduced the amount of time I could have spent making extra features and improving my program.
Accomplishments that we're proud of
This is a posix compliant software that can disassemble any elf-based executable regardless of the home system being unix-based or not. In comparison to competitors like Ghidra or IDA (which costs a ridiculous amount), lzd is a simple, fast, and efficient solution that runs using 1/20th the memory and disk space required per executable, while also being able to disassemble in a fraction of a second.
What we learned
Take things piece by piece and break them down into smaller digestible chunks so that my progress is more developmental and slow instead of sporadic. This took a large toll on my time and effort when it came to writing and figuring out some of the code required for this project.
What's next for The Lazy Disassembler
I simply wish I had more time to be able to improve the project even more to add things like semantic analysis (e.g. replacing target names and properly decompiling recognized opcode sequences), target more little-endian based architectures (powerpc & risc-v64) as well as target dwarf and runpe executables so that the program that is posix-compliant can read any operating systems binaries regardless of it being the home system. All of these I will end up doing since this is a project I have wanted to make for a while now and have finally got the time to do so.
Log in or sign up for Devpost to join the conversation.