I am writing a tool for unreal pak, but I encountered a decryption problem. <p dir

decryption algorithm? about repak HOT 1 CLOSED

Chuanhsing commented on June 15, 2024

decryption algorithm?

from repak.

Comments (1)

trumank commented on June 15, 2024

AES always operates on blocks of 16 bytes so inputs must be padded if they don't land on a block boundary. OpenSSL has some clever tricks to do this automatically without having to store the unpadded length externally, but it can be disabled with -nopad to operate on raw blocks. I'm not sure where 6c cc cd c8 60 8c 80 or 6c cc cd c8 60 8c 80 ef 69 8c 99 e4 a4 9a d5 ad came from as I get neither of those from encrypting foo-bar with the given key.

I can verify bbe8d48c0f5b9aca2e460ed3253a67e3 does decrypt to foo-bar (plus padding) however:

# decrypting
echo 'bbe8d48c0f5b9aca2e460ed3253a67e3' | xxd -r -p | openssl enc -d -nopad -aes-256-ecb -K $(echo 'aWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWk=' | base64 -d | xxd -p -c 0) | xxd
# 00000000: 666f 6f2d 6261 7209 0909 0909 0909 0909  foo-bar.........
# NOTE the trailing 09s: these are special bytes telling OpenSSL to remove the last 9 bytes because they are padding
# they only appear in the output because -nopad is specified

# encrypting
echo -n 'foo-bar' | openssl enc -nopad -aes-256-ecb -K $(echo 'aWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWk=' | base64 -d | xxd -p -c 0) | xxd
# 00000000: bbe8 d48c 0f5b 9aca 2e46 0ed3 253a 67e3  .....[...F..%:g.