Small optimizations#44
Conversation
Modify logic to append values instead of overwriting in sorted_decoded_config.
|
any idea why tests are skipped? |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the configuration parsing and decryption logic, introducing optimizations for metadata lookups and support for multiple AES metadata candidates. Key changes include the extraction of decryption and remapping logic into dedicated methods, the use of bisect for faster method lookups in dotnetpe_payload.py, and a more robust string decryption process that tracks successful keys. Review feedback focuses on further optimizing method lookups by token, restoring type hints, and ensuring correct string formatting when appending list values during configuration remapping.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…yptor_aes_with_iv.py Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Added checks for metadata presence and improved error handling when accessing tables in dotnetpe.
|
from my tests on my side is nearly 50% faster now. please review when you can |
It's because this is coming from a forked repo - GitHub Actions does not expose repository secrets (like the samples ZIP password) to fork PRs, so the malware sample decryption step would fail anyway. That said, it will run once we pull it into the main repo and I can run it on my end locally! |
|
Love it! There are some small modifications I saw in review that I'd like to implement, but because this is on your fork, I can't write them onto this one, so I'm going to merge this, open up a new PR, and then feel free to pull in those changes at your leisure. Thank you as ever for the optimizations <3 |
PR #44 introduced a `successfully_decrypted_count == 0` guard at the end of `decrypt_encrypted_strings` that raises if no string was successfully decrypted. For template/builder samples (e.g. unconfigured AsyncRAT builds where every config value is a placeholder like `%Anti%`), every value fails the b64/length filter and is passed through unchanged without any decryption being attempted. The guard then raised, causing `_attempt_decryption` to discard the AES decryptor and fall through to the plaintext decryptor, which has no salt -- so `report["salt"]` was reported as "None" instead of the actual extracted salt. Track attempted decryptions separately and only raise when at least one string was actually attempted but every attempt failed. Template samples have zero attempts and now fall through cleanly with the AES decryptor intact, restoring the master behavior of reporting the salt. Verified against all 14 known sample expected outputs. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
@doomedraven There was a small regression I fixed in #45 - Feel free to pull that in to your fork, and let me know if you have any questions! |
|
thank you |
2 participants
No description provided.