Reddit reviews Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation
We found 18 Reddit comments about Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation. Here are the top ones, ranked by their Reddit score.
John Wiley Sons
This book covers rootkit development, not analysis, on Windows 7 and x86/IA32. It's a must read, if you're interested in rootkits.
While not yet released, it looks very promising. Over the years, Microsoft has continually introduced better protections against rootkits and malware in Windows. Among other things, the book will cover how some of the rootkits/bootkits seen in the wild have bypassed protections such as Secure Boot, kernel-mode signing, Patch Guard and Device Guard.
I'd also recommend having a look at the following books:
Also, Windows Internals for both Windows 7 and Windows 10 is a great reference to have laying around.
Copy paste from a post I made earlier
Malware RE isn't really all that much voodoo as it seems, you take the executable and break it down into steps.
First check out the PE headers and find what strings you can, characteristics. Figure out if the malware is packed or not.
A quick and dirty way to get an idea of what it does it run it with certain tools on the system and a linux box to intercept all network communications. This is called behavioral analysis.
After that you can load it into a disassembler like IDA Pro and start looking for interesting functions or windows API calls. Things like WriteFile, VirtualAllocEx, ReadFile then figure out that they are doing.
After that you can take it into your debugger (I like OllyDbg) and set some breakpoints at interesting functions to see what the malware is doing in the stack. Like I said, its not voodoo once you look into it further.
Creating the malware is a whole different story and outside my skill set. In fact I hate programming and know only high level programming, basically I can interpret code and what it wants to do. But I have an easier time reading Assembly (lol) than something like C++. But coding malware is just like coding anything else, design it for what you want it to do and get to work. Stuff like Stuxnet had probably at a minimum 10 extremely talented coders behind it.
Here is a great list of learning sources.
Cybrary.it Malware Analysis Course - Free
Opensource Malware Analysis Course - Free
Dr. Fu's Malware Analysis Course - Free
OpenSecurityTraining.info - Free
SANS FOR610 Reverse Engineering and Malware Analysis - Expensive
Practical Malware Analysis
Practical Reverse Engineering
Malware Analyst's Cookbook
For reverse engineering:
For malware analysis and malware techniques
For programming
This should be enough for you to get started.
Hey /u/Xerack! I'm the original author of the post linked here.
Appreciate the feedback! If you think I could clarify anything better, please let me know.
As far as resources for Reverse Engineering, I can provide you with a baseline that I would recommend starting with.
x86 Assembly:
If you don't know assembly language at all, this list of videos was where I picked up a decent amount of x86 assembly language.
A few good books would be:
Hands On:
Courses:
Tons of courses on youtube. I learn well from visual, so I recommend these youtube videos:
Beyond that, Google will always be your friend, and /r/reverseengineering. I also have a bunch of material for Malware RE, but that's a bit different than Software RE, though it is relatable.
Some resources which will indirectly help you for GREM
https://amzn.com/1593272901
https://amzn.com/1118787315
https://amzn.com/1593272898
Reversing: Reversing: Secrets of Reverse Engineering
Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation
Reversing: Secrets of Reverse Engineering - Is probably the most common book recommendation. Its an older book (2005) but its about as gentle as it gets in terms of the core concepts but its missing a bit due to its age (32bit RE only). I'd liken it to something like Hacking: The Art of Exploitation for exploit developers. Its a solid book, it covers the fundamentals but it'll take a bit more work to get up to speed.
Practical Reverse Engineering - This one is a newer book (2014) while it doesn't cover as many topics as the above book, its less dated in what it does cover, and it does cast a wider net covering things you'll see today like ARM and x64 instead of just x86. I tend to recommend starting with this book, using Reversing and the next book as a reference if there is a chapter of interest.
Practical Malware Analysis - While this one has more traditional RE introduction, where it excels is in dynamic analysis and dealing with software that doesn't want to be analyzed. Now, its from 2012 and malware has changed since then, so its age certainly shows, but again fundamentals remain even if technical details change or are expanded upon.
Practical Binary Analysis - This is the newest book of the list (December 2018). It wouldn't use it alone, but after you've gone through any of the above books, consider this an add-on. Its focus is on dynamic analysis and its modern. I'll admit I haven't read the entire thing yet, but I've been pleased with what I have read.
Edit: s/.ca/.com/g
It would be an... interesting team, since as I understand it reverse engineering x86 is mostly for people creating malware. And the security experts thwarting them, I suppose. Book on Amazon: Practical Reverse Engineering.
If someone was a programmer looking to expand their skillset into IT security, though...
In case you're talking about reverse engineering, malware analysis etc.:
Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation https://www.amazon.com/dp/1118787315 is very good and has a huge ARM part
I suppose you could just read Practical Reverse Engineering. The typical methods are explained there for reverse engineers. It's kind of an "arms race", so I doubt any one place will have a full set of up to date info. Also, companies who do this sort of thing will not usually be willing to outline exactly what they do and how they do it. Obviously, disclosing that would only help crackers.
http://www.amazon.com/Practical-Reverse-Engineering-Reversing-Obfuscation/dp/1118787315/ref=sr_1_1?ie=UTF8&qid=1406820088&sr=8-1&keywords=practical+reverse+engineering
Okay so there are a couple of good places to start with malware. The first is Malware Analyst's Cookbook. It is a pretty decent beginner level resource.
From there, Practical Malware Analysis is excellent and goes a lot deeper.
For free resources I've heard good things about Dr. Fu's Malware Analysis Tutorials.
You will need to have a strong understanding of reverse engineering. I like Practical Reverse Engineering or Reverse Engineering for Beginners. The latter is free.
With RE comes assembly. I learned from the free book PC Assembly Language. The RE books should have some info on assembly as well.
You should also know the systems programming API and OS internals for whatever OS you're interested in. This is most likely Windows, so I recommend Windows System Programming and Windows Internals. You can find similar books for Linux and macOS too. Having a good understanding of C and C++ is helpful for this. Also get comfortable using your assembly level debugger on your OS of choice. WinDBG, x64dbg, and OllyDBG are all good on Windows. GDB is pretty much the default on Linux, and LLDB on macOS.
I also highly recommend some scripting language, whether it's Python, Ruby, Powershell or whatever for hacking up your own tools.
Lastly, there is a list on GitHub with a ton of helpful links.
I think that's enough for now.
As far as demand it's hard to say and probably depends a lot on where you're from. It's certainly not like the demand for webdevs but there's also not nearly as many people with the skillset. I'm not a malware analyst myself, I'm more focused on security research and embedded development.
I know those skills are especially high in demand around the Washington, DC area with defense contractors and government agencies. Especially if you can get a security clearance. Most other security firms I know of are always looking for good people with strong reversing and OS internals knowledge.
Let me know if you have any questions and I will try to answer.
If you want the quick and dirty I suggest Practical Reverse Engineering:
http://www.amazon.com/Practical-Reverse-Engineering-Reversing-Obfuscation/dp/1118787315
I used this book back when I was learning how to use cheat engine to hack games. It teaches you basic assembly language in 3 major architectures, how to decipher ambiguous machine code, and the relationship between memory and processor. It's really a boon if you're going to dive that deep into computer science. If you can reverse engineer programs in run-time, you can do just about anything.
I'm not too sure if this is the sort of answer you're looking for because it appears that you are pretty new to all this but...
If you read these books, then you will know everything you need (ranked by reward to required effort ratio):
https://www.amazon.com/Practical-Malware-Analysis-Hands-Dissecting/dp/1593272901
https://www.amazon.com/Practical-Reverse-Engineering-Reversing-Obfuscation/dp/1118787315
https://www.amazon.com/Windows-Internals-Part-architecture-management/dp/0735684189
However, the books might be pretty difficult to understand with how much you currently know.
My recommendations then for self study:
Read all those and you will be in good shape ;)
EDIT: I hate trying to get reddit to do what I want.
Generally speaking, "reverse engineering" implies getting an executable (like a .exe file on Windows) and trying to figure out what it does at the level of the source code. Reverse engineering is a long and tedious process that is not as simple as it sounds for several reasons.
The first thing that you have to understand is how a program goes from source code to EXE (since we're going in the opposite direction when we reverse an .exe file). When a program is written in a high level language like C or C++, it can't be run by a computer until it has been compiled, a special process performed by a compiler. Compilers take the source code, and translate it first into a middle language called an intermediate representation that represents the logical structure of the program, and then based on that middle language emit machine code. Machine code (which can be translated into a human readable form called assembly language) is the binary language that the CPU actually uses to do computation - it contains very simple instructions like "move this data to this location in memory" or "add these two numbers together". Most compilers will also make a lot of optimizations in before emitting the machine code - for example, if they see a certain piece of data being accessed and stored unnecessarily, they may move the code responsible for the redundancy to another place in the executable to avoid wasted operations. The compiler will finally output a file called an object file, which contains optimized machine code.
However, this file is generally not executable - it still has to be linked by the linker, (which sometimes automatically runs after the compiler). The linker performs several tasks, like fixing up absolute addressing to ensure that a program can be loaded anywhere in it's address space, as well as providing references to shared libraries. Usually when writing big programs, developers will use already-written code, like the C library or other vendor specific packages, by referencing it in the source code. For example, C source code can use statements like
include <stdio.h>
to indicate that the program includes references to the standard input/output library in the C library, which is used to allow user-provided data and to print data to the screen, among other things. So, it's the linker's job to ensure that these libraries are included in the final executable and that the other object files can reference them correctly. To make matters worse, the linker will build the executable program in whatever file format the operating system uses (PE on Windows, ELF on Linux, and Mach-O on OSX), and these file formats store the program data and code in separate locations. However, the linker handles this cleanly and produces a compiled, optimized, and linked program in the right format, which can then be executed. So that's how it happens normally.
So now, let's do it in reverse. Suppose you have suspicious.exe, a file that you think is malware and you want to find out what it does so that you know whether it's dangerous or not. Suspicious.exe is a compiled and linked executable, and since it was optimized, you don't necessarily have a 1-to-1 correspondence between each machine code instruction and each line of source code (and you don't have the source code anyway). Furthermore, the Intel x86 architecture that most commercial personal computers use in their CPUs uses variable length machine code instructions - some of the instructions will be longer than others, so it is very difficult to look at them in a binary and figure out what is doing what. This is where a disassembler is used - a program that takes a raw binary file and emits human readable assembly language. Because of variable length instructions, some disassemblers even emit the wrong assembly instructions sometimes! However, because the program has to be able to run consistently and reliably when given to the CPU, there is always a way to disassemble it into the correct machine code - it sometimes just takes a few hours (and a headache or two).
Now, you've disassembled the file using a tool like IDA Pro (which can cost hundreds or thousands of dollars, depending on the license), and you have human-readable assembly. So why is it still hard to figure out what the program does? Firstly, any descriptive variable names that a programmer used to make the source code more easy to read are gone because the compiler got rid of them once it generated the intermediate representation - so you don't even know what the various memory references are where data is stored. Secondly, while you can tell where functions begin and end, you can't necessarily tell what they do - they're just blobs of assembly, and sometimes not even that; if the functions were included in a shared library, they'll often be just references to the address in memory where the imported library is placed when the operating system loads the process into its address space (it depends on whether the executable is dynamically or statically linked, but that's a more in depth and tangential discussion). You also don't where important data structures - like strings or pointer tables - are because what the disassembler doesn't recognize as code, it'll just call "data" and leave it at that. Thirdly, most of the data in the program depends on the memory state while it's running, which you can't tell just by looking at the assembly. You need to actually run suspicious.exe.
So you take a look at this mess, ask yourself why you chose this job in the first place instead of being a web developer even though they get paid about the same as you, open another can of Rockstar, and you get to work. Generally, you'll start suspicious.exe in a sandbox environment like a virtual machine using a debugger, which is a special program that will allow you to halt it and examine its memory state, register states, and other activity. As the program executes, you will begin to notice behaviors that resemble C structures - how you actually do this is a huge discussion that people have written entire books about, but suffice it to say for now that it comes with experience. Furthermore, if you use IDA (or keep a notebook), you'll write down lots of notes about the program behavior, and use Microsoft's MSDN pages (or Apple's developer documents or the Linux man pages, depending on what environment your executable runs in). Eventually, whatever it is that you were aiming to find out becomes clear, or you quit out of sheer frustration (but usually and hopefully the former).
Bear in mind that most people don't aim to entirely reverse engineer every bit of machine code in an executable. A lot of it isn't related to what you're trying to discover, and so part of the game is first finding what pieces of code are actually relevant (which you do with a debugger by stopping the program's execution once it starts doing stuff relevant to your reversing purposes), then reversing those little parts of the code.
http://www.amazon.com/Practical-Reverse-Engineering-Reversing-Obfuscation/dp/1118787315/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1405264006&amp;sr=1-1&amp;keywords=practical+reverse+engineering
Which book is better for very begginers?
https://www.amazon.com/Practical-Malware-Analysis-Hands-Dissecting/dp/1593272901/
or
https://www.amazon.com/Practical-Reverse-Engineering-Reversing-Obfuscation/dp/1118787315