Introduction to reverse engineering and assembly
kakaroto.homelinux.net
kakaroto.homelinux.net
Self studying that book -- along with the free video lectures[1] by the authors -- equipped me practical knowledge that's applicable as a software engineer who strives to grasp an understanding of the entire system.
[1] https://scs.hosted.panopto.com/Panopto/Pages/Sessions/List.a...
You begin by combining electrical logic gates into gradually more complex chips, then assemble the components of a computer, write an assembler, then a compiler for a high level toy language a bit like Java. Finally you program a game (such as Tetris) in that high level language.
It is available on Coursera, you can access it for free but have to pay to have your work marked, which is definitely worth it.
It really demystified that magical bridge between hardware and software for me - "How does typing text on this keyboard physically alter the flow of an electrical circuit?"
Basically you start with only NAND gates available. Using this you have to connect together inputs/outputs etc to make NOT, AND, OR, XOR gates. Then you use these to make gradually more complex chips, such as MUX, HALF-ADDER, ADDER. Then you make an APU etc, eventually making a CPU.
At each stage they tell you the design, but not the implementation.
The assembler targets the CPU you build. The compiler targets the assembly language etc.
You understand the whole stack, and it is a real computer, although simplified as much as possible.
~ The Eternal Flame, by Bob Kanefsky
When I started trying to interpret assembly instructions by keeping track of the registers, stack, and branches, but that ended up being way too much bookkeeping and didn't really give any more insight on what the code actually does.
Keeping a text file of C code though and adding lines as you go through the instructions is really fitting and practical. C is abstract enough to not care about most bookkeeping of registers and stack management, and branches can be written in nice nested if-else blocks that are familiar to most programmers and provide a visual structure that is compact and practical. On the other hand, C is low enough to deal with memory addresses almost directly, allowing you to easily transcribe any address arithmetic that happens, and if you're familiar with what stucts get compiled into, you can very nicely spot them in disassembled code and keep your high-level reverse engineered code structured and nice.
Very nice guide and a very good starting point in reverse engineering, especially if you have at least some experience with assembly.
A lot less complex to start and you still learn the magic.
[1] http://problemkaputt.de/gmb.htm [2] https://github.com/avivace/awesome-gbdev
- https://github.com/radareorg/cutter (GUI for Radare2, free alternative to IDA)
- https://github.com/eteran/edb-debugger (debugger, free alternative for OllyDbg)
- http://hte.sourceforge.net/ (hex editor, disassembler, free alternative for Hiew) (open a binary, then press F6, select image format to get started, e.g: elf/image or pe/image)
- http://ref.x86asm.net/coder64.html List of x86-64 opcodes
- https://godbolt.org/ REPL that shows asm for given C/C++ code.
The syntax the author uses isn't even proper at&t or Intel, it's some weird hybrid of both.
https://blog.steve.fi/how_i_started_programming.html
Later I started doing similar things on shareware and trial-locked applications for the PC, via sites such as +fravia's reverse-engineering site.
These days people put out "crackmes" which are fun challenges if you want to test your reverse-engineering skills, and while I always pay for software these days, when I need it, there's still a lot of fun to be had patching binaries to allow your preferred serial number to be accepted!
+ORC got me into programming too. Great days cracking winzip and defeating parental controls :-)
I often have trouble explaining reverse engineering to people without raising eyebrows. People think its hacking
However like a lot of other similar jobs you will fairly quickly hit a ceiling in terms of career progression at which point the only way up is becoming a manager of sorts.
Even if it only happens once or twice a year, if you're the only person on your team who can figure out how to work around some framework or OS bug, people will think you're a magician. Stuff like that can make performance review cycles all by itself.
It really depends on the type of work you're doing, though. Most people got into reverse engineering because they find it fun. If you hate it, there is probably other stuff you can spend your time on more productively.
Malware analysis. Limited job opportunities and companies, very specialized skill set, but good pay, challenging, and exciting.
You can't be a hack who programs through Stack Overflow - either you know your shit or you don't - few people can help you if it's something nobody has ever seen.
Here's G cache: http://webcache.googleusercontent.com/search?q=cache:dH0AFM8...
The OP, afaict: https://puri.sm/posts/primer-to-reverse-engineering-intel-fs...
Thanks for sharing!