🥲 my whole knowledge of low level coding, decrypting, decompiling and shellcode injection
first clone the repo then install the followings (refer to https://docs.cossacklabs.com/themis/installation/installation-from-packages/ if you don't want to build themis from source):
wget http://archive.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1_1.1.1f-1ubuntu2_amd64.deb
sudo dpkg -i libssl1.1_1.1.1f-1ubuntu2_amd64.deb
sudo apt update -y && sudo apt upgrade && sudo apt install -y libpq-dev pkg-config build-essential libudev-dev libssl-dev librust-openssl-dev
git clone https://github.com/cossacklabs/themis.git
cd themis
make
sudo make install
# install themis on MacOS M1
brew install libthemis
cargo run --bin thecry
compile the onion exploit into the linux
or windows
executable
extract the shellcode from the executable into shellcode.bin
using objdump -d ./onion | grep -Po '\s\K[a-f0-9]{2}(?=\s)' | perl -pe 's/\r?\n//' | sed 's/$/\n/' > shellcode.bin
command
inject the shellcode into the memory by invoking the inject()
method.
sha384
will be used to hash the password or the cipher key in which the first 32 bytes is the key and the rest 16 bytes can be used as the IV
.sha384
or pbkdf2
) can be used to encrypt and decrypt data.IV
since this cipher block chaining process.PKCS#7 is a standard for padding messages to a block size suitable for encryption. The padding works by appending
N
bytes of value N
to the message, where N
is the number of bytes required to reach the block size. In the context of AES, which has a 16-byte block size:
X
bytes where X < 16
, we append 16 - X
bytes to the message or the plaintext of the value 16 - X
.0x10
.For the padding to be valid, the last N
bytes of the decrypted plaintext must be a sequence from 1 to N
, each of value N
. For example, the last two bytes could be 0x02, 0x02
or the last three bytes could be 0x03, 0x03, 0x03
.
To verify whether you've used the correct key for decryption, you decrypt the last block of the ciphertext using that key and the ciphertext from the second-to-last block as the IV
(Initialization Vector). If the decryption is successful and the plaintext contains valid PKCS#7 padding, then the key is most likely correct.
more on Padding Oracle Attack
In our sec.json
file example, we would select two cipher blocks inside the json file using a hex editor, like 5307f7afffa3798f386e7c6c144c6a9c
and its next block like 3b2364d1d04a35c8081bbc6fdeacbd86
to decrypt the second one using the second-to-last block as the IV
which 5307f7afffa3798f386e7c6c144c6a9c
. If the resulting plaintext block has a valid PKCS#7 padding, then the key is correct. This check works because if the wrong key or IV is used for decryption, the resulting plaintext is highly unlikely to have valid PKCS#7 padding.
if we have an encrypted file contains the cipher blocks (assuming that these are simply AES-256-CBC encrypted blocks), then the decryption process would generally involve reading those blocks from the file, then decrypting each block, in our case the output hex inside sec.json
is formatted with 16 bytes in each row cause AES requires blocks of 16 bytes in length (16 bytes plaintext --> 16 bytes cipher block), so that each row of 16 bytes represents one block of ciphertext (hex string) in AES-256 and if we decrypt a cipher block that will give us a correct padding we can say that we used the correct key.