19 replies to this topic

[Carrotlord]

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)

Edited by Carrotlord, 19 July 2012 - 12:28 PM.

[Noxid]

: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.

[HyMyNameIsMatt]

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

[Noxid]

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

[Carrotlord]

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.

[Carrotlord]

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.)

[Lace]

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.

[Carrotlord]

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="Red"]9E5[/COLOR]
MOV AL,CL   = 8[COLOR="Red"]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="Green"]1[/COLOR] 11 [COLOR="Red"]100 101[/COLOR]
MOV AL,CL   = 1000 100[COLOR="Green"]0[/COLOR] 11 [COLOR="Red"]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.

[Lace]

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?

[Carrotlord]

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="Green"]1[/COLOR] 11 100 [COLOR="red"]101[/COLOR]
MOV EBP,4   = 1011 [COLOR="Green"]1[/COLOR][COLOR="Red"]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="Green"]11[/COLOR] 11 111 [COLOR="Red"]101[/COLOR] [COLOR="DarkOrchid"]0000 0100[/COLOR]
CMP (reg),(data) = 1000 00[COLOR="green"]<s-bit><w-bit>[/COLOR] 11 111 [COLOR="red"]<reg>[/COLOR] [COLOR="DarkOrchid"]<data>[/COLOR]

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