Cr1pt0r Ransomware Analysis Libsodium/NaCl Encryption, Decryption, paramenters and (sad) conclusions

Hi Everybody,
After my two posts here and here  this is the third about Cr1pt0r.

Cr1pt0r main function decompiled by using RecDec plugin (graph view representation is huge to be seen in a picture):

Usage: ./cr1pt0r /mountPointToEncryptOrDecrypt
The ELF looks for a keyfile, in this order:
1 looks for a "privkey" file
2 looks for the "pubkey" file.
No matter if privkey is present, if the public key file is found, the ransomware starts to encrypt, if privatekey only is present, the ransomware decrypts the files.
In all the cases to walk trought the directories the included nftw function is invoked.

Defined parameters (still digging on them):
-g --> read the keyfile as bin2hex(bytes)
-k --> bin2hex + seed; probably generates a keypair?! - Don't know yet.
-e --> force encryption
-d --> force decryption
-t --> test? crypto has_sha512 final maybe does not overwrite the file? - Don't know yet.
/mountpoint --> the directory to be encrypted by the .sh start script is defined to be /mnt

Another thing I have to look at is why encrypted files , "_Cr1pt0r_" signature a part, are longer than the original ones. Also @demonslay335 has noticied the same. Could it be the answare?

 From PyNaCl documentation:

A note:
arm assembly SVC -> "SVC (formerly SWI) that generates a supervisor call. Supervisor calls are normally used to request privileged operations or access to system resources from an operating system." From ARM documentation.
Some of syscalls has been identified manually, binding the ARM instructions to the EAX value. The x86 reference website https://syscalls.kernelgrok.com/ gave me the connection I needed to identify the exit functions and few others.

To avoid the deleted files recovery possibility the ransomware during encryption creates the sameNameFile+".tmp" where stores the encrypted stream, then replace the source file with the encrypted data overwriting the source file itself.
The encryption algo used appear be crypto_onetimeauth_poly1305.  

I'm embarassed. This was completly incorrect. I wrote that during late night, I apologize.😰

Thanks to Frank Denis.

Those calls to crypto_onetimeauth_poly1305 takes us to NaCl One-time authentication.
More info on one-time authentication (Poly1305): (PDF) Daniel J. Bernstein, "Cryptography in NaCl", 45pp.

(0x000160BC)

Python and PyNaCl library helped me to create a keypair based on the standard implementation of  the library itself.

import nacl.utils
from nacl.public import PrivateKey, Box
skbob = PrivateKey.generate()
pkbob = skbob.public_key

>>> publicbob.hex()
'3d3f78633ea6a799c4dcf2522d9021c51031de6ba3ebcf061cc5caf8f843c52f'
>>> privbob.hex()
'dba2d474c0b72b620ecdc87f43eaab2e2465009174dc03b422c848301f19dd78'

Using this key pairs, I tryied to encrypt and decrypt a folder of my VM and the result has been positive.

To bruteforce such kind of key nowdays is pratically impossible.
Mathematics don't know good and bad, it is a rigid discipline with rules and even if in this situation where we would like to break the rules for the good, we can't.
I hope someone may have in the future some brilliant ideas on how reduce the keyspace for example some specific bug on random generation on this specific device and kernel (/dev/random is connected to this crypto algo) or maybe NaCl's creator Daniel J. Bernstein can share with us some ideas.


If some of you have ideas, feel free to contact me on Twitter @solver_re
Cheers,
RE Solver