Reverse Engineering Malware 101

+1 for dnSpy. It is the only .NET debugger/decompiler I use these days.

What do you think of dotPeek by JetBrains?

https://www.jetbrains.com/decompiler/

+1 for dnSpy. It's not only a decompiler, but also a debugger. Additionally, it has the best IL editor I've ever used. A parser for the native parts of the PE file (headers and sections) is a great feature too.

Thanks for the pointer to dnSpy. I'd been using Lutz's .NET Reflector, but since Red Gate took it over, and despite even paying for the Pro license (I needed to be able to debug and step through assemblies that I didn't have the source for, and there was nothing similar at the time), it's become a total pain in the arse to use. This looks like it'll comfortably replace it.

In general, dropping a sample into a VM and executing it is an obvious - and dangerous - approach. Real-world malware has been known to detect VMs and refuse to run. Or attack the VM, escape, and infect the host.

Broadly, it's not a reliable approach and relies to a surprising extent on the cooperation of the malware package.

VMs are extremely useful for malware RE, but there are a few potential concerns:

- VM breakouts are a security concern. While fairly uncommon this is a risk. Most of that risk exists in drivers and VM acceleration tools and can be mitigated.

- Some malware packers will detect virtual machines and refuse to run. You can bypass this by cracking the VM check of course - but that can sometimes be harder than dumping it on real hardware, depending on the protection and specifics of the situation.

These are much bigger concerns if you're working with 0 day high level stuff and not just typical skiddie malware you pulled off usenet or a fake crack in a youtube video. Most of that stuff is just iStealer or a shitty DDoS-focused RAT and whatever "FUD" RunPE packer was on sale for the cheapest price on HackForums or similar that day. Some people will play this up to be a bigger concern than it realistically is - but a VM will protect you from the malware in almost every case I've seen. Just remember to keep your VM software up to date and avoid using unnecessary pieces.

My paranoid setup is a dedicated machine with 2 VMs, one victim VM and one router VM, quite similar to their setup there. The difference is, my router VM goes over Tor and doesn't allow traffic from the second interface out in any other way. I also use libvirt with kvm with as few extensions and drivers as possible to prevent most VM-based attacks.

Malware will often detect the presence of a VM and refuse to run, requiring you to identify and defeat the VM checks or more insidiously appear to run normally but modify the actions it takes. [0]

Generally these problems are solved by modifying the VM so it can no longer be detected. [1]

[0] http://malware.dontneedcoffee.com/2016/04/bedepantiVM.html

[1] http://www.kernelmode.info/forum/viewtopic.php?f=11&t=3478

The only fields in the PE header dealing directly with the stack are:

   SizeOfStackReserve:           0x00100000
   SizeOfStackCommit:            0x00001000

Certainly nothing there that indicates which way the stack should grow. PE does not deal with the stack directly.

ARM supports the stack growing in either direction, but on Windows ARM it grows down.

PE/COFF does have some architectural differences though; for example, the relocation types differ across architectures.