OBAKE Cryptanalysis: Code

Debug or Disassembly

In this attack, the actor research the code to discover where and how to change some critical step of the algorithm (or program), causing an undetected and predicted malfunction to achieve his goals. It may be related to leaking the user's key to a remote location or file, or to make the algorithm vulnerable by bypassing several rounds or critical steps (the encryption will be weak), or even changing large portions of code to perform (or not) a specific function.

Therefore, this attack is critical to learn about the target and see where the malicious artifact should work - it usually precedes a code injection attack.

• DISASSEMBLY: the OBAKE application is protected against this attack by a complete professional obfuscation of its code. In this way, the disassembly process is ineffective since our protection hides the actual code or sometimes replaces it with a fake one, as shown here, here, and here.

• DEBUG: we utilize some mechanisms to detect debugging tools that try to execute the application, immediately aborting their interaction. In addition, we utilize "virtual code" (code not related to any language or ASM) to protect sensitive procedures in various parts of the OBAKE application, causing some advanced debugging tools to be lost and aborting execution due to serious errors. This can be seen here and here.

This type of attack on the OBAKE application and the OBAKE-512 algorithm is mostly impractical.