Address challenge feedback from Discord

Author: zardus

challenges/computing-101/control-flow/callee-write/DESCRIPTION.md

@@ -72,7 +72,7 @@ Get it right, and your `solve` will print your flag for you!
 **Hint:** Keep in mind that `write()` takes arguments in the order of: file descriptor (1 in `rdi` for stdout), buffer (pointer to memory, in `rsi`), and size (in `rdx`).
 This is _different_ from the arguments your function will be called with, so you'll need to move some stuff around!
 
-**Debugging your solution.**
+**DEBUGGING TIPS:**
 Since your code is a function inside a shared library, there's no entry point to launch under `gdb` directly --- but you can *give* it one.
 Add a tiny `_start` to your code that fakes the grader's call: point `rdi` at a stand-in buffer, set `rsi` to its length, and `call solve`.
 Now you can step through your logic in plain `gdb`, with no flag and no privileges needed:
@@ -101,12 +101,13 @@ If your `solve` is correct, this prints `AAAA` --- and the same logic will print
 
 You can also debug the native harness directly with stand-in bytes instead of the flag.
 `/challenge/check` is the Python checker script, so do not load it as the executable in `gdb`.
-The native program that loads your `.so` is `/challenge/harness`, and it reads the stand-in bytes from stdin:
+The native program that loads your `.so` is `/challenge/harness`, and it reads the stand-in bytes from stdin.
+Put those bytes in a file and redirect it into the harness:
 
 ```console
+hacker@dojo:~$ printf 'type-a-placeholder-flag-here\n' > fake-flag
 hacker@dojo:~$ gdb --args /challenge/harness your-solve.so
-(gdb) run
-type-a-placeholder-flag-here
+(gdb) run < fake-flag
 ```
 
 The checker will run that same harness shape with the real flag when you submit your `.so`.

challenges/computing-101/numbers-as-strings/itoa-two-digits/DESCRIPTION.md

@@ -19,10 +19,10 @@ Then return the number of characters written (in this case, 2).
 Remember to `.global itoa`.
 
 **Writing characters.**
-Your `itoa_digit` function from the last level returned the result (in `rax`), and you didn't have to deal writh writing it to a buffer.
+Your `itoa_digit` function from the last level returned the result (in `rax`), and you didn't have to deal with writing it to a buffer.
 Now, you do.
 Your actual character is _one byte_ (8 bits), whereas the register you're holding it in is 64 bits (8 bytes) long.
-You just want the last ("least significant") byte, and you can directly access it through _partial register alises_, depending on the register:
+You just want the last ("least significant") byte, and you can directly access it through _partial register aliases_, depending on the register:
 
 | register | least significant byte |
 | -------- | ---------------------- |
@@ -49,11 +49,11 @@ This is tricky, but do it carefully, and the flag is your reward!
 
 ----
 
-**Debugging:**
+**DEBUGGING TIPS:**
 This can get tricky to get right.
 To debug this challenge, our advice is to add a `_start` in your code, as so:
 
-```
+```asm
 .global _start
 _start:
     mov rdi, 42     // you'll pass 42 as the first argument to your function
@@ -76,3 +76,11 @@ hacker@dojo:~$ gdb ./debug
 ```
 
 Execution stops at your `int3`, and from there you can step through with the techniques you learned in [Software Introspection](/computing-101/introspecting), looking at memory on the stack, registers, etc, until things work!
+You can also debug the native harness that loads your `.so`:
+
+```console
+hacker@dojo:~$ gdb --args /challenge/harness your-solve.so 42
+(gdb) run
+```
+
+The first argument after `/challenge/harness` is your library, and the second is the stand-in number passed to `itoa`.

challenges/computing-101/the-stack-revisited/stale-stack-data/DESCRIPTION.md

@@ -31,4 +31,16 @@ hacker@dojo:~$ ld -shared -o solve.so solve.o
 hacker@dojo:~$ /challenge/check solve.so
 ```
 
-For debugging a submitted function inside a shared library, refer back to [Writing From a Shared Library](/computing-101/control-flow/callee-write).
+----
+
+**DEBUGGING TIPS:**
+For the general shared-library debugging workflow, use [Writing From a Shared Library](/computing-101/control-flow/callee-write).
+If you debug the checker path directly, load the native harness with `gdb`, not `/challenge/check`, and redirect stand-in flag bytes into it:
+
+```console
+hacker@dojo:~$ python3 -c 'import sys; sys.stdout.buffer.write(b"debug-stale-stack-flag\n" * 16)' > fake-flag
+hacker@dojo:~$ gdb --args /challenge/harness solve.so
+(gdb) run < fake-flag
+```
+
+The harness reads stand-in flag bytes from stdin, just as the checker feeds it, and the checker output also prints the exact stale-stack offset for this level.

challenges/linux-luminarium/chaining/script-args/challenge/run

@@ -19,7 +19,7 @@ if [ "$OUTPUT" = "$EXPECTED" ]; then
     cat /flag
 else
     echo "Not quite right!"
-    echo "Expected: $EXPECTED"
-    echo "Got: $OUTPUT"
+    echo "Expected: '$EXPECTED'"
+    echo "Got: '$OUTPUT'"
     exit 1
 fi

challenges/linux-luminarium/commands/mv/DESCRIPTION.md

@@ -15,4 +15,5 @@ hacker@dojo:~$
 ```
 
 This challenge wants you to move the `/flag` file into `/tmp/hack-the-planet` (do it)!
+Run `mv` directly from your shell, just like in the example above.
 When you're done, run `/challenge/check`, which will check things out and give the flag to you.

solve.sh

@@ -0,0 +1,2 @@
+#!/bin/bash
+echo "$2 $1"