Fix all remaining typos (#30)

.github/wordlist.txt

@@ -544,4 +544,10 @@ yrp
 yrp's
 yYZrkNRmD
 zlib
-zodiacon
+zodiacon
+Reconstructor
+froc
+programmatically
+aelo
+insomnihack
+modularity

content/2013-06-20-I_feel_lucky.md

@@ -50,7 +50,7 @@ My exploit was in 4 parts:
         int fd = open("/sbin/ping", O_RDONLY);
         caddr_t addr = mmap(NULL, LEN, PROT_READ, MAP_SHARED, fd, 0);
 
-2. `fork` to passe to be the mmaped address to a process I can attach to using `ptrace()`
+2. `fork` to passe to be the `mmap`-ed address to a process I can attach to using `ptrace()`
 
 3. in the parent process, I attach to the child process and then prepare a basic payload to substitute the original code with
 
@@ -100,7 +100,7 @@ Done! Simply execute the target binary to get a root shell.
 ```
 
 By nature, this exploit is very stable and I was able to report that I had `root` access to my customer :)
-I was undeniably lucky to find exactly the privesc I need just exactly when I needed it (kudos to Konstantin Belousov & Alan Cox for the finding), but it also taught me that there can be a huge difference of postponing applying patches, even if for one day...
+I was undeniably lucky to find exactly the privilege escalation I need just exactly when I needed it (kudos to Konstantin Belousov & Alan Cox for the finding), but it also taught me that there can be a huge difference of postponing applying patches, even if for one day...
 
 Cheers mates!
 

content/2016-03-08-bkpctf-2016-complex-calc.md

@@ -59,7 +59,7 @@ deallocated:
       pointers of the list are updated using the `unlink` macro.
    1. If the size is higher than `MMAP_THRESHOLD`, then the chunk was not
       allocated via the `brk`/`sbrk` syscall, but mapped in memory via the
-      syscall `mmap`. If this heap chunk is mmaped, then its size will be a
+      syscall `mmap`. If this heap chunk is `mmap`-ed, then its size will be a
       multiple of 2 (i.e. size & 2 = 2).
 
 This actually shows quite well in the flow graph:
@@ -103,7 +103,7 @@ the following mapping:
 ```bash
 .bss:00000000006C4A88 add_result      dd ?                    ; <-- previous chunk size
 .bss:00000000006C4A8C                 align 10h
-.bss:00000000006C4A90 div_operator_1  dd ?                    ; <-- chunk size (need to | 2 for flag IS_MMAPED)
+.bss:00000000006C4A90 div_operator_1  dd ?                    ; <-- chunk size (need to | 2 for flag IS_`mmap`-ed)
 .bss:00000000006C4A94 div_operator_2  dd ?                    ; <--
 .bss:00000000006C4A98 div_result      dd ?                    ; <-- free will point @this chunk
 .bss:00000000006C4A9C                 align 10h

content/2016-03-14-0ctf-2016-warmup-write-up.md

@@ -112,7 +112,7 @@ send 5 bytes of junk data so that the syscall can return with the right value in
 `read` arguments, then jump into it and finally jump back to our next gadget ☹ .
 
 After quite some time, I realized that `warmup` starts by initializing an alarm
-for 10 seconds (which when SIGALARM is received, will kill the
+for 10 seconds (which when `SIGALRM` is received, will kill the
 program).
 ```bash
 .text:0804810D                 mov     eax, 27

content/2016-04-01-hitb-teaser-2016-bakery.md

@@ -100,7 +100,7 @@ inside the `mmap` buffer, which will then be jumped into and executed.
 ### Exploitation ###
 
 Getting the initial random integer can be done by reading from the socket until
-reahcing the string `0v3n w4rm3d up to` and divide this value by 0x1337.
+receiving the string `0v3n w4rm3d up to` and divide this value by 0x1337.
 ```python
     # get the init rand()
     parts = s.read_until("\n").split()
@@ -110,7 +110,7 @@ reahcing the string `0v3n w4rm3d up to` and divide this value by 0x1337.
     ok("Got rand=%d" % rand)
 ```
 
-To reliably control the content of the mmaped buffer, we need to "compensate"
+To reliably control the content of the `mmap`-ed buffer, we need to "compensate"
 the accumulation that the function is doing. Since we know the initial random
 integer, my approach was to use one of the valid ingredients (in this case
 `FLOUR`) which is required to pass the `strstr()` check, sum up the ascii values

content/2016-05-23-defcon-ctf-2016-feedme.md

@@ -98,7 +98,7 @@ Before continuing, I would recommend reading the paper & slides related to the
 
 Since the child process is being forked, we know that the parent and child are
 identical in every way, including the memory mapping and the canary token. So
-the idea for this exploitation is to bruteforce one-by-one all the bytes from the
+the idea for this exploitation is to brute-force one-by-one all the bytes from the
 canary variable in stack, with the following binary logic: overwrite one byte of
 the canary with a value, `X`. If we have a crash, it will mean that the canary is
 corrupted, and therefore `X` is not valid. If it does not crash, then `X` is
@@ -158,7 +158,7 @@ def leak_canary(s):
 ```
 
 
-We know control the execution flow without triggerring the `canary_fail()`
+We know control the execution flow without triggering the `canary_fail()`
 function. All we need to do is build the shellcode using regular ROP. Since the
 binary is statically compiled, we have more gadgets than we need.
 

content/2016-06-13-armpwn-challenge.md

@@ -217,7 +217,7 @@ Partial RelRO:                                    Yes
 Full RelRO:                                       Yes
 ```
 
-And on top of all those, ASLR is on. Given the target is 32 bits, bruteforce is a
+And on top of all those, ASLR is on. Given the target is 32 bits, brute-force is a
 realistic approach, although inelegant. One (or more) memory leak(s) can defeat
 PIC & ASLR, let's look for those first.
 
@@ -249,7 +249,7 @@ So we have `execve_addr = libc_base + 0x9bf80` and also `binsh_str = libc_base
 
 ### Leaking the canary ###
 
-Last thing we need to build a full exploit is a way to leak/bruteforce the
+Last thing we need to build a full exploit is a way to leak/brute-force the
 canary.
 
 In the pseudo-code earlier, we found that the `main` process was calling a
@@ -269,7 +269,7 @@ while (1){
 
 This gives us a perfect way to leak the canary:
 
- * try to bruteforce byte 0 of the canary, and then send another valid
+ * try to brute-force byte 0 of the canary, and then send another valid
      (dummy) HTTP request.
  * if the byte tested is incorrect (i.e. different from the canary), the
      process will die, closing the socket, that we can detect on our end by an
@@ -294,10 +294,10 @@ Canary is 0x6074e600
 Almost there! We have bypassed ASLR, PIC, NX and SSP. In x86, we would be just
 done. ARM however uses one register (saved on stack) to save the return address
 (called the Link Register) along with all the non-volatile registers that must
-be preserved accross functions calls.
+be preserved across functions calls.
 
 IDA shows that the `parse_request()` function finishes its execution by
-restoring the context of the calling fubnction:
+restoring the context of the calling function:
 ```
 .text:000016D0 loc_16D0
 .text:000016D0 ADD     SP, SP, #0xC
@@ -313,7 +313,7 @@ gadgets to pop the `/bin/sh` address directly into $r0. `gef` module `ropgadget`
 will work perfectly for this. Finding suitable gadgets is a little harder on ARM
 than x86 as you find hardly instructions to pop directly into your argument
 registers (for example `pop{r0}`, or `pop{r1}`) So you'll need to chain them
-adequatly, bearing in mind which registers will be affected the gadgets (for
+adequately, bearing in mind which registers will be affected the gadgets (for
 example `blx` will also affect the Link Register which may be indesirable).
 Building the ROP sequence for this binary is not hard, so I built a helper
 function:

content/2016-09-06-twctf-2016-reverse-box-writeup.md

@@ -53,7 +53,7 @@ the hash.
 
 Since I was feeling lazy and didn't want to reverse the whole thing, I decided to
 use my tool [`gef`](https://github.com/hugsy/gef.git) and
-its [Unicorn-Engine](http://unicorn-engine.org) command to bruteforce the
+its [Unicorn-Engine](http://unicorn-engine.org) command to brute-force the
 initial random integer. We can do so because we know that the flag has to start
 with `TWCTF{`.
 
@@ -70,7 +70,7 @@ gef➤  unicorn-emulate -f 0x80485b1 -t 0x80486e0 -e /tmp/revbox.py
 [+] Unicorn script generated as '/tmp/revbox.py'
 ```
 
-You can then easily update the script to make it bruteforce the correct value
+You can then easily update the script to make it brute-force the correct value
 for `eax` (i.e. the random integer), and let `unicorn` transform the buffer
 (located in the stack at 0xffffd26c - which we know thanks to GDB).
 

content/2017-01-26-insomni-hack-ctf-2017-bender-safe.md

@@ -1,11 +1,11 @@
 date: 2017-01-26 00:00:00
 modified: 2017-01-26 00:00:00
-title: Insomni'hack CTF 2017: bender_safer
+title: Insomni'Hack CTF 2017: bender_safer
 author: hugsy
 category: ctf
 tags: pwn,linux,insomnihack,mips,stack-overflow,rop,shellcode,keystone
 
-[Insomni'hack CTF 2017](https://web.archive.org/web/20170102081524/https://teaser.insomnihack.ch/) offered a series of 3
+[Insomni'Hack CTF 2017](https://web.archive.org/web/20170102081524/https://teaser.insomnihack.ch/) offered a series of 3
 challenges (i.e. 3 different flags) on the same binary, called `bender_safe`:
 
   * `bender_safe` was a Reversing challenge (50 pts) to [discover the correct
@@ -336,7 +336,7 @@ will leave this to the reader's curiosity  ☺
 
 I will just conclude this post by thanking
 the [Insomni'hack](https://insomnihack.ch) team for putting up together such fun
-and original challenges. And also, huge congratz to the few teams who scored this
+and original challenges. And also, huge congratulations 🥂 to the few teams who scored this
 challenge during the CTF.
 
 Hope you enjoyed this article, and see you next time for more challenges...

content/2017-06-25-qemu-images-to-play-with.md

@@ -21,7 +21,7 @@ category: misc
 
 A few weeks back, I came across  [@Fox0x01](https://twitter.com/Fox0x01){:target="_blank" class="fa fa-twitter"} [tutorial](https://azeria-labs.com/writing-arm-assembly-part-1/){:target="_blank"} to get started with learning debugging and exploitation techniques on ARM. If you haven't checked it out, make sure you add this on your to-read list.
 
-I have been initially developping [`gef`](https://github.com/hugsy/gef.git) for the same reason, to learn more about non-x86 architectures. So in the same spirit of openness that Azeria has shown, I am releasing a few Qemu virtual machines to start immediately playing with ARM, MIPS, PowerPC and AARCH64 architectures!
+I have been initially developing [`gef`](https://github.com/hugsy/gef.git) for the same reason, to learn more about non-x86 architectures. So in the same spirit of openness that Azeria has shown, I am releasing a few Qemu virtual machines to start immediately playing with ARM, MIPS, PowerPC and AARCH64 architectures!
 
 All you need is [Qemu](http://www.qemu.org). Then download the link to your image, and unzip the archive.
 
@@ -52,9 +52,9 @@ Already existing fantastic projects such as [Vagrant](https://app.vagrantup.com/
 
 The closest thing to what I wanted when I started exploring exotic architectures was [aurel32 (now Debian Quick Image Baker) Qemu pages](https://people.debian.org/~gio/dqib/), which provides great Qemu images. Unfortunately, they are using extremely old kernels and/or Linux distributions, making it too hard for a quick plug-n-play experience.
 
-Interestingly when developing `gef`, I talked with many people interested in learning about non-x86 archs but felt like they _don't know where to start_. So my hope is that those images will be the start to a lot of fun.
+Interestingly when developing `gef`, I talked with many people interested in learning about non-x86 architectures but felt like they _don't know where to start_. So my hope is that those images will be the start to a lot of fun.
 
-All the VMs come with 2 compiled ELF binaires: a very simple `hello-world` to start easy with the new architecture, run it, start `gdb`-ing around it to understand the architecture basics (memory layout, function call convention, GOT+PLT, stack canary, etc.) and a `simple-bof`, which is a simple Stack Overflow ELF to start on the way of understanding memory corruption.
+All the VMs come with 2 compiled ELF binaries: a very simple `hello-world` to start easy with the new architecture, run it, start `gdb`-ing around it to understand the architecture basics (memory layout, function call convention, GOT+PLT, stack canary, etc.) and a `simple-bof`, which is a simple Stack Overflow ELF to start on the way of understanding memory corruption.
 
 
 ## But I just wanna play with assembly...

content/2017-07-14-building-a-debian-stretch-qemu-image-for-mipsel.md

@@ -80,7 +80,7 @@ Let the installer do its magic.
 
 ![3.debian.partition.png](https://i.imgur.com/Lg6Db5x.png)
 
-Since it's a VM for test and lab stuff, the guided partitionning is more than
+Since it's a VM for test and lab stuff, the guided partitioning is more than
 enough (and select `All files in one partition`). Feel free to tweak that part.
 
 ![2.debian.installation.png](https://i.imgur.com/iv31UxH.png)
@@ -236,7 +236,7 @@ The adequate files were downloaded from
   */
 ```
 
-  - For simplicity, I highly recommand to only use the official repo (from
+  - For simplicity, I highly recommend to only use the official repo (from
     `deb.debian.org` or `mirrors.kernel.org`). It might be a bit slower than
     your local mirror, but mirrors do not always mirror **all** the
     architectures generated by Debian maintainers.
@@ -247,7 +247,7 @@ The adequate files were downloaded from
 That's how you get started with making your own QEMU images. Debian, as the real
 hacker distro it is, is usually the one that works best for trying weird
 combination, and MIPS CPUs are very well supported. More posts will come on
-building other QEMU images for other ABI, which are not necesarily that easy to
+building other QEMU images for other ABI, which are not necessarily that easy to
 setup.
 
 I hope you now have all the information to make your own QEMU images.

content/2017-08-01-gef-at-black-hat-arsenal-us-2017.md

@@ -2,7 +2,7 @@ date: 2017-08-01 00:00:00
 modified: 2017-08-01 00:00:00
 title: GEF at Black Hat Arsenal US 2017
 author: hugsy
-tags: gef,blackhat,bharsenal
+tags: gef,blackhat,arsenal
 cover: assets/images/gef-bh-usa-bg.png
 category: talk
 

content/2017-08-07-setting-up-a-windows-vm-lab-for-kernel-debugging.md

@@ -28,7 +28,7 @@ isn't an option. So my setup is:
     1. Windows 7 x86 VM (using UART as debugging medium)
     2. Windows 8.1 x64 VM (using Network as debugging medium)
 
-As a comodity, I've created a
+As a commodity, I've created a
 [`Vagrantfile`](https://github.com/hugsy/modern.ie-vagrant) to simplify the VM
 creation process using [`Vagrant`](https://vagrantup.com). You can create a new
 Windows VM like this
@@ -107,11 +107,11 @@ C:\> bcdedit /debug {UUID-RETURNED-BY-FORMER-COMMAND} on
 ![image_alt](/assets/images/win-kernel-debug/win7-bcdedit-enable-debug.png)
 
 Now instruct Windows serial communication as debugging medium, and use the
-"fastest" baudrate (i.e 115200 symbols/sec). Since we'll only use serial
+"fastest" baud rate (i.e 115200 symbols/sec). Since we'll only use serial
 debugging for this VM, we can use the `bcdedit /dbgsettings` global switch.
 
 ```
-C:\> bcdedit /dbgsettings serial debugport:1 baudrate:115200
+C:\> bcdedit /dbgsettings serial debugport:1 baud rate:115200
 ```
 
 *Note*: if we wanted to set debug settings specific to one entry of the boot

content/2017-08-14-a-primer-to-windows-x64-shellcoding.md

@@ -39,7 +39,7 @@ PROCESS ffffe000baa6c040
    Image: System
 ```
 
-This leaks the address of the `_EPROCESS` structure in the kernel, of the proces
+This leaks the address of the `_EPROCESS` structure in the kernel, of the process
 named `System`. Using `dt` will provide a lot more info (here, massively
 truncated to what interests us):
 

content/2017-08-18-first-exploit-in-windows-kernel-hevd.md

@@ -248,7 +248,7 @@ hold
 to know the state of the stack after the overflow but before exiting the function, it'd
 be nice to have WinDbg break at the `ret` instruction of
 `TriggerStackOverflow`. Since ASLR is enabled, we can't just break at a fixed
-address and having to compute the address would be tidious, but fortunately,
+address and having to compute the address would be tedious, but fortunately,
 WinDbg, in its all awesomeness,
 provides the command
 _Break Unresolved_) which provides a clean way to circumvent this issue:

content/2017-08-31-arbitrary-write-primitive-in-windows-kernel-hevd.md

@@ -228,7 +228,7 @@ Now we've got the `ImageBase` component.
 
 This step is actually much easier. All we need to do is to :
 
-  1. load the kernel image `ntoskrnl.exe` and store its base adress
+  1. load the kernel image `ntoskrnl.exe` and store its base address
   1. retrieve the address of `HalDispatchTable`
   1. subtract the two pointers found above