Minor grammatical fixes

Author: msm-code

2018-09-13_scs-ctf/binary_re/README.md

@@ -42,14 +42,14 @@ This looks like an oversight of the author - decrypted password probably shouldn
 
 The tasks became even weirder from now on. The binary asked us a riddle [(terrible translation by Google Translate for curious)](https://translate.google.com/#auto/en/Od%20pi%C3%B3rka%20jestem%20l%C5%BCejszy%2C%20ale%20powstrzyma%C4%87%20na%20d%C5%82ugo%20nie%20zdo%C5%82a%20mnie%20najsilniejszy.%20Czym%20jestem%3F). We could just guess the solution or find it on the Internet, but reversing the binary turned out to be even easier.
 
-All the answers are in the binary in plain text, and are compared with input using standard string comparsion. There are two problems though:
+All the answers are in the binary in plain text and are compared with input using standard string comparison. There are two problems though:
 
 - Strings are obfuscated. Not intentionally - but Polish characters confuse IDA and GNU strings and not all the answers were immediately visible.
 - The binary is written in C++ and compiled without optimization.
 
 ![](comparsion.png)
 
-But it's nothing that we can't deal with in a few minutes. Strings are initialized globaly, so first we had to find the static initialization routine in the codebase (easy with find-xref function in IDA. One could also search for the name  `__static_initialization_and_destruction`, because symbols were not stripped).
+But it's nothing that we can't deal with in a few minutes. Strings are initialized globally, so first, we had to find the static initialization routine in the codebase (easy with find-xref function in IDA. One could also search for the name  `__static_initialization_and_destruction`, because symbols were not stripped).
 
 All the answers can be easily found by looking at that function in disassembly:
 

2018-09-13_scs-ctf/crypto_rot/README.md

@@ -8,7 +8,7 @@ Another ciphertext-only challenge. This time, ciphertext is even shorter:
 
 We immediately can infer *something* about the encryption, because we know that `scsctf_2017{` encrypts to ```5?5?6B0a_`gL```. The same input characters encode to the same output characters, so this is a substitution cipher.
 
-The chalenge title and description suggested `rot` operation. Alas, there are no obvious patterns in:
+The challenge title and description suggested `rot` operation. Alas, there are no obvious patterns in:
 
 ```python
 mapping = {
@@ -52,8 +52,8 @@ c 36
 Now, as I've said, we hate guessing. So we decided to approach this problem
 methodically, instead of getting into the task author's head.
 
-One of my teammates noticed that there are only few possible differences for
-ascii values. So he tried subtracting `[36, 47, -47, 62]` from every ciphertext
+One of my teammates noticed that there are only a few possible differences for
+ASCII values. So he tried subtracting `[36, 47, -47, 62]` from every ciphertext
 character, and written down all printable results at every position:
 
 ```

2018-09-13_scs-ctf/crypto_xor/README.md

@@ -8,9 +8,9 @@ UxYSRSg6YzQ8KkNGUDQKdl8fRQNMAxhVcRNdRBgLEx8MHRI2XFcRTBMEClIWAhA1PTcucyNWVUEy
 DCURDlkVV1E+SSMDTRddGwIXQxAPLFFfR10JBE4PUzMKJTExI3MTUkNUMBZ2fBVDBkoC
 ```
 
-I dislike ciphertext-only challenges, because to solve them you need to guess the algorithm, and it's neither practical nor fun. Not to mention that basing the difficulty of your cipher on secretness of your algorithm is a [well-known antipattern in cryptography](https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle).
+I dislike ciphertext-only challenges because to solve them you need to guess the algorithm, and it's neither practical nor fun. Not to mention that basing the difficulty of your cipher on secretness of your algorithm is a [well-known antipattern in cryptography](https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle).
 
-After wasting way too much time on guessing, we discoverd the encryption algorithm. We know the beginning of the flag (flag format is `scsctf_2018{.......}`), and xoring it with the ciphertext:
+After wasting way too much time on guessing, we have discovered the encryption algorithm. We know the beginning of the flag (flag format is `scsctf_2018{.......}`), and xoring it with the ciphertext:
 
 ```python
 import string
@@ -25,7 +25,7 @@ print xor(data, 'scsctf_2018{')
 
 Yields `To demonstra` which looks like a beginning of an English sentence.
 
-If the data was xored with completely random sequence of bytes, the scheme would be [provably secure](https://en.wikipedia.org/wiki/One-time_pad). But we expect the flag to be shorter than the whole ciphertext, so this turns into a [repeated key xor](https://en.wikipedia.org/wiki/XOR_cipher), a well-known weak cipher.
+If the data was xored with a completely random sequence of bytes, the scheme would be [provably secure](https://en.wikipedia.org/wiki/One-time_pad). But we expect the flag to be shorter than the whole ciphertext, so this turns into a [repeated key xor](https://en.wikipedia.org/wiki/XOR_cipher), a well-known weak cipher.
 
 We brute-forced few key lengths to discover the proper one, and found it:
 

2018-09-13_scs-ctf/web_serialize/README.md

@@ -1,6 +1,6 @@
 # Serialize (Web)
 
-This challenge deserves highlighting, because it required absolutely no guessing.
+This challenge deserves highlighting because it required absolutely no guessing.
 
 We have to deal with the following PHP code:
 
@@ -68,12 +68,12 @@ class MagicCode {
 }
 ```
 
-In the last line of code (that I somehow didn't copy), the POST data sent by user is base64 decoded and unserialized.
+In the last line of code (that I somehow didn't copy), the POST data sent by the user is base64 decoded and unserialized.
 
 It's obvious what to do here: we need to craft a MagicCode object.
 The __destruct() method will be called by the runtime, and we will get a limited RCE on the server. In fact, it's enough to change `command` variable to `showFlag` to get "password" and `showSource` to get the flag.
 
-Crafting PHP serialized payloads is relatively easy, because the serialization format is human readable and not very complicated. I crafted the following by hand (although in retrospect, I should've just used the code provided and serialize() function):
+Crafting PHP serialized payloads is relatively easy because the serialization format is human readable and not very complicated. I crafted the following by hand (although in retrospect, I should've just used the code provided and serialize() function):
 
 ```python
 import requests