From 09e8f3d656439b0b275af2589d4a3cf22bbf463c Mon Sep 17 00:00:00 2001 From: David Vandorpe Date: Thu, 8 Mar 2018 20:52:21 +0100 Subject: [PATCH] Fixed weird sentence --- content/blog/17-18/cscbe.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/17-18/cscbe.md b/content/blog/17-18/cscbe.md index 6024981..993e292 100644 --- a/content/blog/17-18/cscbe.md +++ b/content/blog/17-18/cscbe.md @@ -53,7 +53,7 @@ We found a [writeup](https://github.com/Alpackers/CTF-Writeups/tree/master/2016/ Setting the encryption key to NULL on the server seemed easy enough, but sadly this would also mean that the server couldn't decrypt the messages from the client (as this key was used for both encryption and decryption by both sides). -To understand the next step, let's see how the plaintext is formatted. It consists of some header bytes (including IV and HMAC sign) followed by data. The data is the only part that gets encrypted if encryption is used. This data is essentially an array of different data blocks. The first two bytes of each block are the "TlvType" (an enum in `packets.h`) and the length of the data block (excluding these two bytes). The rest of the bytes are then followed by the actual data. It is also essential to understand that AES+OFB generates a bytestream which only depends on the IV and the encryption key. This stream does then get XOR'd with the plaintext. Changing a byte in the plain/ciphertext only changes the corresponding byte in the cipher/plaintext. If we know a byte P from the plaintext, it is easy to substitute it with another byte P': simply change C to C'=C XOR P XOR P'. +To understand the next step, let's see how the plaintext is formatted. It consists of some header bytes (including IV and HMAC sign) followed by data. The data is the only part that gets encrypted if encryption is used. This data is essentially an array of different data blocks. The first two bytes of each block are the "TlvType" (an enum in `packets.h`) and the length of the data block (excluding these two bytes). The rest of block is the actual data. It is also essential to understand that AES+OFB generates a bytestream which only depends on the IV and the encryption key. This stream does then get XOR'd with the plaintext. Changing a byte in the plain/ciphertext only changes the corresponding byte in the cipher/plaintext. If we know a byte P from the plaintext, it is easy to substitute it with another byte P': simply change C to C'=C XOR P XOR P'. Let's dive back into the code. When trying to dump the flag through an error message (which never gets encrypted) on the client side, we stumbled across some interesting code.