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.
Re:Reverse Engineering Malware 101
by teh_klev on Thursday March 30, 2017 @09:20AM
(#13995058)
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.
Re:Reverse Engineering Malware 101
by lowleveldesign on Thursday March 30, 2017 @02:32AM
(#13993379)
+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.
Re:Reverse Engineering Malware 101
by problems on Thursday March 30, 2017 @04:49PM
(#13998748)
It lacks many of the more advanced features like integrated debugging and deobfuscation and it isn't open source, so unless it happened to work better with a given executable I probably wouldn't use it.
Re:Reverse Engineering Malware 101
by problems on Wednesday March 29, 2017 @04:33PM
(#13990307)
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.
Re:Reverse Engineering Malware 101
by problems on Thursday March 30, 2017 @04:18PM
(#13998538)
You're right - if they're zero day. If you don't update your VM and someone lugs some old ones around just to see you could still get bit. Like I said though, odds are actually very low and it's probably not as major of a concern as many people make it out to be.
Re:Reverse Engineering Malware 101
by goatsi on Wednesday March 29, 2017 @04:39PM
(#13990358)
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]
Re:Reverse Engineering Malware 101
by Kalium on Wednesday March 29, 2017 @04:31PM
(#13990286)
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.
Re:Reverse Engineering Malware 101
by moyix on Wednesday March 29, 2017 @05:59PM
(#13991007)
Not widespread is a bit of an understatement. In the context of malware analysis I would be astonished if someone bothered to use a VM escape bug. They're valuable; you don't waste them by sticking them in a piece of malware to pwn some poor malware analyst's machine.
VM detection is much much easier, so there's not much point.
Re:Reverse Engineering Malware 101
by matt_wulfeck on Thursday March 30, 2017 @02:38AM
(#13993407)
I was thinking the same thing. Who would waste an unpatched vm escape bug just to nab some poor souls laptop, which can be wasted and reformatted in an hour? Sounds like a colossal waste and I bit there's very, very few (if any) examples of it happening in the wild.
Re:Reverse Engineering Malware 101
by giancarlostoro on Thursday March 30, 2017 @03:31AM
(#13993593)
I have a feeling escaping from Windows into a Ubuntu host system would not be as effective (though I wouldn't doubt it impossible) as escaping into a Windows OS which is usually the bigger / main target for malware.
Re:Reverse Engineering Malware 101
by mech_eng_lewis on Wednesday March 29, 2017 @05:21PM
(#13990680)
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?
Don't screw around with other .NET decompilers, use 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.
https://www.jetbrains.com/decompiler/
- 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.
https://www.blindseeker.com/AVATAR/AVATAR-3-18-17.pdf
https://blindseeker.com/blahg/
Also:
https://cloudplatform.googleblog.com/2017/01/7-ways-we-harde... | https://news.ycombinator.com/item?id=13483603
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
Broadly, it's not a reliable approach and relies to a surprising extent on the cooperation of the malware package.
https://www.zerodayinitiative.com/blog/2017/3/16/pwn2own-201...
VM detection is much much easier, so there's not much point.
I might expect to see someone including an antique attack against some old Sandboxie or something, but nothing more.
Any known breakouts from Windows guests in VirtualBox on Linux?
There have been others. In short, no VM is completely safe.
PE/COFF does have some architectural differences though; for example, the relocation types differ across architectures.