Here is a list of some of the projects I am either currently worked on, or just liked enough to mention :). This list will be expanded in the future since I tend to pick up new projects all the time.

Thank you for your support. Any money I recieve as a donation will go directly into edb's development.

— or —
Donate BTC 12z3uWcWNLHnLYzDJdSCdJhCiTAbrYT13q
edb logo Qt Ambassador

Debugger - Download Here - 0.9.20



I am happy to announce that version 0.9.20 of edb is available under the GPL-2 license for download! This version supports x86 and x86-64 architectures. Please give it a try and let me know what I can do to improve it. Documentation is pretty much non-existant, but that's one of the reasons why this is not a 1.0 release :). Remember to read the README file, it has a lot of information, and please check the bugzilla before asking about a missing feature, it may already be in the works. Enjoy!

Source Repository

edb now has a publically readable subversion repository. For those out there who want to contribute, this is a great place to start!


I have produced an edbuild for all you Gentoo users out there. The easiest way to use it is to do the following (as root):

mkdir -p /usr/local/portage/edb/dev-util/edb/ cp edb-0.9.20.ebuild /usr/local/portage/edb/dev-util/edb/ echo PORTDIR_OVERLAY=\"\${PORTDIR_OVERLAY} /usr/local/portage/edb\" >> /etc/make.conf cd /usr/local/portage/edb/dev-util/edb/ ebuild edb-0.9.20.ebuild digest ACCEPT_KEYWORDS=~x86 emerge -a dev-util/edb


I do a lot of work analyzing applications which I do not have the source code for. On Windows, OllyDbg is my tool of choice, but there is no Linux (or any other *nix) equivalent that I could find. Sure we have GDB, but GDB and all it's various frontends tend to lean towards debugging applications to which we have the source. What I really want is a debugger which is as functional and useable as OllyDbg but for Linux (and possibly more). So I started my own debugger which is currently based on the ptrace API. The hex dump views are based on the QHexView I developed which gives things a very polished look.


One of the main goals of this debugger is modularity. The interface is written in Qt4 and is therefore source portable to many platforms. The debugger core is a plugin and the platform specific code is isolated to just a few files, porting to a new OS would require porting these few files and implementing a plugin which implements the DebuggerCoreInterface interface. Also, because the plugins are based on the QPlugin API, and do their work through the DebuggerCoreInterface object, they are almost always portable with just a simple recompile.

The disassembly engine is my edisassm project. I feel that this disassembler is mature and works well. It is worth noting that the current version of edb has temporarily dropped AT&T syntax support. Once this is implemented in edisassm, it will return.

Bug Reporting

Bugs & requests are now tracked in bugzilla set up at Please post any bugs you find or features you would like me to try to implement there.



Some screen shots

QGMailNotifier - Check it out on github


This is my operating system. It is written in c++ with a tiny bit of assembly. My primary goal is to make a usable and useful operating system which is truly designed from the ground up to secure and flexible. Its design is influenced by a few Operating Systems. I plan to have a UNIX like filesystem, which will have the notion of "devices are files" but devices will live in there own namespace. For example, the first hard disk will be available as: "device:///hard_disk/0" and will not be normally part of the actual filesystem. Similarly, instead of a "/proc/" filesystem, I have "process:///". However, a user will be able to reproduce a UNIX like /dev by mounting "device:///" to "/dev."

I plan to have the normal way of creating processes be somewhat like Win32, and not use fork/execve. This is simpler to work with from a programmers point of view. I do however plan to have fork/execve available in order to increase compatibility the vast library of existing UNIX applications.

In its current state, evanOS runs in long mode, and is 64-bit. It supports multiple processes/threads, semaphores, mutexes, monitors, ATA hard disk access with preliminary ext2/3 reading support, and a few other cool things.

A related side project of mine is a custom written from the ground up libc and libstd++. These are designed to be standards compliant and be able to operate in kernel mode. This way I can test and validate a lot of code in user space before jamming it into my kernel code. Also it allows me to reuse standard code for things like containers which are already have correct implementation. Finally the use of safe containers such as std::string will help greatly in the reduction of possibly insecure code. Once it moves along a bit more, I'll start posting source code so that if anyone is interested they can take a peek at what I'm up to :)

I have successfully added user mode processes, and the ability to load simple statically linked ELF binaries off disk and run them! Once I finalize my IPC API, then I can begin work on a real GUI which will in user space.

I also may choose to fork off the evanOS-libc and evanOS-libstdc++ into seperate projects for people to use as well. The libc is pretty close to being complete and I'd call the libstdc++ 80%, usable but still missing some large pieces.

Some screen shots for your viewing pleasure...

Pretendo Check it out on github

Pretendo is a NES emulator. As per usual, it was written in c++ (my favorite language, can't you tell?) by me and my friend Eli Dayan. It was designed to be portable so it is already able to be compiled on Windows, BeOS/Zeta, Solaris and Linux (there is no real reason why it couldn't be built on any system which has SDL and Qt as well), a Macintosh port may be done in the foreseeable future. This will probably depend on if I get one of those cool new Mac Minis...they are pretty bad ass. Here are some screen shots for you to take a gander. After discussing Pretendo with Eli, we both agree that we will in fact open source the emulator, but only after it is in a state where we feel happy with it, until then, binary only releases. It is a fairly fast emulator, but we are still looking to make it faster. (At the moment it get about 650 FPS on my laptop which is a 2.0GHz Centrino). Currently it sports a pretty wide feature set which includes:

Binaries will be available on a "once they are ready" basis. We are in no rush to get yet another release out the door. We are currently focusing on code quality, emulation accuracy, and being full featured.


This is my PSX emulator. Currently it really isn't much more than the CPU core and debugger with little tidbits of PSX specific extras. It will currently boot the BIOS just fine. Unlike other emulators, the goal of this one really isn't speed or playability, but more good design and clean code (which may result in speed/playability). What this means is that the code makes a lot of use of templates, classes, and very thought out design. For example, I noticed that many (all?) open source PSX emulators implement memory in a way which just seems weird to me. They tend to implement the memory code literally 3 times, once time for each of 8-bit, 16-bit and 32-bit read/writes. This in my opinion is rather silly, in the real hardware I don't think there is anything stopping you from using a 32-bit write to write to an address which represents an 8-bit port, even if it is considered a programming error. Plus there is the fact that it's annoying to manage 3 copies of the code. So my approach is the use templates and write it once. Then in the code I enforce alignment requirements of the CPU to make sure everything ends up being correct. The result is smaller and easier to follow code. I'll probably post some source soon.

RPG Engine

This one is one of my current favorites. I am building a Final Fantasy 3 (Final Fantasy 6 in Japan) style RPG Engine. It is top down and tile driven in classic RPG style. The cool part is that pretty much every part of the games made are driven by my C like scripting language developed specifically for this engine. Everything from stepping onto an event tile (think doors/stairs/damage tile/etc) to talking to an NPC triggers a function call in the script. This allows every aspect of the plot of the game to be written outside the engine, making it more than just an engine, but an RPG creation engine. I have also developed a mostly functional map editor which currently is used to aid in development of the main game engine, but it will likely be part of a "suite" of programs which make up the creation engine.

Here's some nice screenshots for anyone curious, click on them for larger versions.

Note: I am not an artist, so many if not all of the graphics are "borrowed" from other RPGs I have found on the internet. I will be posting a list of sources as soon as I find all the relevant URLs. If you would like to know the source of a given image, please feel free to contact me.

Ok, I found the program where i got my tiles from, they are from an RPG project known as O.H.R.R.P.H.C.E.. A very good RPG system, with a very fun wacky sense of humor to it.

Quixey - Check it out on github

This is the c like scripting language that I made to drive the event system in my RPG. It is a nice small, yet efficient engine written in c++. It is still a work in progress, and a little messy under the hood, but proves to be very useful for my RPG.

The language was originally loosely based on code found in "C: The Complete Reference", but has been expanded on, re-written and improved very much. At this point, it has evolved into an entirely different codebase from the original example code.

libunif - Check it out on github

QHexView - Check it out on github

edisassm - Check it out on github

cpp-json - Check it out on github