Description
I designed this in such a way that it should only be possible to get the key at runtime. Static analysis is purposefully very difficult, not through obfuscation, but through some other **interesting** methods. You are welcome to stab at it with static, but just know that there's quite a few decoys if you do go that route. Good luck!
You must be logged in to post a comment
trendcrusher on 9:43 AM 09/10/2025: 27/72 security vendors flagged this file as malicious
trendcrusher on 9:46 AM 09/10/2025: It's not certain that there is anything, but just in case) Need to check carefully.
BitShifted on 5:25 PM 09/10/2025: @trendcrusher, yes indeed. Theres a reason it passed review though. It doesn't do anything harmful, if you just threw it into VT, check out the behavior: No network requests, no disk writes, nothing like that. Its just because of the way I packed it, and the runtime encryption.
dsfsdfsdfsd on 7:25 PM 09/10/2025: painful challenge, too many steps to write a writeup so just posting the password Shadow42!, good job mate
dsfsdfsdfsd on 7:30 PM 09/10/2025: must took a great effort to write the PIC loader, noice
BitShifted on 8:43 PM 09/10/2025: @dsfsdfsdfsd, nice job man! The loader wasnt bad, but I have to ask if it did its job: were you able to dump the PE from memory, or did you have to dump PIC and reassemble it? Also, did the challenge succeed in making you debug/dynamically work with the file, or were you able to do it mostly statically?
dsfsdfsdfsd on 10:51 PM 09/10/2025: soo, started with debugging it, BUT with the suspended cmd process thing u did, I had to attach the newly created process to the debugger every time I needed to reloaded the exe for setting the BPs so it was a no go (because each time it was a new Process the BPs were gone).Then decided to extract the whole shellcode and wrote a simple shellcode executioner to debug it. Last step was to extract the final exe from memory to analyse it.The last step could have been for sure "only runtime" but I think extracting the exe and analyse it static was easier.For the first part, analysing it only in memory would take ages.There are still suspended cmd process xD
dsfsdfsdfsd on 10:53 PM 09/10/2025: Overall yes I think the challenge did each job "mostly debbugging" because the shellcode on each own was quite complex so I literally went step-by-step on it.
dsfsdfsdfsd on 10:58 PM 09/10/2025: One last thing I have to ask, the loader was PIC C/C++ code with custom gcc/vc options or handwritten asm? the push rcx {i think it was rcx} pop rcx to get the encrypted data's address was nice
BitShifted on 11:13 PM 09/10/2025: @dsfsdfsdfsd I leaned on some existing tooling for the part of the loader that encrypted/decrypted the actual payload, along with resolving the imports, before executing it in memory I modified it a bit to try to make it harder to dump from, and also the way it handled the RWX section it maps into. But its is all in C/C++
dsfsdfsdfsd on 12:18 AM 09/11/2025: nice, I think it was as "runtime" as it is possible