| @trendcrusher, glad you had fun doing it man, not many people seem to want to do java crackmes... You should make a writeup if you want to, id love to see your reimplementation of the VM |
==> |
| Got it. So you basically reversed it far enough to find the final hashing algo, then bruteforced that. Fair enough man, good job! Did the VM semantics trip you up at all? I put a lot of work into making them misleading. |
==> |
| @trendcrusher, damn dude! both this and my python one you found a key that wasn't the intended one. What is your methodology? Are you just brute forcing these? I don't see another way you would derive that key... |
==> |
| i found the issue. i will reup a fixed version later today. |
==> |
| @trendcrusher, this is not the intended key, and i have no idea how it evaluates to correct lmao but its cool you found that |
==> |
| @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, 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? |
==> |
| @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. |
==> |