removed typos in ductf file magic

1 files changed, 21 insertions, 18 deletions

diff --git a/content/articles/2022-09-25-ductf-file-magic.md b/content/articles/2022-09-25-ductf-file-magic.md
index b0bc560..f4b55c9 100644
--- a/content/articles/2022-09-25-ductf-file-magic.md
+++ b/content/articles/2022-09-25-ductf-file-magic.md
@@ -1,7 +1,7 @@
 # DownUnderCTF 2022: File Magic
 
 A short writeup about my favorite challenge from DUCTF. It took me approximatly
-0.5 days to solve. I found it was the most creative and challenging one that i
+12h to solve. I found it was the most creative and challenging one that i
 solved.
 
 ## Task
@@ -48,26 +48,26 @@ print(stdout.decode())
 os.remove(f.name)
 ```
 
-So for a anything to make it past these check and be executed it must:
+So, for anything to make it past these checks and be executed it must:
 
-1. be a valid 13x37 JPEG image with the pixel at 7,7 set to #070707
+1. be a valid 13x37 JPEG image with the pixel at 7,7 set to `#070707`
 2. be a valid ELF binary that reads `./flag.txt` after decrypting with AES CBC,
    fixed key (`downunderctf2022`) and the provided IV
 3. The IV must contain `DUCTF`
 
-During the competition I discovered the information the next three headings in
-parallel but internally in-order.
+During the competition I discovered the information in the next three headings
+in parallel but internally in-order.
 
 ## 1. AES CBC "flaw"
 
 We need to generate a file that is a sort-of polyglot with JPEG and ELF,
-converted with AES CBC.
+converted with AES CBC (Cipher block chaining).
 
 AES itself operates on 16-byte (for 128-bit AES) blocks, so bigger files are
-split and then encrypted seperately. To ensure that identical blocks dont result
-in identical blocks in ciphertext, (when using CBC) each block is first xor'd
-with something that wont be identical, in this case, the last ciphertext block
-or the initialisation vector (IV). Here is a diagram for encryption
+split and then encrypted separately. To ensure that identical blocks don't
+result in identical blocks in ciphertext, each block is first xor'd with
+something that won't be identical. In the case of CBC, the last ciphertext block
+or the initialisation vector (IV) is used. Here is a diagram for encryption
 
 ```
   ___plaintext____|___plaintext____|___plaintext____|...
@@ -92,7 +92,7 @@ IV--->XOR   '---------->XOR   '--------->XOR   '---- ...
 ```
 
 This does make sense, however i noticed that all but the first block do not
-depend on IV. This turn out useful since we can turn any block into any other
+depend on IV. This turns out useful since we can turn any block into any other
 block by applying a chosen value with XOR. So we can control the ciphertext with
 the IV directly as follows:
 
@@ -127,7 +127,7 @@ data we want.
 ## 3. ELF Payload
 
 The binary needs to be super small so creating it "manually" was required. I
-followed a the guide
+followed the guide
 [Creating a minimal ELF-64 file by tchajed](https://github.com/tchajed/minimal-elf/)
 and recreated it for my needs. Like in the guide i also wrote the assembly with
 a rust EDSL.
@@ -164,14 +164,14 @@ representation for clarity, question marks `?` represent data that is implicitly
 defined):
 
 ```
-ciphertext: 7f 'E 'L 'F 02 01 01 00 00 00 00 00 00 00 00 00 
+plaintext:  7f 'E 'L 'F 02 01 01 00 00 00 00 00 00 00 00 00 
 iv:         ?? ?? ?? ?? ?? ?? 'D 'U 'C 'T 'F 00 00 00 00 00
-plaintext:  ff d8 ff fe {len} ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
+ciphertext: ff d8 ff fe {len} ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
 ```
 
 This scenario is a little more complicated because in some places we define
-cipertext and plaintext and in some we define ciphertext and IV. This is not a
-problem though, because XOR operates on every byte individually.
+ciphertext and plaintext and in some we define ciphertext and IV. This is not a
+problem because XOR operates on every byte individually.
 
 All-in-all, the file looks like this now:
 
@@ -183,9 +183,9 @@ All-in-all, the file looks like this now:
 - _end of the jpeg comment_
 - Rest of the JPEG image
 
-All this information should be enough to solve this challenge.
+All this information should be enough to solve this challenge!
 
-I also attach the implementation that i created _during_ the CTF here. I kept it
+I here attach the implementation that i created _during_ the CTF here. I kept it
 as messy as it was, just removed not-so-interesting code and added comments.
 
 ```rs
@@ -250,3 +250,6 @@ assert!(buf.len() < 1337);
 File::create("image").unwrap().write_all(&buf).unwrap();
 File::create("iv").unwrap().write_all(&iv).unwrap();
 ```
+
+I am also still looking for team mates for upcoming CTF events and would be
+happy to hack together with you! Just [contact](https://metamuffin.org/contact) me.