I started analyzing the malware for a day, mostly using dynamic analyse tools. Normally the file that is downloaded is around 100kb but after unpacking itself, it is around 30kb. We need to put hardware breakpoint at 0x401ae0 to be able to dynamically debug program. (Note: I also put software breakpoint but after breakpoint hit, I removed it for further analysing).
Also I dumped process to ghidra, so I can do static analysis too. If you check memory in x32dbg or SystemInformer, everything can be Read/Written/Executed. That's why it can rewrite itself.
NOTE: The reason, we must not use software breakpoint is, it modifies malware's code by adding CC at start of the assembly code, unpacking the code will cause issues.
Later analyzing the code, I realized some parts of the executable is still encoded, I let malware execute itself till 0x401BCD so it can decode these parts, then dumped. Which later, I realized it didn't really decode and check ghidra again for any tips. There it is, code is actually decoding -> executing -> encoding itself. (Polymorphic) Which is why I couldn't do static analyzes:
What I will actually do is, again execute code but now, I will stop at when the part is executed so I can copy and paste it into my dumped exe file. For example, 0x40410a etc.
Alright so, I changed bytes of the parts we need for further analyzing. the first function at 0x40410a is putting functions' address from dlls to uninitialized DATAs:
(it is longer)
It will not be really hard to rename DATAs in ghidra to function names for static analysis. Which is what I am going to do next.
After Renaming variables, it is a lot more easier to do static analysing but there are still some functions that use decoder() function in itself. That means I have to also rewrite their bytes.
Okay so as I progress, I try as much as I can to do static analysis and understand each function, I did few discoveries and 1 of the important ones is:
As I renamed, it checks for file name and returns accordingly, in our case as I run it first time with random name, it will return 0x10 but there are other possibilities too, which I might check if needed. That's the exact way malware searches for file names:
Which is not that hard to understand.
Sadly, while analysing this malware, I had to take break for a while (final exams in university) so I couldn't focus on the malware. But I can say, I did important parts like decoding some parts, to explain what the dropper part does is, (not really dropper because malware itself is actually as a whole doing everything) just delete WinSrv32 file and terminate any process with this name, write itself (or a part of itself), I couldn't analyse these parts as I dont have a lot of time. then start executing itself from there. I will provide smokeloader ghidra zip, because I believe it is not something to drop in trash, maybe 1 day I might come back and look into this and finish the job. I dont really know. (ghidra zip is in same folder as this file). (also provided dd32 file to know where the breakpoint has to be).