Not just writing assembly, rewriting a compiled object file without letting any of the addresses change, without having the source to work with, and presumably with almost no documentation, to patch a program that has been left untouched for almost 20 years.
Those properties come by definition. Addresses don't change because you can't (realistically) change things any much and move things around.
Basically, think of it like this: you have an old book, written in some magic runes and is told that a certain (quite short) paragraph is wrong and can be badly misinterpreted due to poor wording. You know, the magic spell goes kaboom.
You have tools that can easily and painlessly: a) translate the runes into a text that mere mortal can reasonably easily read; b) scrub runes off the page and write any new ones over; c) translate your text into runes. There is a simple correspondence between text length and how many runes it would take. Now, all you need is to write the new text that must be no longer than old one was. Not a trivial task, but not something extraordinary. Just rare, because we don't deal with magic runes those days as familiars take orders and handle all the gory details.
Writing assembly requires a skill. So does reading old assembly code of a particular function and figuring out what it did. That's admirable, but not something unbelievable.
It's just rarer to see those days, but not a lost art or anything like that. Crackmes are still alive. On the game cheat forums such patching (albeit, for a different purposes) was the norm, and probably still is for the games that aren't protected. And many embedded developers have their fights for code size quite often.
It is easy to not let addresses change, because compilers without “-O2+“ do lots of extra stack ops. Documentation is not needed there, because it is overflow fix, it is catchable by debugger and both caller and callee are right in bt. And the fact that this program was not recompiled for 20 years actually adds to the possibility of what was done. Modern compilers are much less forgiving.
Anyway, your points are pretty weak and oh-magic-driven, and I don’t see any reason gp comment to be gray or work to be called stellar. Though of course it was done by asm-skilled person.
I think it's easy in all the superficial churn of frameworks and languages to forget how much depth there is in our field. To me, writing a compiler isn't that big a deal anymore; it's the kind of exercise I might use to try a new language out. But when I was a sophomore in college, even after a few years of computer usage, it would have been magic to me.
It takes a lot of work to get to the point of skill demonstrated in this article... but there's still a lot of skill runway beyond that level of skill, too. It's simultaneously true that this is an impressive amount of talent, and that there are people for whom this would be an entertaining momentary side diversion from their normal job.
I kind of agree with the sentiment. It isn't that crazy.
We do this as a matter of course all the time. Patching a small handful of instructions is pretty easy. You could learn to do it on a week or less if you are a decent programmer.
Do it well? Do it quickly? Do it idiomatically and in a short amount of time.... Takes real skill.
I used to patch games for infinite-lives, or to allow my serial numbers to be accepted. Doing this wasn't hard, as somebody who grew up writing assembly language on 8-bit machines in the 80s.
One fun self-challenge was always to make my modifications as small as possible. e.g. one-byte changes were a lot more impressive than two-byte changes.
It is indeed a lost art. I can count with just one hand the amount of colleagues that I know that are capable of doing this. Also this is not assembly, it is object code.
Disassemblers exist. You can take the binary, generate the assembly code, fix it and then re-compile to find the needed changes. I cracked a few sharewares with OllyDbg this way (just for fun, never distributed), and I'm no "leet coder".
I wouldn't call it a lost art... Assembly is used many places, even for new projects. But it makes sense that assembly programming might seem impressive (or antiquated) to the HN crowd, which I have an impression is composed of a lot of newly grads, web developers, and comparatively few old hats.
Well, when you have people calling Electron based apps native.....
Not just writing assembly, rewriting a compiled object file without letting any of the addresses change, without having the source to work with, and presumably with almost no documentation, to patch a program that has been left untouched for almost 20 years.
Those properties come by definition. Addresses don't change because you can't (realistically) change things any much and move things around.
Basically, think of it like this: you have an old book, written in some magic runes and is told that a certain (quite short) paragraph is wrong and can be badly misinterpreted due to poor wording. You know, the magic spell goes kaboom.
You have tools that can easily and painlessly: a) translate the runes into a text that mere mortal can reasonably easily read; b) scrub runes off the page and write any new ones over; c) translate your text into runes. There is a simple correspondence between text length and how many runes it would take. Now, all you need is to write the new text that must be no longer than old one was. Not a trivial task, but not something extraordinary. Just rare, because we don't deal with magic runes those days as familiars take orders and handle all the gory details.
Writing assembly requires a skill. So does reading old assembly code of a particular function and figuring out what it did. That's admirable, but not something unbelievable.
It's just rarer to see those days, but not a lost art or anything like that. Crackmes are still alive. On the game cheat forums such patching (albeit, for a different purposes) was the norm, and probably still is for the games that aren't protected. And many embedded developers have their fights for code size quite often.
It is easy to not let addresses change, because compilers without “-O2+“ do lots of extra stack ops. Documentation is not needed there, because it is overflow fix, it is catchable by debugger and both caller and callee are right in bt. And the fact that this program was not recompiled for 20 years actually adds to the possibility of what was done. Modern compilers are much less forgiving.
Anyway, your points are pretty weak and oh-magic-driven, and I don’t see any reason gp comment to be gray or work to be called stellar. Though of course it was done by asm-skilled person.
I think it's easy in all the superficial churn of frameworks and languages to forget how much depth there is in our field. To me, writing a compiler isn't that big a deal anymore; it's the kind of exercise I might use to try a new language out. But when I was a sophomore in college, even after a few years of computer usage, it would have been magic to me.
It takes a lot of work to get to the point of skill demonstrated in this article... but there's still a lot of skill runway beyond that level of skill, too. It's simultaneously true that this is an impressive amount of talent, and that there are people for whom this would be an entertaining momentary side diversion from their normal job.
I kind of agree with the sentiment. It isn't that crazy.
We do this as a matter of course all the time. Patching a small handful of instructions is pretty easy. You could learn to do it on a week or less if you are a decent programmer.
Do it well? Do it quickly? Do it idiomatically and in a short amount of time.... Takes real skill.
I used to patch games for infinite-lives, or to allow my serial numbers to be accepted. Doing this wasn't hard, as somebody who grew up writing assembly language on 8-bit machines in the 80s.
One fun self-challenge was always to make my modifications as small as possible. e.g. one-byte changes were a lot more impressive than two-byte changes.
1 reply →
It is indeed a lost art. I can count with just one hand the amount of colleagues that I know that are capable of doing this. Also this is not assembly, it is object code.
Also this is not assembly, it is object code.
Disassemblers exist. You can take the binary, generate the assembly code, fix it and then re-compile to find the needed changes. I cracked a few sharewares with OllyDbg this way (just for fun, never distributed), and I'm no "leet coder".
Would the assembler maintain the same binary size and the exactly the same address module in the same order just like the article claims?
What they said is they found evidence that the binary was modified manually.
This is way more tedious that disassembling and reassembling a binary.
7 replies →
I wouldn't call it a lost art... Assembly is used many places, even for new projects. But it makes sense that assembly programming might seem impressive (or antiquated) to the HN crowd, which I have an impression is composed of a lot of newly grads, web developers, and comparatively few old hats.
>Also this is not assembly, it is object code.
It is a matter of hitting F4 in hiew.