Dear folks, How are you doing? I wanted to share with everyone the news that based on my most recent "When Data Mining Conti Leaks Leads to Actual Binaries and to a Hardcoded C2 With an Encryption Key on Tripod.com - Part Five" blog post - ddanchev.blogspot.com/2026/0… where I actually found several CWE flaws including a hardcoded decryption key in the actual encrypted file for a Conti Ransomware sample which I obtained from 2020 as I further continued pursuing my belief that this is the case with other related Conti Ransomware binaries today I came across to a second Conti Ransomware sample which is doing exactly the same namely storing the decryption key in the actual encrypted file where I'll soon summarize my findings and publish them. Also for the record in my previous "When Data Mining Conti Leaks Leads to Actual Binaries and to a Hardcoded C2 With an Encryption Key on Tripod.com" - ddanchev.blogspot.com/2026/0… blog post series I also came across to a relatively interesting wrapper function called "Asshole". “AssHole” wrapper purpose and mechanics Literal marker: "AssHole" at 0x405558. Alphabet used by transform: "0123456789abcdef" at 0x405544. And. Both send_data_to_c2 and recv_command_from_c2 incorporate "AssHole" directly into the transform pipeline: On send: the outgoing buffer is combined with "AssHole" and passed through encode_obfuscated_hex_string (0x4024a0). On receive: the received blob is combined with "AssHole" and passed through decode_obfuscated_hex_string (0x402620). I'll continue pursuing my belief that this hardcoded decryption key mentality might be the case with other related Conti Ransomware samples and I'll soon publish my findings. The more malware samples the merrier. Special thanks to @vector35's BinaryNinja reverse engineering product and service of which I'm a proud user. Thanks, Dancho