分类： LINUX
2008-08-28 10:06:23
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.
I have recently noticed that the current version of EDB will fail to build on some platforms such as Fedora Core 6. This is due to the lack of QTs QT_ARCH variable and can be worked around by running qmake or qmake-qt4 with "QT_ARCH=i386" or "QT_ARCH=x86-64" as a parameter.
I am happy to announce that version 0.9.4 of EDB is available under the GPL-2 license for 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 before asking about a missing feature, it may already be in the works. Enjoy!
I do a lot of work analyzing applications which I do not have the source code for. On Windows, is the tool of choice, but there is no Linux (or any other *nix) equivalent that I could find. Sure we have , 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, and it is coming along very nicely. The hex dump views are based on the 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 thus 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.
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.
The disassembly engine is based on my project. I feel that this disassembler is mature and works well. It is worth noting that the current version has temporarily dropped AT&T syntax support. Once this is implemented in edisassm, it will return.
I have produced an 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.4.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.4.ebuild digest
ACCEPT_KEYWORDS=~x86 emerge -a dev-util/edb
Some screen shots...
Download
I love using and on both Windows and MacOSX there is a wonderful simple program called . 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 . 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 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
This is my . It is written in c++ with a tiny bit of assembly. My primary goal is to make a usable and useful operating system where it is truly designed from the ground up to secure and flexible. Generally, its design is influenced by a few Operating Systems. I plan to have a 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:/HardDisk/0" and will not be normally part of the actual filesystem. However, a user will be able to reproduce a UNIX like /dev by mounting "Device:/" to "/dev."
Also, I plan to have the normal way of creating processes somewhat like Win32, and not use fork/execve. I do however plan to have fork/execve available in order to increase compatibility the vast library of existing UNIX applications.
It currently runs in , supports multiple processes/threads, semaphores, mutexes, monitors, ATA hard disk access with preliminary ext2/3 reading support, and a few other cool things. I have been trying to implement in as logical a way as possible, the entire c++ standard library in kernel space. 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, tasks, and the ability to load simple statically linked ELF binaries off disk and run them! Also, I have implemented switching to 32-bit graphical modes using a VESA driver implemented through v8086 tasks. It also has a somewhat functional mouse (a box which moves around and changes colour when you click). Once I finalize my 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 is a ...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.
This one is one of my current favorites. I am building a style 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 . A very good RPG system, with a very fun wacky sense of humor to it.
This is the c like scripting language that I made to drive the event system in my . 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 , 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 .
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. (the popular format) is very limited and constantly has needed hacks to the format. So 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, this 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 . And the documentation can be found .
This is a reusable QT4 widget made to display data in traditional hex editor style. The ASCII column is optional, and many visual aspects are adjustable, such as font and font size. 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 is a standalone close that depends on nothing more than the QT library itself. Currently it only supports read-only operations, but is still in active development. Future plans including:
At the moment, QHexView is available in the src/widgets subdirectory of my project. To use it, you simply need to redefine the two types which are the first public members of the class: C, which is a container expected to have a readable vector like interface (QVector
My has recently spawned off a side project. I am no longer satisfied with 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 , and the various instructions sets (SSE/SSE2/SSE3/SSSE3). The tables are based on the latest documentation for the Intel EMT-64 and IA-32 architecutures. Version 1.5.4 is the first version to support 64-bit instructions and is available for
Usage is very simple and included in this package is edisassm.cpp which demonstrates a simple disassembler.
