6 ms·
Reverse Engineering Malware 101
- problems 10y agoLooks 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.
- micaksica 10y ago+1 for dnSpy. It is the only .NET debugger/decompiler I use these days.
- bathory 10y agoWhat do you think of dotPeek by JetBrains? https://www.jetbrains.com/decompiler/ https://www.jetbrains.com/decompiler/
- lowleveldesign 10y ago+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.
- teh_klev 10y agoThanks 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.
- wonderous 10y agoWhen does running malware in a virtual machine (VM) not make sense, is it commonly not possible, etc.?
- Kalium 10y agoIn 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.
- mikevm 10y agoHow common are VM escapes anyway?
- mi100hael 10y agoNot widespread, but they do exist. https://www.zerodayinitiative.com/blog/2017/3/16/pwn2own-2017-day-three-schedule-and-results https://www.zerodayinitiative.com/blog/2017/3/16/pwn2own-201...
- moyix 10y agoNot 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.
- Kalium 10y agoYeah. Unless the analyst is your target environment, I wouldn't expect to see it a serious current VM escape. I might expect to see someone including an antique attack against some old Sandboxie or something, but nothing more.
- mech_eng_lewis 10y agoDoes 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?
- SCHiM 10y agoThe 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.
- smeenai 10y agoARM 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 10y agoThis looks really cool, can't wait to dig in. Is it legit to redistribute that victim VM Windows 7 image?