Assembly primer

In an attempt to have more in-depth and interesting hacking discussions and hacks, I'm considering starting a basic assembly primer. I'm wondering wether this would be interesting to anyone, or wether assembly involves too much effort to bother learning, practicing, and putting to use.

If there's enough interest, I might even post my own disassembler once I get internet access back at my appartment. I'd have to clean it up first, of course, since my version involves the occasional tweak in the code when I want to change stuff, which isn't practical for non-programmers.

So would this interest anyone? I feel a little out of place posting assembly hacks and explaining things in terms of code when nobody else (AFAIK...) knows how to write assembly. And it might lead to some interesting hacks that go beyond typical Sue's Workshop cookie-cutter material.

 

It'd be fun to pick up, although I doubt I myself would take it seriously enough to practice every day.

I'd read it.

 

Well I don't want to write this just for it to be read and put aside afterwards. Once my internet access comes in, I'll be able to shift Endless Saga back as my #1 dev priority and Cave Story will take a bit of a backseat, so I'd rather prioritize than invest effort randomly here and there.

 

I'd probably read it. I tend to get bored pretty quickly when trying to learn new programming languages, but we'll see.

 

Sure, that would be cool! Don't know if I would be industrious enough to practice every day, but I will surely try it.

 

I'd be interested, I'm trying to learn some programming languages myself, becuase I enjoy working on this kinda thing. Plus I'd like to make my Mod more standy-outy.

 

I am definitely interested in this. Both for Cave Story purposes, and general knowledge of assembly.

You wrote your own disassembler..?

 

I am not so much interested in a primer, I'm fairly comfortable with assembly and everything I learnt was available on the net. Don't let you stop you from writing it though.

However, I would love to get my hands on your disassembler, with source code if possible, as I've yet to find one that really suits my needs (ndisasm hasn't been cutting it).

 

Writing a disassembler is really nothing to write home about. You just need to know which opcodes map out to which mnemonics, parse the executable byte by byte, and dump the results to a text file. Anything else you might add is purely fluff (unless they're things to make the output more reliable such as heavy branch prediction algorithms to isolate code from data.) Even someone with something as lowely as QBASIC has more than enough to write a disassembler; expert C++ knowhow isn't required. A bit of experience with the PE format (.exe files) doesn't hurt, but it's hardly necessary (to skip the file header and such.)

I'm a software engineer by trade and have a full-time job in this field. I make money selling software, not giving it out. So I'm very anti-open source and have no plans of releasing the source. But I have no issues with releasing explanations of how various algorithms work - if someone can make use of their own skills to write their own implementation, then more power to them.

What would be helpful is knowing what you guys want to see in an assembly primer. The basic theory? A list of commands and what they do? Really basic watered-down stuff, or bare-bones "this is how it is" explanations? Something general purpose or more closely suited to Cave Story? Focus on assembly in general, or hacking in general?

 

I'd say your best bet is to first introduce assembly, explain it's structure (I keep hearing about the stack, and my GUESS is that it's the list of commands executed each loop or something, but I'm probably wrong), introduce some basic commands, and then see what the reaction is. Nothing that would take too much of your time, and a great way to gauge how to structure future lessons/explanations/parts of your primer.

Ah, such programming skill, all wasted to an anti-open-sourcist. Google is doing pretty fine for being an supporter of open-source in many situations.

 

Ah, such programming skill, all wasted to an anti-open-sourcist.

Yeah, every rose has its thorn. Though I wouldn't exactly call it wasted - my focus is the end-user who'll be using the software. As long as they're content, I feel I've done my part.

What I'm thinking of doing is introducing various assembly concepts (stack, processor flags, registers..) based on the assumption the person reading already has a bit of a background in writing algorithms (scripting languages, basic programming, etc..) For instance, if I were to write a series of instructions (after explaining what they do), I'd expect the reader to understand that execution starts at the first line and goes down each line sequentially. And that if part of the code "jumps" to another place, execution doesn't continue from the old place anymore. Stuff like that.

What I'm worried about is either not being able to water it down enough (I tend to get carried away when explaining things and get too technical - I'd make a terrible teacher ) or having people expecting to come out of it able to crack open CS and completely revamp it right away..

 

I'd be most interested in learning how to hack programs, any programs at all. One can always look up the list of commands (can't there only be a few more than 256?) for an architecture, and one should have a basic knowledge of algorithms before attempting anything serious. What I'd like to learn is how to figure out where a file header ends, how to tell code from data, and other such concepts.

 

Actually there are more than 256 commands - two bytes can be used to indicate an opcode (in fact one of the opcodes is reserved for processor extensions and requires 2 bytes to call.)

Just knowing what the instructions do isn't enough - you have to know how the processor works. For instance, the different between ja (Jump if Above) and jg (Jump if Greater) - they sound like they'd do the same thing, but that's not the case at all. This tends to throw off people who are new to assembly - most of them come from a regular programming background and don't have the tendency to think in terms of processor states. Then they perform an AND on a register and wonder why the zero flag is set a few instructions later when they perform a conditional branch.

I'll post what I have once I get my internet back. I should be calling tonight, as a matter of fact, so with any luck it'll be posted this weekend.

I've also started writing a mini-compiler, because I got royally fed up with screwing with offsets whenever I'd add a byte here or there. So far it works like a charm (didn't take more than an evening to code) but it doesn't support every opcode yet. I add them as I need them, pretty much. I might release this with the primer, but I'm not sure if I should. I started out writing it for myself and rushed through the code (seeing as I know I'm not going to try to stuff unexpected values in there.) As a result, someone who doesn't know what they're doing could get skewed results. I'll see. One thing's for sure, I don't intend to invest any time in making it solid and crash-proof. >"<

 

I've decided I'll release my assembler after all. Originally I wrote it as a quick and dirty utility but I scrapped the code and created a nice, simple Win32 interface for it and tightened up the code slightly.

Basically you can enter code in an editable text zone. The format is a little strict, but easy to respect. You can also provide it with a base offset. It'll generate everything for you, calculating relative jumps and such on the fly. It can't handle pointer tables (yet?) though, but I might create a little something to fix that.

The program can detect unknown operands (still doesn't support them all, but the list grows daily) and invalid parameters (ie, mov 0x35,eax would raise an error.)

I'll probably build the primer around this utility and use it as a means of providing examples. Code samples to tweak and experiment with, and such. A future version might support writing directly to an executable, so you could test things out without using a hex editor. Even better would be making the program run as a debugger and attaching to a process to directly modify its code on the fly.

 

Ok. I'm currently at my mother's, who has internet access, and brought along with me a few things (mainly, a dump of Cave Story's code and Discrete, my assembler.) I forgot to bring the assembly primer with me though, so that'll have to wait a little bit...

As I have to format her PC and reinstall Windows XP for her, I'll edit this post with a link to these two files in about an hour.

 

Here's the assembly dump.

http://www.filefactory.com/file/f3014d/

And here's the compiler.

http://www.filefactory.com/file/55dfc5/

Make sure to read the readme file before running it (you should have your computer-usage liscence revoked anyways if you're too stupid to run a program without reading the readme file first...)

 

Awesome. Freakin' awesome.

Although it'd help if i knew what the commands (mov, push, eax etc.) meant. I'm guessing that they're pointers of some sort, but I'm pretty sure trying to assembly without this knowldge is pointless.

 

Awesome. Freakin' awesome.

Although it'd help if i knew what the commands (mov, push, eax etc.) meant. I'm guessing that they're pointers of some sort, but I'm pretty sure trying to assembly without this knowldge is pointless.

Boy, are you in for a surprise .

 

Boy, are you in for a surprise .

Oh, I do know that opening the .exe with a Hex editor grants you access to a whole load of data, and I have done that in my own mod, but I meant using the Discrete program without knowing all the commands could potentially screw over my game.

Then again... trial and error... the old skool way.

 

Actually, trial and error with assembly is not a very wise move. However, I also posted a dump of the game's code, so that should offer a very good starting point.

I'll post my primer next weekend, next time I give my mother a little visit. That should help.