Assembly Language Programming: Still Relevant Today (2015)
wilsonminesco.com
wilsonminesco.com
"Jeff Laughton (Dr Jefyll on the 6502.org forum) says, "I recall hanging out with a programmer pal o' mine and a younger fella who was in college. The young fella was complaining, 'We have to take assembly language,' and Len corrected him immediately, saying, 'You get to take assembly language!'"
<g>
What's great is that learning assembly is like taking the first step to understanding the bridge between software and hardware.
I remember a taking class that started out as confusing as hell. The first few exercises seemed really mystical and just so brittle. You'd have to be a wizard to ever get this, one thinks. But by the end of the class, we made an asteroids-like game, complete with RNG based on input timing (the time between game execution and when the user clicked start). That was really an enlightening moment.
I have read that self-modifying code on the x86 architecture is pretty dangerous at the assembly level.
More broadly, this kind of comes back to all the issues in the "C is not a low level language" thread. Some level of assembler certainly gives the programmer as full access to the machine as possible. But naive assembler from the 8086 - 80486 eras is going to be rearranged in a lot of ways in a modern Pentium processor and counting on in-order execution may be a mistake.
Edit: at the same time, the modern processor doesn't really allow a lower level than assembler normally and the default approach is assuming flat memory but being aware of the pitfalls of multiple caches being involved.
Dangerous in what way?
Generally, easiest to do the last or put NOPs or doing something like windows hot patch point for functions. Where hot patchable functions are preceded with a 5 bytes of nops, and the function always starts with MOV EDI, EDI which again is a pretty much a NOP, but takes two bytes.
This allows one to replace MOV EDI, EDI to a short jump to the start of those 5 bytes which is large enough to hold a long jump to any code. Windows went this route because originally multi byte NOPs where not part of the spec so if you used the one byte NOPs not only would each nop need to be execute slowing down function calls, but in multi-threaded code you would have to lock all threads to edit the code since it would be fetching on byte at time ect...
These days, I think you would need to 1) have memory pages with code with write permissions, 2) possibly flush the instruction cache and 3) hope no other thread is using said routine. With today's security concerns, 1) will not be likely, 2) possibly requires elevated privileges (I don't recall---I've only really done ring-3 level code on x86) and 3) is probably okay in a single-threaded program.
Why's that? I'm not aware of any issues specific to x86.
You may be remembering early x86 chips that didn't properly invalidate the instruction cache after a write. Modern chips are fully cache-coherent.
Doing this on every write (especially considering multiple possible virtual to physical mappings) is very expensive in terms of hardware - it's why some architectures (RISC-V for example) have explicit instructions to trigger these things
(I manage a team thag writes self modifying code for a living.)
Am I the only one who’s never felt that way? I get grief from people around me (especially “hurry up and get it done” management types) for spending too much time in the low levels, trying to really understand what I’m doing and what’s going on.
In fact, most mainframes have always made use of microcoded CPUs, with Assembly being referred as bytecode on the programming manuals.
You just need to dive into IBM and Xerox PARC manuals, for starters.
Otherwise there isn’t a great limiting principle to your logic. Just because someone once built hardware that executes such a high level assembly that the manual referred to it as bytecode doesn’t mean that all bytecode formats are assembly.
Even modern 80x86 Assembly is a low level form of bytecode, given that the micro-ops that are processed by the microcoded CPU are completly unrelated to 80x86 Assembly opcodes.
It yields the only control and execution. Almost programs are generated through an assembler and assembly language. How could it possibly not be relevant?
https://github.com/openjdk/jdk/blob/e73ce9b406c34bd460f0797f...
Also if you look at the compiler's intermediate representation at the very last phases you'll see it basically looks like an assembly program.
Some things can only be done in assembly.
Although doing the same on windows is kinda annoying. Also the amount callee saved registers is kinda like what the heck. Here is some code I wrote doing that for window's ABI. https://pastebin.com/jnxeMRcV
And I feel assembly should be more a core building skill in a programmers toolbox. So this article is very welcoming for o me.
I would recommend checking out an old book for an old mainframe's assembly language. They're usually much less mystic by virtue of being much less complex. IBM had some really nice manuals and books; no one ever got fired for buying IBM because an IBM machine could be programmed by a dog.
Octal is where it's really at, though, if you get really into this. A fun weekend project is to write an octal "decompiler" (ideally you won't have compiled anything, just having written some octal by hand) that allows you to reason with what it's doing by translating it to an actual language rather than just thin syntactic sugar over 1s and 0s. Octal itself isn't so difficult, it makes binary much easier to reason with, but this definitely helps you get a more intuitive sense of what is what.
Of course, it's not something that has a substantial amount of value with modern machines. Maybe eventually we'll get back there; I think I'll enjoy it when we do. Until then, though, it's fun to play with.
Why octal, not hex?
I just don’t know how to get started at all.
I don’t know how people can reverse engineer a device that you don’t access to the running program to. How do you monitor and track all the bits being passed around to break back firmware? Specifically video game mods and hacks I wanted to dabble in since I find their programming fascinating and know I’d be interested to contribute most in my spare time in that.
Not sure you need assembly for that.
If you want to modify 3D rendered output, you normally need to adjust shaders, textures and such. For extreme cases, you can hook the entire Direct3D API adjusting how it works for the game. The only assembly you might need for that is shader assembly https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/... but not always necessary as the HLSL decompilers are often OK.
If you want to modify game logic, it’s normally implemented as scripts. Game designers and level designers don’t often know C++, and they certainly don’t want to recompile the game because it’s slow, they adjust scripts and see the result in real time.
How do I modify the code of that which I don’t have access to?
What reverse engineer projects are good for beginners? I see people post here their first project attempt to reverse an older gadget. I’d love to pick up an older gadget and try to reverse engineer it and make it do what I want it to.
Native code reverse engineering is very time consuming. It’s often possible to achieve similar results by focusing on the code which you have access to. You don’t have source code of Windows OS components, but you do have their APIs and debug symbols, and that’s much better than just binaries.
If you want to change what’s rendered, you can replace the GPU API with a wrapped version, like renderdoc does. If you want to change what’s loaded from disk, patch game files, or replace whatever OS file I/O APIs is used by the game (DLL injection, then MinHook or Detours).
Even when you do need to change game’s own native code, directly patching machine code is rarely a good idea, very hard to implement and especially debug. An easier way is replacing complete functions with API-compatible replacements implemented in your DLL library in C++. Again, use MinHook or Detours to replace the implementation. C++ allows unrestricted memory access so you can read and write everywhere, here’s working examples: https://github.com/Const-me/vis_avs_dx/blob/master/avs_dx/Dx... https://github.com/Const-me/vis_avs_dx/blob/master/avs_dx/Dx... I didn’t have source code of these C++ classes, but wanted their data regardless. Found the offsets by using VS debugger, these third-party DLLs include GUI to change the values, I compared memory before/after making changes.
> What reverse engineer projects are good for beginners?
In the context of modern Windows games, assuming you wanna change what’s rendered, a good start might be https://renderdoc.org/. Officially, the tool is only supported when you run your own code. Technically, it often works with retail games too, just don’t open issues about that, they’ll be closed as a not supported use case. As a nice side effect, you’ll learn a thing of 2 about Direct3D. The tool is open source with good license (MIT), so you can fork, disable their frame captures, and change their API wrappers to modify the output of some particular game.
One more thing, modern games use a lot of bytecodes. E.g. D3D shaders are byte code, search “3dmigoto decompiler” to decompile dxbc into HLSL. .NET is often byte code (Unity3D is based on .NET), use reflector to decompile into C#. Many games use custom VMs, sometimes modding community has decompilers for their custom byte code.
> I’d love to pick up an older gadget and try to reverse engineer it
What do you mean by “gadget”?
Some products I own and some are made to order. Some I did on my own and for some I was a leader of big team
I have used and sometimes still do use assembly language, including 6502 (specifically, NMOS 6502 without decimal arithmetic, including unofficial opcodes), and a little bit of x86 stuff (although the modern x86 is very messy, I think), but also Z-machine and Glulx. I have also used MIX and MMIX assembly (and may use MMIX more if I would actually make a computer with it). And then some other programs (such as ZZ Zero, which is similar to ZZT) has its own kind of assembly language.
One feature not mentioned is the relative numbered labels such as 1H and 2H available in MIXAL and MMIXAL; you can then use 2F to find the next 2H label forward, or 2B to find the next 2H label backward. My own assemblers for Glulx and ZZ Zero support the similar feature too.
Part of my motivation for this was to have an assembler that ran in the browser (for my fantasy console that also runs in the browser), but another big part of it was to write an assembler designed to be more friendly to people writing assembly directly.
When I wrote 6502 asm I mostly did it from Supermon which is a no frills experience. It's nice to see the features that assemblers have now, I think I'll be implementing quite a few of those macros from this link in my own assembler.
As that 6502 example in the article shows, you don't great great productivity with assembly. And even macros don't improve on it that much.
You can still do it if you care about debug build performance.
I think this article is very, very simplistic. All of it relates to a 8 bits CPU that is 40+ years old.
I switched to HLL as soon as I could get my hand on a compiler, namely, UCSD Pascal at the time! Then the Pascal, then to C and then myriads of other languages. I covered 6502, Z80, 68k (all of them, to 68040), PowerPC (all of them from 601 prototypes to G5s), ARMs (more than I can count) and x86s (same).
True to be told, the assembly language I started with /helped a LOT/ with be becoming an efficient developer; a developer who understand what 'code' is being generated when he writes an expression, a statement, a loop, and one who understands what the runtime implication are for most of the 'sugar coating' HLL gives.
However, starting (a bit) with the 68k, then even more so with the PowerPC, it became pretty much impossible to write /from scratch/ an assembly equivalent that was QUICKER than the compiler generated code. That was 20+ years ago. DRAM latency happened, pipelining happened and SIMD happened.
Today, hand writing assembly is pretty much stupid on modern CPUs. Given the register files, timings, shadow registers, bus latencies etc etc the compiler will ALWAYS be better because there is so much criteria to think about when generating code...
I'm not saying that having the knowledge is not useful; the best use of assembly is to write some code il HLL, one that is supposed to be super-mega-critical-quick, then disassemble it and see how it looks. More often then not, you can't make it better than it is in situ -- most of the time you will gain is to prepare your data better, align it better etc etc -- basically, 'hinting' the compiler to do a better job. You can do serious code butchery like that, without a hint of assembler [0].
But really, I haven't written any assembly for /performance reasons/ in 15 years, and that was Altivec on PowerPC.
For 8 bits, it's all smooth as butter, but the article also doesn't take into account the massive progress in compilers; I'm the author of SimAVR [1] and I've seen my load of generated code for that CPU, and the GCC toolchain is /very hard to beat/ by hand these days.
[0]: critical audio loop on one of my old PCI card driver, converting float<->int, applying gain etc while using the register file to the max, and making most use of the pipelining of the G4 (at the time) https://gist.github.com/buserror/0a3a69cca927b8da6c9c7ee1605... -- note, the inner loop was generated by a script that was doing the cycle calculations (!)
Someone has to create those tools.
Yup. Explains all that neat hand-written AVX asm code in your video decoder, strcmp() implementation, lzma decompressor, utf8 parser, and the base64 decode logic in your browser.
A lot of people put in a lot of hard work so that you can have the cute thought that there is no more reason to write assembly. Many of them wrote your compilers, some of them wrote some of the logic I mentioned above. Quite sure that none of them appreciate being called "pretty much stupid".
That's the same as using assembly language, rather than poking binary/hex values into memory.