Projects

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

Requirements

Announcments

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!

Downloads

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

History

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.

About

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 http://bugs.codef00.com. Please post any bugs you find or features you would like me to try to implement there.

Features

Thanks

Some screen shots

QGMailNotifier

Download Version 2008.3 Here

I love using GMail and on both Windows and MacOSX there is a wonderful simple program called Gmail Notifier. Unfortunately, there is no *nix port. To fill the gap there are a few work-alikes out there. But for me, none of them fit the bill. The closest to meeting my needs was kcheckgmail. But that one actually logs into the page and parses the data, which makes it very brittle and prone to breakage every time google updates their pages. QGMailNotifier uses the GMail RSS feed to get it's data.

So, I've developed my own Qt4 based notifier which works very similarly to the Windows version. I've added a few things here and there, and plan to add some cool things in the future such as: multiple account support, kde wallet support and more methods of notification.

For now, it is simple and works well :). I've created an ebuild for anyone who wants to try it, the only dependancy is Qt >= 4.3.0.

I have produced an ebuild 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/qgmailnotifier/mail-client/qgmailnotifier/ cp qgmailnotifier-2008.3.ebuild /usr/local/portage/qgmailnotifier/mail-client/qgmailnotifier/ echo PORTDIR_OVERLAY=\"\${PORTDIR_OVERLAY} /usr/local/portage/qgmailnotifier\" >> /etc/make.conf cd /usr/local/portage/qgmailnotifier/mail-client/qgmailnotifier/ ebuild qgmailnotifier-2008.3.ebuild digest ACCEPT_KEYWORDS=~x86 emerge -a mail-client/qgmailnotifier

QGMailNotifier screenshot

evanOS

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

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.

Fakestation

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.

RPG Script

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. My implementation included features such as:

You can download a copy with my RPG functions trimmed out here.

libunif

This library is related to my NES emulator Pretendo. Basically around 2000/2001 there was a bit of a movement in the NES development community to have a more accurate and proper game cart backup format. .NES (the popular format) is very limited and constantly has needed hacks to the format. So UNIF came along and personally I think it is in fact a much better format. As for if it did/will catch on, who knows.

Regardless, libunif is a library I made which makes loading UNIF and .NES files pretty trivial. It also has an example program which will convert from .NES to UNIF (though it does need a little user input). The code can be found at http://code.google.com/p/libunif/. And the documentation can be found here.

As of 2011, Tennessee Carmel-Veilleux, the original creator of UNIF, has asked that I host and maintain the UNIF standard which I am more than happy to. So if you see any dead or out of date links to the UNIF standard, feel free to redirect them to the copy that I am hosting at http://codef00.com/unif_cur.txt.

QHexView

This is a reusable Qt4 widget made to display data in traditional hex editor style.

It is very configurable. The different columns may be shown or hidden as needed. In addition, the colours, fonts and font-sizes are all adjustable

I originally considered reusing the widget made for KHexEdit, but it really seemed like it is bit too tightly coupled with the rest of the application. So I developed this widget by building on top of the QAbstractScrollView. The look at feel of the widget is based on KHexEdit, but it is a standalone widget that depends on nothing more than the Qt library itself. Currently the widget only supports read-only operations. However, You can of course alter the underlying data and refresh the view programmatically.

QHexView is available in at http://code.google.com/p/qhexview/. To use it, you simply supply it with an object that inherits from QIODevice. This means that viewing files, data buffers or even a QTCPStream is trivial!

edisassm - Subversion Repository

My debugger (edb) has recently spawned off a side project. I am no longer satisfied with libdisasm as the disassembler engine for edb. It is a stagnant project and only supports i386. Because of this I have started my own object oriented disassembly API which will be the future basis for edb's disassembly. It can decode all of the i386/EMT64 instruction set including MMX, and the various SSE instructions sets (SSE/SSE2/SSE3/SSSE3). The tables are based on the latest documentation for the Intel EMT-64 and IA-32 architecutures. Starting with version 1.5.0, disassembling 64-bit code is supported.

Usage is very simple and included in this package is edisassm.cpp which demonstrates a simple disassembler.

cpp-json - Subversion Repository

There are a few different JSON parsing libraries out there. But cpp-json aims to be the simplest to use while still being efficient by using modern c++ techniques.

Currently, the only active item on the TODO list is to better support Unicode. The parser can be given iterators referring to wide characters, but there is no runtime detection or endian-ness detection (yet)

However, Unicode is generally well supported in the form of \uXXXX encoding, including code points which require surrogate pairs. The resulting json::value object will contain the string, encoded as UTF-8 since it is stored in a std::string.

Of course special consideration is needed when displaying these strings if they do in fact contain non ASCII characters.

So, for example, {"test1" : "\uD840\uDC8A"} will correctly parse and the object's "test1" member will have the byte sequence: 0xF0 0xA0 0x82 0x8A

Here is a simple example of the usage of this library:


#include "cpp-json/json.h"
#include <fstream>
#include <iostream>

int main() {
        // open a file
        std::ifstream file("test.json");

        // json::parse can take two iterators or a std::istream
        json::value json = json::parse(file);
        
        // you can access objects like associative array's easily
        // the result is a json::value
        // ... though in real code you may want to check the type first ;-)
        auto servlets = json["web-app"]["servlet"];

        // when dealing with arrays, you can just use iterators, 
        // or feel free to use C++11 ranged-for
        const json::array &a = as_array(servlets);
        for(auto it = a.begin(); it != a.end(); ++it) {
                const json::value &v = *it;
                // all basic types (numbers, strings, booleans) can be converted 
                // to a string
                std::cout << to_string(v["servlet-name"]) << std::endl;
        }
}