How to start RE/malware analysis?

Many people approach me asking more or less the same questions: how to start RE, how to become a malware analyst, how did I start, what materials I can recommend, etc. So, in this section I will collect some hints and useful links for the beginners.

//NOTE: this article is periodically updated with new materials

The topic of reverse engineering (RE) is very broad. You can reverse engineer all sort of software for all sort of platforms. You can even reverse engineer hardware. But in this article I will focus mostly on the subset of skills that you need for analyzing malware on Windows.

Tools & environment

In order to not infect yourself, you need to prepare an isolated virtual environment with all the tools installed, where you can deploy the malware sample and analyze it. More details:

Learning tools

Among the tools that you will use on daily will be debuggers and disassembles, such as IDA, Ghidra, BinaryNinja, OllyDbg (or some of its derivatives such as ImmunityDbg), x64dbg. Very useful and advanced, but not as user-friendly is WinDbg – also worth to learn it, but I don’t recommend it to beginners. Below you will find some courses that will help you familiarize with those tools:

How to get malware samples, intelligence etc.?

If you are a beginner and not a member of any community yet, you can find fresh, nicely cataloged samples for free here:

You can also download them from some of the free online sandboxes and open repositories, such as:

For a threat intelligence, information about outbreaks, hashes of fresh samples etc, I recommend you to join twitter and follow some of the researchers that you know.

Check also some malware trackers, where you can find live links to the latest malware, and some more information about campaigns:

Common malware families

A catalogue of various articles on particular malware families you can find here:

Mind the fact, that the sourcecode of several popular malware families already leaked (i.e. ZeuS, Tinba, Gozi , Pony, Alina, Carberp). A bigger collection is available at VXUnderground, here. Strains that are currently in circulation may be based on them, or have some fragments of code copied. Hours of reading the leaked code may save you days of analysis! And even when you are dealing with a malware that was written from the scratch, the experience gained by reading the leaked code can help you recognize common approaches.

Similarly, malware authors don’t hesitate to adapt the toolkits that were written for a legitimate purpose, i.e. for Red Teams. An example of such tool that was leaked and is often being used in malware is Cobalt Strike (Avast on Cobalt Strike, Mandiant on Cobalt Strike).


Reversing is an art that you can learn only by doing, so I recommend you to start practicing directly. First try to practice by following step-by-step writeups.

Check also writeups from an annual FlareOn Challenge (including my writeups that are on this blog). It contains variety of reverse engineering tasks with growing difficulty level.

Inside the compiled application

Reversing a native application requires you to understand some low-level concepts. If you want to focus on Windows malware (as I do), you will most of the time be dealing with PE files. When you watch an application under a debugger, you see it in a disassembled form – transformed to assembly language (assembler). So, the more about assembler, PE structure, and operating system you know, the easier will be for you to follow.

Here and here you will find some gentle introduction to x86 assembly. To get a deeper understanding and a grasp on other platforms too, check this free course. An invaluable, comprehensive resource about assembly is the official Intel manual.

For learning the PE format, I recommend you to read [this] + the articles of Matt Pietrek (i.e. [1] [2] [3]), and Ange Albertini’s posters (PE101, PE102). You can start by my slides about PE. Check also PE-bear and try to view various executables, compare it with what you read about the format.

Programming for RE/malware analysis

Not all malware analysts are proficient programmers, but you need to have some basic skills, and at least be able to understand the code. The more fluent programmer you are, the better for you – you will be able to experiment with the techniques and create some tools helping you in analysis.

The languages that I use on daily are C/C++, Python, and assembler, and I am mostly agree with [this] MalwareTech’s article.

Some people ask me from where I learned particular languages, so here are some of the sources:

Windows System Programming” is a very solid book covering Windows API and the related topics.

Malware unpacking

Malware usually comes packed, and in order to analyze the core you will have to unpack it from the outer, protective layer. Malware distributors may use legitimate, well-known packers and protectors, as well as custom ones, prepared with a special focus on AV evasion. This article explains the concept.

To get familiar with manual unpacking, check the series of tutorials “Unpacking With Anthracene” [mirror: Unpacking With, pass: tuts4you], and other tutorials from Tuts4You.

My vidoetutorials about unpacking malware are available here.

Protectors using virtualization

A separate class of executable protectors, also applied in malware, are the ones using virtualization. In contrast to the classic ones, they not only wrap the original code into another layer, but also modify the existing code, rewriting some fragments in a way that they can run only on a built-in Virtual Machine. This type of protectors are especially difficult to analyze, as they cannot be unpacked in a typical way. Sometimes reconstruction of the original executable is impossible, or time inefficient. I usually deal with them with the help of tracing. However, for less complex variants, it is possible to analyze the full VM logic, and reconstruct the code.

Example of (legitimate) protectors of such type are VMProtect and Themida.

Below you can find some links on analysis of this type of protection method:

You can practice de-virtualilzation on some dedicated crackmes – packed by simple, custom VM-protectors. Examples:

Malware injection/impersonation methods

Most of the malware injects code into other processes. The common purposes of injections are: impersonating other applications and hooking. The implant can be a shellcode, as well as a full PE. Used methods are various. Among PE impersonation techniques, the most popular is Process Hollowing (aka RunPE) and Reflective DLL injection.

Code implants can be detected i.e. with the help of PE-sieve/HollowsHunter. PE implants are detected by default, and shellcode implants optionally.


Hooking is a technique that allows to intercept API calls. Malware uses this technique for various purposes, such as: being unnoticed by monitoring applications, intercepting the data being sent etc. From the other hand side, the same technique is also used by sandboxes, to monitor malware.

How the hooking works:

How a simple, userland rootkit utilizes hooking:

Hooking can be detected i.e. with the help of PE-sieve/HollowsHunter. PE-sieve detects inline hooking by default, and IAT hooking optionally. In HollowsHunter, the detection of both is optional.

Kernel Mode malware

Most of the malware you will encounter works in userland. But from time to time you can come across some kernel mode malware modules. Reversing them is more difficult, and it will require different environment setup.

Setting up the environment for analyzing malware in kernel mode will follow the same steps as I described for Windows Kernel Exploitation practice, here:

Kernel mode modules are structured completely different than the ones that you encounter on daily in userland. This is why, before analyzing them, I strongly recommend you to get a general knowledge on drivers. In my opinion, the best introduction to the topic is a book “Windows Kernel Programming” by Pavel Yosifovich , and the set of accompanying examples that is available for free here. A briefer intro into the methodology of analyzing a driver (by  Matt Hand) can be found here. Other notes on the topic, (by VoidSec) are available here (although the author focus mostly on Driver RE in context of exploitation, but most of the tips are valid also for malware researchers).

Below, you can find a very nice tutorial about reversing a kernel more rootkit:

More about techniques used by kernel mode rootkits you will find, i.e. here:

Keep in mind that some of the techniques of classic kernel mode rootkits no longer work on modern Windows.

Even lower level…

It is possible to install malware implants at even lower level than the Operating System’s kernel space. There are malware out there that infect MBR, such as Petya, and other bootlockers. A separate category are bootkits, which can hijack the whole boot sequence of the system, starting from the earliest stages. Of course preparing such implant is much more difficult than writing a conventional malware, so it is done very rarely. Here you can find a very interesting research on the malware that infects UEFI firmware: “Moon Bounce”.


YouTube channels


Tips & ideas

How to get a job as malware analyst?

From my experience, the best way is to contribute in the community. Be active, start researching on your own, show your passion, share what you learned. There is a big and very friendly community of researchers on twitter, it helped me a lot finding a job in this field. So, if you are not there yet, I strongly recommend you to join.

33 Responses to How to start RE/malware analysis?

  1. withrich says:


  2. More about techniques used by kernel more rootkits you will find, i.e. here: s/more/mode

  3. Pingback: Reverse Engineering in CTF Tips – fareedfauzi

  4. Nanna says:

    What are some CS classes hat help improve Reversing Skills?

  5. Eilon says:

    Awesome as always.

  6. Gio says:

    Many thanks for sharing this! Would you tell some more about your environment for malware analysis? Which setup are you using, whether you use hardened VM and how hardened, what is your typical workflow, if you use any sandboxes too, if and how you store samples, etc

    • hasherezade says:

      Hi! My setup for malware analysis is very simple. As a base system I use Linux (Debian) with Wireshark (to sniff the traffic from the guest if needed). Then I use Windows on VirtualBox. On Windows I have all my tools installed (PE-bear, debuggers, PIN tools, SysInternals Tools, Fiddler, etc). I don’t usually use hardened VMs, just a basic setup.
      I start from viewing a sample in PE-bear, then I am unpacking it (with PE-sieve, or manually if needed). Once I have the sample unpacked, I view it again in PE-bear, to get a general overview. If it is not obfuscated, I just open it in IDA and start analyzing statically. If the sample is complex or obfuscated, I start from tracing it by a PIN tracer. I usually use TinyTracer ( first), then eventually some more complex traces. They give me tags that I am loading to IDA to better understand the obfuscated parts.
      Depending on a sample, I can switch from static to dynamic analysis multiple times. Sometimes I may start from a behavioral analysis, observing API calls with ProcMon, observing eventual traffic with Fiddler or Wireshark.
      I do several iterations, renaming functions in IDA, adding comments.
      When the sample is defending itself against analysis, I find those branches by PIN tracers, and patch them to make the malware “blind”. Sometimes I import functions from malware to experiment with them (with libPeConv).
      I hope it answers your question 🙂

  7. Sanyuj says:

    Thankyou for sharing all of this @hasherezade !!!
    I came to know about you from a paper i read about PrincessLocker unpacking.
    Love your content and wish to contribute to the community soon!

  8. ahmedES says:

    any recommended resources to learn shellcoding ?

  9. Pingback: trimstray/the-book-of-secret-knowledge

  10. Adrian Dostoevksy says:

    Thank you for this amazing post.

  11. regular_user says:

    which is your recommendation? “Windows 10 System Programming” or “Windows System Programming”

  12. Jesus Conejo says:

    Hi Alexandra. First of all thanks so much for this Git plenty of information. I have put a message on one of your Youtube videos, sorry for repeat it here. I’m studying the Phobos ransomware. I have seen your analysis and is amazing. I also have decompile it with IDA to assembler and C but it’s a nightmare to study it with all these generic “sub_xxx”….is possible for you to send me the C code (with the variables and routines named) please?. Thanks!!

  13. Jesus Conejo says:

    Hi. Thanks for answering. Which CSV file?..Do you have a CSV with Phobos data?….My idea is trying to understand how Phobos creates the AES key. My company contracted somebody to decrypt some files and he got it so it’s possible. He only asked for the IV value (in the file name) so all the information for decrypt must be into the encrypted files . We have too the tool from the Phobos hacker for decrypt but it do it in two steps, first you must look for the file for it to see the RSA public (?) key, this key must be sent to the hacker and then he/she must send to you the AES Key that you must write in the tool for decrypt the files. Getting RSA private key from public key is not possible in a short time (calculating for some hundreds years i think) but knowing how Phobos create/mount the AES key could be a solution. What do you think?. Thanks!

    • hasherezade says:

      If you read carefully my analysis at Malwarebytes blog ( you will see that I already found how the AES key is generated. They use CryptGenRandom (a strong random generator). So, as my analysis concluded, the ransomware is NOT decryptable: “[…] the used encryption algorithm is secure. It is AES, with a random key and initialization vector, both created by a secure random generator. The used implementation is also valid: the authors decided to use the Windows Crypto API.”

      There is still some (small) window of chance to decrypt it without paying the ransom, but only if you manage to dump the generated key from the memory of the running ransomware. I demonstrated it on the video ( ) – yet, this scenario is not applicable in most of the cases.

      • Jesus Conejo says:

        Hi Alexandra. Thanks so much. I meant really to found the random number inside the AES key, because I have a encrypted and decrypted file (the problem would be if I only had a encrypted file). In a brute force way I could implement a simple app to look for that rand number. As I already comment we contracted a little company for decrypt some files and they did it without knowing anything, just having the files…(perhaps contacting with the hacker and sharing the money, who knows) so there must be a way. I’m going to study your video. Thanks!!

      • hasherezade says:

        The key consists of 32 values, each from the range 0-255 (demonstrated here: It gives 256^32 possibilities that we need to check in order to brutforce the key.
        Means it is impossible to brutforce it in our lifetime.
        Maybe you can find my presentation on this topic helpful:

        The company that proven to decrypt the data probably got them decrypted by the cybercriminals themselves.

      • Jesus Conejo says:

        Hi again. Amazing video!!!!. I understand, but you are watching when Phobos is going to encrypt…what happend when Phobos has finished and it has encrypted all files?, IV changes when it starts another encrypting “session” (you can see it that in the same hard disk you can have several IV’s in the name of the encrypted files corresponding, I suppose , to different AES Keys)….How you could find an AES key from a old “encrypting session”?…..Thanks!!

      • hasherezade says:

        this is why I said earlier: it is impossible to crack it. once the AES key is destroyed, there is no way to recover it. and as I also mentioned earlier, brutforcing it is impossible because there are too many values in the range, and checking all of them will exceed our lifetime.

      • Jesus Conejo says:

        Yes, I understand what you say. My hope was that AES were built with some constant values plus random (IV + volume_serial + random value for example) and not only the random value. If not of course is impossible. I’m watching (re-reading your deep analysis) that at generating this 32 byte value it looks for a context, perhaps looking for a key container?…It’s not clear for me the way virus reads/hide the strings and file extensions….It hides those strings in memory? if so..which AES key uses (if there are not any files to encrypt) ?, …what do you think?. Thanks!!!

      • hasherezade says:

        “My hope was that AES were built with some constant values plus random (IV + volume_serial + random value for example) and not only the random value” – but this is not the case. All the 32 values are completely random, generated by a cryptographically strong generator. This is why cracking it is really impossible, sorry.

  14. Jesus Conejo says:

    Hi Alexandra. Yes, ok. Just for continue learning…what about the encrypted strings questions?…what do you think?. Thanks so much!!

  15. aaa says:

    Windbg Preview – use it for kernel debugging.

  16. Pingback: List of Step by Step Manuals, Howto Guide & Tutorials for Every Software Engineers -

  17. moshe says:

    Your links to tuts4you aren’t working, for example the unpacking section.
    can you please fix them?

  18. Holy smokes! I just noticed this resource and this is absolutely outstanding!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s