3

I'm currently investigating a piece of software which encrypts it's files with AES-128-CBC.

From disassembly it is truly known that the algorithm used is correct (log messages plus calls to the BCrypt library).

The key and IV are static and stored within the executable as a blob of 96 bytes, which is split using a set of XOR loops into 2 blobs of 16 bytes — one for the key, and one for the IV.

I have been able to reproduce the same algorithm and acquire both the key and the IV.

However, when I try to use the acquired data to decrypt the file, either using tiny-aes or the OpenSSL command line tool, I get a piece of the correct decrypted header for the file, containing human-readable text at that, but further just a bunch of zero bytes, and then seemingly the original encrypted data again.

Reading up about CBC on Wikipedia leads to the fact that:

Decrypting with the incorrect IV causes the first block of plaintext to be corrupt but subsequent plaintext blocks will be correct.

However, this seems to be the exactly inverse in my case. Moreover, even if I set the IV to all zeros during decryption, I still get the header, but not the further data.

Am I missing a critical point in how to apply the algorithm properly? Or may it be that the implementation in Windows BCrypt differs from tinyAES and OpenSSL on Linux?

Improve this question
2
  • It might be useful to take a look at this question. Can't say without looking at your code but it seems likely you're having a similar problem with overwritten IV data.
    – AlphaD
    Commented Apr 18, 2019 at 3:37
  • @AlphaD Thanks for your reply. The problem is that the response is exactly the same with the openssl command line tool (from the package openssl-utils).
    – akasaka
    Commented Apr 18, 2019 at 3:53

1 Answer 1

Reset to default
3

If you are seeing a partially correct result it is likely an IV problem:

In CBC the IV is XOR'ed to the plaintext after encrypt/decrypt. This means that if you've got the IV completely wrong then your decrypted message will have incorrect data of the first block (in CBC 16 bytes) as that is the length of the IV. This is in line with the quoted wiki.

However there is also the case where your IV is partially right (say the first n < 16 bytes are correct) then you will see the correct first n bytes in the decrypted file and the remaining (16-n) bytes incorrectly. This means that even if you try an IV of all zeroes you might still get the first n characters correct.

I can't say why your IV is incorrect but I would check the value there first.

Improve this answer
4
  • Or I am missing something on a level above that, as I've just tried decoding a different component of the software using the same code I used and not only it decodes perfectly but also passes the checks further applied by the software on decrypted files. Thanks for your help!
    – akasaka
    Commented Apr 18, 2019 at 7:10
  • @VladislavKorotnev Good to know you got it working. It can be a pain trying to debug crypto
    – AlphaD
    Commented Apr 18, 2019 at 7:14
  • Especially when you don't have much idea on what data to expect on the output :D
    – akasaka
    Commented Apr 18, 2019 at 7:21
  • If anybody is lurking and wondering what it was, the file turned out to be just 2 parts joined together, first part encrypted with the key I found, second encrypted with key I found later. Just had to split it and decrypt them separately.
    – akasaka
    Commented May 15, 2019 at 3:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .