I'm not sure how best to describe what I'd like to be able to do, but basically, like the title says, I'd like to be able to assemble code at specified addresses, over parts of a loaded file (binary - using the "file" directive), (for patching files).

The closest thing that I found to what I need is the "store" directive, but it's really not nearly the same.

Something like Cheat Engine's Auto-Assemble tool would be great, where, for example, you can write:


And it'll assemble the code at addresses 00410000h and 0053004Ch.
EDIT : virtual offset, of course.
In FASM, I'd be responsible for assembling code at the proper, real offsets.

... Am I overlooking an incredibly obvious solution ?

Just mark the target section as 'writeable' using APIs like VirtualProtect Then do WriteProcessMemory


You want an example ?

An example would be very helpful, yes.

Is WriteProcessMemory really necessary though, for simply getting FASM to assemble code over an already loaded file ?

fwd: You also need to know the file format to be able to patch at virtual memory addresses. You'll need to map the binary file address to the memory map when loaded.

I expect that using a dedicated patcher program would be more more convenient.

Oh, I see. Was he talking about making the changes permanent when he said patching ? If he meant that then your suggested way of 'mapping' would be much faster and effective. I'll wait for him and see if he wanted a permanent patch or not.

Yes, 'permanent' patching - not patching memory.

I want to use FASM to edit (patch) an exe or dll file, knowing what (real) offsets I want to assemble at - over the original code.

I can do it easily by assembling code in FASM into a .bin file, and then just copy-pasting the binary into the file (exe, dll, etc.) that I want to 'patch' using a hex editor, but I would rather be able to save the extra steps, and just open the file in FASM, and have FASM output the same file except with my code assembled over whatever given addresses (offsets).


Sorry about the lack of clarity.

Ahh. It's clear now.

OllyDbg can do it.
HexEdit can do it
HExplorer can do it.

Basically a hex editor is all you need.



IMO it's easy also to make your own.

Sounds like an interesting project to do. Maybe I should make that tool right now. I'm always up for such challenges.

NOTE: I'll make it in C that way the progress will be much faster.

Here's what I have so far. I'll finish it later.

"Hex viewer" rather not "Hex Editor"

I like this display of HxD more, it's better to see whats in the file with ASCII characters directly attached not in another window. You waste a lot of space when displaying content. If you are working with hex editors they have to be small in display, fast and need easy page/up page/down support and more.

I don't know why you write this tool for windows as it have really many.
HxD is my favourite, can read files, sectors (discs) and memory areas.

HxD is another tool so is this one.

HxD cannot compile an Assembly file (using FASM of course) and then patch a file using the assembled file.

Read the OPs request.

Without a dis-assembly there's no way to account for relative addressing.
You'd need to scan for reads/writes/jumps that intersect with the patch code and readjust them by +/- the size of the patch code. Then there's the special cases that make it more difficult like byte offset jumps that now go beyond the byte boundary and need to be modified further.

The above is less of a problem when patching static code like DLL functions. When I created a faster version of Win XP 64's RtlInitUnicodeString function I was able to patch the system DLL by compiling my new function FASM and pasting the output over the original DLL's binary. But I also had to re-calculate the file hash of the modified DLL and paste the new hash in the appropriate (?header?) location.

^^Hmm, thanks for that idea. It's really more than just inserting bytes.

However, the OP did not actually specify if he wants the bytes overwritten or adjusted(of course the header itself will need to be updated). Thanks r22 I would not have thought of that for sure.

Maybe he can use OllyDbg at the same time ?

Or maybe I can just make an OllyDbg plugin ?

WTF... I'm going to quit and delete this project and go do other things lol

It make no sense to patch an assembly file. If I have an assembly file I could easily reassamble it. Patching is a technique used when you don't have assembly ressources.

In the early 80s patching was quite common by changing a few bytes with fixed offset inside a mostly binary file. The technique was used because it was more easy to change a few bytes due to long transfer of large binaries over telephone lines with 300 Baud. So people phoned with a developer, asked for changing something and try the patch at a far location when the developer could not stay there and could not test the program in the real environment.

I think today patching is more or less obsolete. Even Microsoft is not really patching their software, they provide new/changed drivers or files. They do not really change a few bytes. Mostly programs have been styled for patching to easily change data, jumps, calls or loops. The Patchday of Microsoft is pure marketing and has nothing to do with real patching.

I like patching in the 80s and did many times when I have been at customers. Today you just send a new/changed binary with email or other way. And there are not many developers giving you access to symbols or even source files. Because it's there capital.

Did you actually understand his request.


He thought he could make fasm do this


then FASM would open 'some_app.exe' and patch that file at the specified address with the currently assembled file.

Now do you understand ?

Hello again everyone,
I'd forgotten about this thread, but I'm glad to see that more replies have been made to it, and I thank you all for the help.

I'll read over what's been posted more thoroughly when I have time, but if anyone's curious, I'm just using Cheat Engine's Auto-Assemble tool in the meantime and applying the generated code to whatever PE files I want, using HxD.

One thing I don't care for about CE's AA is that it throws in 'nop's during assembly, particularly around jump instructions.

Anyway, thanks again guys.

Long time ago my approach was fasm macroses that create patch file and apply them with external program.[/url]

Okay but I think it is difficult to use this way.
One thing is to patch values, another to implement new instructions.
So you have to know the binary file very well, need space for placing instructions, need the context in which instructions are used and need the space you have for new instructions. Would get even more complex to overwrite existing instructions other than NOPs.

And that's exactly what I said in my last posting regarding patching, programs have to be designed for patching. So I think he will make a design with some user defined functions. Maybe would be better to call a function in a DLL and to rewrite the DLL for that application than to do it this hard way.

So I can not see any advantage for this style of programming.
But can do many things with FASM, maybe I try to make a coffeemaker with it.