Been diving into malware analysis lately and wanted to see how others approach it.
When I get a new sample, my usual flow is:
Check it with file and strings — quick look for anything obvious
Run it in a sandbox to see behavior
Fire up x64dbg or IDA if it's worth a deeper look
I'm not advanced at reversing yet but I'm learning. Crackmes helped me understand basic assembly and control flow.
For those who do this regularly — what's your process? Any good resources for someone moving past the beginner stage?
Also curious if anyone's got a good source for fresh samples to practice on. Not asking for anything illegal — just stuff to tear apart and learn from.
Once you get comfortable with the basics, one thing that helped me was focusing less on individual instructions and more on identifying the protections first.
My typical workflow is something like:
- Identify the file type (Detect It Easy (DIE), PEStudio, Exeinfo PE, TrID).
- Check for packing, virtualization, or obfuscation. DIE and PEStudio can often identify UPX, Themida, VMProtect, .NET, Delphi, Go, Rust, and many other compilers/packers.
- If it's managed code (.NET), I'll usually start with ILSpy since decompilation is often much faster than jumping straight into a debugger. For Java, typically you can open up the Jar file as an archive using 7Zip and you can decompile the class files in IntelliJ. If it's obfuscated then deobfuscation is obviously your next feat to overcome.
- If it is an AutoIt script my go to is Autoit-Ripper.
- If it's native code, I'll see whether it decompiles cleanly in Ghidra, IDA, or Binary Ninja before deciding whether dynamic analysis is necessary.
- If it's packed or heavily protected, I'll spend time unpacking or dumping memory before trying to reverse the actual payload. There's little value in analyzing thousands of junk instructions generated by a packer.
- Only after that do I move into dynamic analysis with x64dbg or an isolated VM to correlate the decompiled code with runtime behavior.
A few things that accelerated my learning were:
- Learning common compiler patterns (MSVC, GCC, Clang, Delphi, Go, Rust).
- Recognizing common packers, protectors, and obfuscators before opening the binary.
- Understanding Windows internals (PE format, PEB, TLS callbacks, imports/exports, SEH, API hashing).
- Comparing decompiler output with the original assembly to understand why the decompiler generated certain code.
For practice,some good resources include:
- MalwareBazaar (for research in an isolated environment)
- theZoo malware repository
- Finding malware collections on GitHub for testing.
(Jul 27, 2026 08:39 PM)Tha Sneak Wrote: Once you get comfortable with the basics, one thing that helped me was focusing less on individual instructions and more on identifying the protections first.
My typical workflow is something like:
- Identify the file type (Detect It Easy (DIE), PEStudio, Exeinfo PE, TrID).
- Check for packing, virtualization, or obfuscation. DIE and PEStudio can often identify UPX, Themida, VMProtect, .NET, Delphi, Go, Rust, and many other compilers/packers.
- If it's managed code (.NET), I'll usually start with ILSpy since decompilation is often much faster than jumping straight into a debugger. For Java, typically you can open up the Jar file as an archive using 7Zip and you can decompile the class files in IntelliJ. If it's obfuscated then deobfuscation is obviously your next feat to overcome.
- If it is an AutoIt script my go to is Autoit-Ripper.
- If it's native code, I'll see whether it decompiles cleanly in Ghidra, IDA, or Binary Ninja before deciding whether dynamic analysis is necessary.
- If it's packed or heavily protected, I'll spend time unpacking or dumping memory before trying to reverse the actual payload. There's little value in analyzing thousands of junk instructions generated by a packer.
- Only after that do I move into dynamic analysis with x64dbg or an isolated VM to correlate the decompiled code with runtime behavior.
A few things that accelerated my learning were:
- Learning common compiler patterns (MSVC, GCC, Clang, Delphi, Go, Rust).
- Recognizing common packers, protectors, and obfuscators before opening the binary.
- Understanding Windows internals (PE format, PEB, TLS callbacks, imports/exports, SEH, API hashing).
- Comparing decompiler output with the original assembly to understand why the decompiler generated certain code.
For practice,some good resources include:
- MalwareBazaar (for research in an isolated environment)
- theZoo malware repository
- Finding malware collections on GitHub for testing.
Solid workflow. I'm still early in the game so this helps.
The compiler pattern tip is something I haven't dug into yet — I've been jumping straight into dynamic analysis and getting lost in obfuscated messes. Probably why I hit walls.
One thing I've been running into lately is finding open Redis servers that are already compromised. Been pulling malware samples from C2s and analyzing them, but most turn out to be the same crypto miners or botnet droppers. Good practice though.
Appreciate the resources. I'll check out MalwareBazaar and theZoo. Any specific packers you'd recommend focusing on first for a beginner?
(Jul 27, 2026 09:16 PM)KR0W Wrote: Solid workflow. I'm still early in the game so this helps.
The compiler pattern tip is something I haven't dug into yet — I've been jumping straight into dynamic analysis and getting lost in obfuscated messes. Probably why I hit walls.
One thing I've been running into lately is finding open Redis servers that are already compromised. Been pulling malware samples from C2s and analyzing them, but most turn out to be the same crypto miners or botnet droppers. Good practice though.
Appreciate the resources. I'll check out MalwareBazaar and theZoo. Any specific packers you'd recommend focusing on first for a beginner?
UPX is the most commonly used packer for malware and NSIS is more of an installer, but it is used fairly frequently.
My go to is always Detect It Easy and it will 99.1% of the time nail what packer is used unless it is a custom packer.
(Jul 27, 2026 10:08 PM)Tha Sneak Wrote: UPX is the most commonly used packer for malware and NSIS is more of an installer, but it is used fairly frequently.
My go to is always Detect It Easy and it will 99.1% of the time nail what packer is used unless it is a custom packer.
UPX it is — seems like the obvious starting point. I've been skipping straight to dynamic analysis and getting lost in obfuscated messes, so actually identifying the packer first makes way more sense.
(Jul 28, 2026 09:32 PM)KR0W Wrote: UPX it is — seems like the obvious starting point. I've been skipping straight to dynamic analysis and getting lost in obfuscated messes, so actually identifying the packer first makes way more sense.
Yes, I am planning on creating a massive series on this topic and I will link you when it is live. If you have any questions in the mean time let me know.
(Jul 28, 2026 09:35 PM)Tha Sneak Wrote: Yes, I am planning on creating a massive series on this topic and I will link you when it is live. If you have any questions in the mean time let me know.
Appreciate that. Looking forward to the series — drop the link when it's up.
Yeah I've been rawdogging dynamic analysis and wondering why I keep hitting walls. Packer identification first makes too much sense.
I'll hit you up if I get stuck on something. You're an absolute legend for this.
(Jul 27, 2026 08:39 PM)Tha Sneak Wrote: Once you get comfortable with the basics, one thing that helped me was focusing less on individual instructions and more on identifying the protections first.
My typical workflow is something like:
- Identify the file type (Detect It Easy (DIE), PEStudio, Exeinfo PE, TrID).
- Check for packing, virtualization, or obfuscation. DIE and PEStudio can often identify UPX, Themida, VMProtect, .NET, Delphi, Go, Rust, and many other compilers/packers.
- If it's managed code (.NET), I'll usually start with ILSpy since decompilation is often much faster than jumping straight into a debugger. For Java, typically you can open up the Jar file as an archive using 7Zip and you can decompile the class files in IntelliJ. If it's obfuscated then deobfuscation is obviously your next feat to overcome.
- If it is an AutoIt script my go to is Autoit-Ripper.
- If it's native code, I'll see whether it decompiles cleanly in Ghidra, IDA, or Binary Ninja before deciding whether dynamic analysis is necessary.
- If it's packed or heavily protected, I'll spend time unpacking or dumping memory before trying to reverse the actual payload. There's little value in analyzing thousands of junk instructions generated by a packer.
- Only after that do I move into dynamic analysis with x64dbg or an isolated VM to correlate the decompiled code with runtime behavior.
A few things that accelerated my learning were:
- Learning common compiler patterns (MSVC, GCC, Clang, Delphi, Go, Rust).
- Recognizing common packers, protectors, and obfuscators before opening the binary.
- Understanding Windows internals (PE format, PEB, TLS callbacks, imports/exports, SEH, API hashing).
- Comparing decompiler output with the original assembly to understand why the decompiler generated certain code.
For practice,some good resources include:
- MalwareBazaar (for research in an isolated environment)
- theZoo malware repository
- Finding malware collections on GitHub for testing.
Thank you, those are some HQ info
|
