分类： LINUX

• Home
• About Me
• Projects
• Coding
• Links
• Blog

Debugger – Download Here – 0.9.4

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 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!

I do a lot of work analyzing applications which I do not have the source code for. On Windows, OllyDbg is the 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, and it is coming along very nicely. 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 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 http://bugs.codef00.com. Please post any bugs you find or features you would like me to try to implement there.

The disassembly engine is based on my edisassm 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 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/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

Features

• Intuitive GUI interface
• The usual debugging operations (step-into/step-over/run/break)
• Conditional breakpoints
• Debugging core is implemented as a plugin so people can have drop in replacements. Of course if a given platform has several debugging APIs available, then you may have a plugin that implements any of them.
• Basic instruction analysis
• View/Dump memory regions
• Effective address inspection
• The data dump view is tabbed, allowing you to have several views of memory open at the same time and quickly switch between them.
• Importing of symbol maps
• Plugins
  • Search for binary strings
  • Code Bookmarks
  • Breakpoint management
  • Check for updates
  • Environment variable viewer
  • Heap block enumeration
  • Opcode search engine plugin has basic functionality (similar to msfelfscan/msfpescan)
  • Open file enumeration
  • Reference finder
  • String searching (like strings command in *nix)
  • Hardware Breakpoints

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

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 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 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:/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 protected mode, 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, v8086 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 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:

• Uses native APIs for video and sound when available (Win32, BeOS/Zeta)
• Uses SDL for video/sound and QT for GUI on UNIX targets (command line GUI in works as well)
• A pretty accurate sound system
• A functional debugger
• Good mapper support (0, 1, 2, 3, 4, 5, 7, 9, 10, 11, 15, 19, 23, 32, 33, 40, 41, 64, 66, 68, 69, 71, 118, 240, 245)
• UNIF support
• Fullscreen and Windowed video modes
• Adjustable palette
• Pattern Table Viewer (Tile Viewer)
• Name Table Viewer
• In memory IPS patches, this allows a ROM patch to be applied without modifying the original ROM file. If the user tells the interface to load an IPS file, Pretendo will load a .nes file of the same name from the same directory and then apply the patch automatically. This removes the need for storing the result of a patch on disk, and hopefully will cut down on hacks in people's ROM collections
• And a few things I'm probably forgetting

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:

• Assignment to variables during declaration
• Detection of duplicate functions
• Combination assignment and modification operators (ex. +=)
• Binary operations (ex: int a = b | c;)
• Proper block level scoping for local variables (they are destroyed when the enclosing block is ended, not just function return
• "else if" support
• Vastly more complete syntax checking
• Pre-tokenization of the program for improved execution speed, this also allows a future version to save this tokenized version and load it for execution. The goal being that you don't have to make your scripts open source.
• Several other features I am failing to recall right now...

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, 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 here. And the documentation can be found here.

QHexView

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:

• Byte pattern searching (related to debugger feature)
• Allowing the data to come from an input stream (allowing viewing of files trivially)
• Write operations

At the moment, QHexView is available in the src/widgets subdirectory of my Debugger 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 works nicely) and address_t, which represents an address, likely a uint32_t will work perfect.

edisassm - Download Here - 1.5.4

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. Version 1.5.4 is the first version to support 64-bit instructions and is available for download!

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