Typo fixes.

Author: Washi1337

challenges/crypto/mixitup/example-solution/README.md

@@ -6,3 +6,5 @@ mixitup
 **Flag:** `RTN{4dd_Str4b3rr13s_X0r_B4n4n4s}`
 
 The hint message mentions the word `eXclusively`, which is a reference to XOR. If we XOR the pixel data together of both images (and skip the first 54 bytes that make up the bmp header), we get an image of a smoothie with the flag.
+
+![output](output.bmp)

challenges/crypto/noncense/example-solution/README.md

@@ -1,6 +1,6 @@
 # Noncense
 
-**Points:** 800 (
+**Points:** 800 (798 after dynamic scoring)
 
 **Flag:** RTN{h0W_mUcH_m0r3_n0nS3ns3_d0_Y0u_w4Nt}
 

challenges/re/espresso/example-solution/README.md

@@ -44,6 +44,6 @@ public class Espresso {
 
 There is something wrong with this code. Passing on the hardcoded string as input does not result in the correct message. Furthermore, from normal analysis, it looks like any string except for the hardcoded string should work (notice the ! before the if statement in the main for loop).
 
-The evilness of this challenge comes from the fact that this challenge exploits the fact that the JVM caches instances of primitive values. In Java, you can represent bytes either by using the primitive `byte` type, or using the `java.lang.Byte`class. Naturally, objects of classes are much more memory intensive than primitives. Therefore, to avoid a lot of duplicated `Byte` instances of the same value on the heap, the JVM maintains a cache of instances of `Byte`instead. The`Byte.valueOf(byte)`method uses this cache rather than creating new instances every time. If you manage to change the internal values stored in these `Byte` object instances, a call such as`Byte.valueOf(1)`might result in a`Byte`object that does not contain the value`1` at all. This is exactly what this binary does. This is exactly what the native loader does. Prior to actually calling this Java code, the native loader hacks into the JVM just before loading and running the embedded class file. `FUN_001016a4` and `FUN_00101478` patch the values of the cached`java/lang/Byte`and`java/lang/Boolean`, resulting in the fact that the compared values do not match with what is stored in the bytecode, effectively slightly changing the behaviour of the implemented verification code. These functions are somewhat hidden to the reverser, as strings in these functions are encrypted, and calls to the JVM interface are virtual, and therefore hidden behind a vtable instead of referenced by imports directories of the binary.
+The evilness of this challenge comes from the fact that this challenge exploits the fact that the JVM caches instances of primitive values. In Java, you can represent bytes either by using the primitive `byte` type, or using the `java.lang.Byte`class. Naturally, objects of classes are much more memory intensive than primitives. Therefore, to avoid a lot of duplicated `Byte` instances of the same value on the heap, the JVM maintains a cache of instances of `Byte`instead. The`Byte.valueOf(byte)`method uses this cache rather than creating new instances every time. If you manage to change the internal values stored in these `Byte` object instances, a call such as`Byte.valueOf(1)`might result in a`Byte`object that does not contain the value`1` at all. This is exactly what the native loader does. Prior to actually calling this Java code, the native loader hacks into the JVM just before loading and running the embedded class file. `FUN_001016a4` and `FUN_00101478` patch the values of the cached`java/lang/Byte`and`java/lang/Boolean`, resulting in the fact that the compared values do not match with what is stored in the bytecode, effectively slightly changing the behaviour of the implemented verification code. These functions are somewhat hidden to the reverser, as strings in these functions are encrypted, and calls to the JVM interface are virtual, and therefore hidden behind a vtable instead of referenced by imports directories of the binary.
 
 A simple python script can be made to reverse the substitutions that are made (example can be found in `make.py`)