Doukutsu Assembler

So, I've created an x86 Assembler in an effort to make ASM hacking easier and/or faster. (An assembler is an assembly language compiler)

Screenshot:

Latest Download Link:
Doukutsu Assembler Version 1.31

Latest Mirror Link:
Version 1.31
Other Mirror

Old Download Links:

Spoiler

Downloads:
Doukutsu Assembler v 1.3
Doukutsu Assembler v 1.2
Doukutsu Assembler v 1.1
Doukutsu Assembler v 1.0
Doukutsu Assembler v 0.4
Doukutsu Assembler v 0.3
Doukutsu Assembler v 0.2
Doukutsu Assembler v 0.1

Mirrors:
Version 1.3
Version 1.2
Version 1.1
Version 1.0
Version 0.4
Version 0.3
Version 0.2
Version 0.1

What are the advantages to using this?
The Doukutsu Assembler contains features that OllyDbg and similar interactive debuggers don't have.
This Assembler has a dynamic labeling system, so all your JMPs have the same capabilities as any goto statement in other programming languages. You can move around large blocks of your own code without having to change a single jump or call thanks to the labeling system.
While hacking, this means you never have to worry about whether to use a long JMP or a JMP SHORT--the assembler does it for you. There is also support for switch statements, so you don't have to recalculate the addresses in your switch tables if you decide to rearrange your ScriptStates.

OllyDbg supports a wide range of possible x86 instructions. The number of supported instructions for my Doukutsu Assembler is far more limited, but you should still be able to do your NPC and Weapon hacking with little to no issues.
(Starting with version 1.0, the Assembler supports almost every integer instruction).

You can still add in new instructions using a feature called defines, which works similarly to the C/C++ define macro.

Documentation
Yes, I've included documentation/tutorials, so please read the Userguide.html file. If you don't, you'll most likely be very confused as to how to use the Assembler.

Source Code

Spoiler

Source code for version 1.31
Source code for version 1.31 (Mirror Link)
Source code for version 1.3
Source code for version 1.3 (Mirror Link)
Source code for version 1.2
Source code for version 1.2 (Mirror Link)
Source code for version 1.1
Source code for version 1.1 (Mirror Link)
Source code for version 1.0
Source code for version 1.0 (Mirror Link)

Linux Users
Even though Java is cross-platform, I've compiled some special versions of the Assembler that make it run much better on Linux.
If you're using Linux, please download these versions instead of the Windows version.

Doukutsu Assembler v 1.2 for Linux
Doukutsu Assembler v 1.2 for Linux (Mirror)

Source code for version 1.2 for Linux
Source code for version 1.2 for Linux (Mirror)

 

:0
I want to check it out but I have to watch a movie right now.
I'm excited, but will it be easier than Olly? Sometimes having too many features can be a bad thing, if this is is more streamlined yet still gets the job done then I will be a happy man.

EDIT: This is very interesting... So it's almost like a thing that compiles assembly and then inserts code into the program. Very cool. I'm currently building a huge list of defines for my convenience.

 

Wow, shortly after I decide that I need to do assembly, this come out.
I gotta try this out when I get a chance.

 

If anybody wants to use my list of defines they're more than welcome to.

 

Updated to v0.3.

This should hopefully fix some of the byte-sized pointer issues and also puts in some miscellaneous additions to MOV, CMP, AND, OR, XOR, and NOT.

MOVSX and MOVZX are now supported, but only for a few variations.

To correct potential future problems, I may have to do a major rewrite of the code for this assembler, but that won't be ready for quite a while.

 

Updated to version 1.0

Version 1.0 is a major overhaul of the Doukutsu Assembler. It encodes all instructions the smart way (bit level encodings) instead of the previous wrong way (byte level encodings). So now, almost every instruction in the Intel x86 integer instruction set is supported. Don't believe me? Try it yourself.

There is also a boatload of new features, such as the two text editors -- one is for plain text editing the old fashioned way, and one is an editor that provides a barrier between ASM instructions and labels (feature suggested by GIRakaCheezer).

Too lazy to scroll up? Grab version 1.0 right here.

(If you find bugs, please report them in this thread or send me a PM/VM. New versions may be prone to bugs, especially during a complete rewrite of the code such as this one.)

 

What's the difference between bit-level and byte-level?
Even sahf and lahf? I'm impressed.


Anyways, I never got around to using the old version, but I think I will/should try this one. It's a big improvement over olly on many levels.

 

What's the difference between bit-level and byte-level?

This is kinda hard to explain, but here goes.

The old Doukutsu Assembler (version 0.4 and earlier) used the byte as the smallest unit of data it manipulated (in most cases). This is not a good way to build a compiler.
Looking at bytes only, let us compare MOV EBP,ESP and MOV AL,CL.

MOV EBP,ESP = 8[color=#7F7F7F]9E5[/COLOR]
MOV AL,CL   = 8[color=#7F7F7F]8C8[/COLOR]

Sure, they share the first hexadecimal digit for their encodings, but otherwise there is no real similarity between the two instructions aside from the fact that they're both MOV. If we were to make a data structure containing all x86 instructions, we would have to put MOV AL,CL in a different category than MOV EBP,ESP.

The current Doukutsu Assembler (v 1.0) embraces the bit as the smallest unit of data it can manipulate.
Looking at the bits, let us compare those same instructions.

MOV EBP,ESP = 1000 100[color=#7F7F7F]1[/COLOR] 11 [color=#7F7F7F]100 101[/COLOR]
MOV AL,CL   = 1000 100[color=#7F7F7F]0[/COLOR] 11 [color=#7F7F7F]001 000[/COLOR]

After some experimenting, you can figure out that ESP is 100, EBP is 101, AL is 000 and CL is 001. Registers encodings are ambiguous, so there is also a bit called the w-bit that determines the wideness of the instruction. In the first instruction the wideness bit is set to 1 for a 32-bit instruction, while in the second the wideness bit is set to 0 because it is an 8-bit instruction.

The binary "skeleton" of MOV register1,register2 looks like this: 1000 100<w-bit> 11 <reg2><reg1>

Because they share a binary skeleton, now we can put MOV AL,CL into the exact same category as MOV EBP,ESP. Reducing the number of categories makes the assembler much more efficient.

 

The old Doukutsu Assembler (version 0.4 and earlier) used the byte as the smallest unit of data it manipulated (in most cases).

I figured something like that, but I didn't know what it entailed.

That's really cool actually - I never really could identify a pattern while looking at the hex encodings that olly shows. I guess this is why.
Say, if 100 is mapped to esp, what happens if I want to mov ebp,4?

 

That's really cool actually - I never really could identify a pattern while looking at the hex encodings that olly shows. I guess this is why.
Say, if 100 is mapped to esp, what happens if I want to mov ebp,4?

In that case, the instruction has a different binary skeleton, so MOV register,register is different from MOV register,data.

MOV register1,register2 = 1000 100<w-bit> 11 <reg2><reg1>
MOV register,data = 1011 <w-bit> <reg> <data>

MOV EBP,ESP = 89E5
MOV EBP,4   = BD 04 00 00 00

MOV EBP,ESP = 1000 100[color=#7F7F7F]1[/COLOR] 11 100 [color=#7F7F7F]101[/COLOR]
MOV EBP,4   = 1011 [color=#7F7F7F]1[/COLOR][color=#7F7F7F]101[/COLOR] 0x04 0x00 0x00 0x00

Notice that it's not exactly an efficient system - you have to write 4 as a huge 32-bit number.
CMP does one better than MOV because it has an s-bit, or sign-extension bit, which can sign extend a byte into a dword or word.
In that case, you could write 4 as just 0x04.

CMP EBP,4        = 83FD 04
CMP EBP,4        = 1000 00[color=#7F7F7F]11[/COLOR] 11 111 [color=#7F7F7F]101[/COLOR] [color=#7F7F7F]0000 0100[/COLOR]
CMP (reg),(data) = 1000 00[color=#7F7F7F]<s-bit><w-bit>[/COLOR] 11 111 [color=#7F7F7F]<reg>[/COLOR] [color=#7F7F7F]<data>[/COLOR]

Anyway, this is really useful info if you ever wanted to edit the source code.

 

Didn't get around to look at this till now. I've started using it and it seems really useful! Its not too complicated and there aren't so many things on the screen that you feel overwhelmed. Nice work! I could never do anything like that

 

This is my quizzical face.












You can use x86?

 

Updated to version 1.1

Version 1.1 introduces a very interesting feature: syntax coloration!

See the first post of this thread for a screenshot.

Download version 1.1

 

Will I run into the same issue with this that I did with ollyDbg? The can't save code I mean.

 

Will I run into the same issue with this that I did with ollyDbg? The can't save code I mean.

No you shouldn't run into the same problem. The Doukutsu Assembler is not a debugger and it is blind to the type of executable you use. In fact, you could use it to hack a non-Cavestory program if you wanted. It will overwrite code in any part of any executable.

Bobbyis, did you read your visitor messages? I gave you a special version of the Doukutsu Assembler that is designed to make <BBP work correctly. Here it is:
http://www.mediafire.com/?0azhus515z6rjmc

 

Hmm... I didn't see that. Guess I'll go get that then.

 

Version 1.2 Released
Grab it here.

Version 1.2 fixes the IMUL Bug. Some types of IMUL were being compiled incorrectly in past versions.

Here's a short overview of the bug's symptoms:

IMUL EDX,EAX              ;Didn't work! Turns into IMUL EDX.
IMUL EAX,EBX              ;Didn't work! Backwards - turns into IMUL EBX,EAX
IMUL EAX,DWORD [464000]   ;Didn't work! Causes error when it should be accepted.
IMUL EAX,ECX,22           ;Worked.

As you can see, this is a somewhat important bugfix because IMUL is a commonly used instruction.

In other news, there is now a special version of the Assembler that is optimized for Linux operating systems.
You know, just in case there are any Linux ASM hackers out there.

 

I'm really liking the new version, but I don't like how the whole thing has to close if it finds something wrong in the file it is assembling. Fix?

 

I'm really liking the new version, but I don't like how the whole thing has to close if it finds something wrong in the file it is assembling. Fix?

System.exit(0) is my way of getting out of some deeply nested method calls. A bad habit, I know.

I'll probably use exceptions to fix this up so the user-interface window will stay open and such.

 

Version 1.3 released.

Download it here or see the first post of this thread.

v1.3 now keeps the main program window open whenever an error box is shown.
Please report bugs if you find them.

EDIT:
Version 1.31 has been released to fix a progress bar message bug in v1.3.