
Reverse Engineering Malware 101 - j_s
https://securedorg.github.io/RE101/
======
problems
Looks good, one comment on tooling though:

Don't screw around with other .NET decompilers, use dnSpy.

[https://github.com/0xd4d/dnSpy](https://github.com/0xd4d/dnSpy)

It's fully open source, integrates with deobfuscators and includes a binary-
level debugger which doesn't require VS separately. Plus it lets you patch
assemblies and export debugged data easily which is how I extract most .NET-
based packers these days.

~~~
bathory
What do you think of dotPeek by JetBrains?

[https://www.jetbrains.com/decompiler/](https://www.jetbrains.com/decompiler/)

~~~
milcron
It's free-of-charge but not open-source.

------
wonderous
When does running malware in a virtual machine (VM) not make sense, is it
commonly not possible, etc.?

~~~
problems
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.

~~~
j_s
If you want to get into VM setup:

[https://www.blindseeker.com/AVATAR/AVATAR-3-18-17.pdf](https://www.blindseeker.com/AVATAR/AVATAR-3-18-17.pdf)

[https://blindseeker.com/blahg/](https://blindseeker.com/blahg/)

Also:

[https://cloudplatform.googleblog.com/2017/01/7-ways-we-
harde...](https://cloudplatform.googleblog.com/2017/01/7-ways-we-harden-our-
KVM-hypervisor-at-Google-Cloud-security-in-plaintext.html) |
[https://news.ycombinator.com/item?id=13483603](https://news.ycombinator.com/item?id=13483603)

~~~
j_s
Also
[https://twitter.com/Carlos_Perez/status/848698806187307008](https://twitter.com/Carlos_Perez/status/848698806187307008)

------
mech_eng_lewis
Does the PE standard differ for x86 and ARM? Windows runs on ARM now right,
but in ARM I believe the stack grows up (to higher memory addresses) and in
x86, as most people know, it grows down. Does anyone know if PE accounts for
this? Or is it just abstracted away in PE?

~~~
smeenai
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.

------
elipsey
This looks really cool, can't wait to dig in. Is it legit to redistribute that
victim VM Windows 7 image?

