So I’ve taught assembly at a local university (simple for loops, function calls, etc.), and I’ve taken reverse engineering courses with IDA , but the classroom experience is way different than looking at real world malware samples! In general I have some success with simple malware but if it’s packed or has good anti-debugging techniques I currently still feel like I struggle too much. For example, I was trying to utilize x64dbg (32 bit one) to review this sample today (md5 51366279c4cc36b32640975a7b8883fb , https://www.reverse.it/sample/3b7e956d97f0811e65e1756e06e21e8beb88670742d04a855c186db03b022a98?environmentId=100 )
I start x64dbg and get to the entry point, when I start going along line by line and taking notes, I see things such as it touching the SEH table (fs) , it referencing RaiseException and RtlUnwind, reading the keyboard type (GetKeyboardType), etc. I’ve read about malware using the SEH table to kinda hide or obfuscate code execution so perhaps that’s what’s going on?
I see it making a decision based on the Keyboard type of what it should do next, which may include RegOpenKeyEXA for software\borland\delphi\rtl depending on the keyboard type. Then it gets the current threat (GetCurrentThreatId) plus some other info about the program (like it’s path with GetcommandLineA). But not really sure exactly why it’s doing any of that.
Then I kinda lose focus maybe, or I get confused, not sure … but I can’t really follow what it’s doing next. Eventually it seems to always die with some error like “Last chance exception, EXCEPTION_ACCESS_VIOLATION” which I’m not sure I totally understand what that means?
I apologize for the long winded open-ended question, but basically what should I be looking for or maybe you know of a better approach I should be taking to tackling disassembling a piece of malware like this? I feel like I simply don’t have enough experience yet and I don’t really have anybody on my team that has assembly experience besides myself so I can’t ask anybody for help.
Thanks in advance. Any feedback is appreciated.
Being overwhelmed from in the wild malware is quite normal in your situation. It takes time to build the experience to know what is going on. Even then, after years, you will still feel overwhelmed with certain samples. It is a feeling you will have to get used to. Just don’t let this creep into your mind as a flaw of yourself. It is not you. It is just the complex nature of our field.
Before you continue working with this sample, you might want to get into the topic of process injection. Read about the most common methods, how they work, how you can recognize them, how you can extract the injected code or PE image.
In general I would try to get an overview to the sample’s behaviour and thus possible points to tackle it before attempting to debug or disassemble. Sometimes this approach saves a lot of time. If you look into your reverse.it link, you will see that this sample does process injection and there are several ways to extract the code without having to debug the instructions step by step. This may also enable you to work around certain anti-reversing features as you may not have to deal with them at all.
There are 3 parts in the reverse.it report that will tell you about process injection:
- The processes. You see here the process executing itself again as child process. This is often a sign that the sample is packed and injects the unpacked code into its own process.
- The system tells you it suspects process injection in the overview. It tells you it might use process hollowing. Look it up if you haven’t heard of it before, it is a very common technique, if not the most common. Another term is “RunPE”.
- If you click on the process you see the API listing. Look for process injection typical API here. In this case it is the NtWriteVirtualMemory calls with the child process as target:
I made an overview for typical process injection APIs here:
I haven’t looked into this sample yet regarding the anti-debugging it uses. Maybe I will later. But maybe it is something you don’t have to care about here (there are always several ways to achieve your goal).
In general it makes sense to look into Peter Ferrie’s Anti-Reversing reference and the anti-unpacker tricks articles on VB, so that you are able to recognize various of these techniques in samples.
I also have Youtube playlists for process injection and anti-reversing stuff. Not that many videos yet, but I will create more eventually. I am sorry for the bad quality of the earliest videos. But maybe they help:
Lastly, I think your current approach, which is asking for help after seriously trying to solve this problem on your own, is a very good one. I would just do the same.
Awesome , your detailed feedback is greatly appreciated. I will dig deeer into what you’ve shared. Thank you
@neonprimetime haha welcome to malware analysis my friend.
I think a specific video will help you here… It won’t necessarily help you with this specific sample but it will help you on how to organize your thoughts when attacking malware. That video is here:
In fact, he uses a resource provided to you by @Struppigel . Basically, doing this manually is a slow process of looking up all of the possible anti-analysis tricks and placing breakpoints on them and defeating them like he says. it will be slow and painful at first and eventually you can start to use the plugins to do this stuff faster and develop your own methods.
I highly recommend you watch this video because it is a real-world example and the processes Segei uses to tackle the problem are import to see in action. Let me know if it helped.
@struppigel your videos have been incredibly helpful ! I feel like I’ve made more progress this week than I have in the past few months. Thank you
@moveax41h thank you. I enjoy the idea behind your website , Thanks for creating it and for providing a forum for learning
Awesome, glad you like this site! I plan to support it for as long as I can. Thanks for comin and I hope you find it resourceful and also are able to help others!