midgard/zeus.ugent.be
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

Fixed weird sentence

Browse source
This commit is contained in:
David Vandorpe 2018-03-08 20:52:21 +01:00
parent 51fdf5f002
commit 09e8f3d656
No known key found for this signature in database
GPG key ID: 750319296238238A
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
content/blog/17-18/cscbe.md
View file

@ -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.