publish 5 hack-a-sat 2022 writeups

writeups by bluepichu, nagi and f0xtr0t

Author: jaybosamiya

hackasat2022/bit-flipper/README.md

@@ -0,0 +1,64 @@
+# Bit Flipper
+
+For this problem, we were given a [binary](./bitflipper) that had a complicated routine for flipping bits in a variable based on user input that involved shifting and xor'ing.  While some of my teammates statically reversed the binary, I worked on black-boxing the entire process and making observations about how the program worked purely from observation.
+
+When connecting to the server, the user would basically get to play a game consisting of a number of rounds.  Every round the user would submit a number, and receive back a number from the server.  Pretty quickly, I had the following observations:
+
+1. Observation: If you submit 0 to the initial round, the server will return 16.
+2. Observation: If you submit 1 to the initial round, the server will return some number less than 16.
+3. Observation: If the server outputs `X` and then you submit any number `Y` twice in a row, then the server will output `X` again.
+
+Since we know it's doing something with XOR from the limited static reversing, observation (3) makes a lot of sense; you're simply doing and then ondoing an operation.  Next I decided to do a basic search by submitting the pattern `1, 2, 1, 4, 1, 2, 1, 8, ...`; note that after each step of this pattern, the cumulative XOR of the values submitted so far is always unique.  This gave rise to the following observations:
+
+4. Observation: When submitting this pattern, every other value returned by the server would be 16.
+5. Observation: By comparing results across multiple runs, it appeared that lower numbers were less frequent, and each value `X` appeared approximately half as often as `X+1`.
+
+Let's reformulate the game slightly: you start at some hidden value `I`, and over time build up some value `X` (which starts at 0), and the server gives you some value derived from `I ^ X`.  With this terminology and the observations so far, we can derive the following:
+
+6. Deduction from (1), (2), and (4): the server will return 16 if and only if `X` has an even number of 1s.
+7. Hypothesis from (5): the goal is to get the server to return 0.
+
+The next step I took was to dump the server's response alongside the cumulative value of `X` at every step across several runs of the program.  (I would provide some sample data, but the problem unfortunately is no longer online at the time of writing. [Sidenote by teammate who did static reversing: despite having access to the binary, the `hardest_rotations.nums` is not provided and only exists on the server, thus re-creating sample data is non trivial])  I then spent a very long time looking for patterns, before noticing the following:
+
+8. Observation: If the last number the server returned was 13 and you submit 15, then the server will return some number less than 13, and vice versa.
+
+This observation seemed to hold across multiple tests, so I accepted it as a fact.  This seemed to give a good direction of how to build up to a solution: we know that we can "escape" 16 by submitting 1, and that we can "escape" 15 by submitting 3, so if we can find these "magic" number for each value greater than 0, we should be able to reduce all the way to 0 in at most 16 steps.
+
+After staring at output for a while longer (guided by observation (6) to only check masks with an even number of 1 bits), I came to two more observations about magic numbers:
+
+9. Observation: 3 is a magic number for 15.
+10. Observation: 5 is a magic number for 14.
+11. Observation: 9 IS NOT a magic number for 13.
+12. Observation: 17 is a magic number for 12.
+
+I got stuck at this point for quite a long time.  The biggest issue was that the limit of 100 rounds per connection meant that only one or two sub-12 values would generally appear per run, but I was also just simply stumped at trying to find the pattern.
+
+However, after writing out what I knew on the whiteboard a few times, inspiration struck.  At one point I had written the magic numbers like this:
+
+```
+16: 00001
+15: 00011
+14: 00101
+13: 01111
+12: 10001
+```
+
+Something about this pattern looked really _familiar_.  After a while I erased the leading zeros and shifted around how I was writing it:
+
+```
+16:     1
+15:    1 1
+14:   1 0 1
+13:  1 1 1 1
+12: 1 0 0 0 1
+```
+
+Wait, that's a Sierpinski triangle in binary!  This led me to what I described to my teammates as "the conspiracy theory":
+
+13. Conspiracy Theory from (2), (8), (9), (10), (12): the `16-X`'th row of the binary Sierpinski triangle is a magic number for `X`.
+
+I tried it on a couple more runs by hand, and lo and behold, it seemed to be working.  Ultimately I reorganized my testing script a little to simply always submit the magic number from (13); see `solve.py`.  To my extreme surprise, out popped a flag!
+
+To this day I still have no idea what the intended path in this problem was.  My understaning from my teammates' limited static reversing is that the variable that you're trying to clear is being used as an index into some array, and that's the source of the numbers we're getting back.  However, this array is read from a file we weren't given (`hardest_rotations.nums`), so I'm not sure how we were supposed to use that info.  Additionally, you had to play the game three times with slightly different rules to get the flag, but this solution somehow solves all of them, which I also don't understand.  Given that we know that it has something to do with bit shifts and XORing the fact that Sierpinski triangles could be relevant _kind of_ makes sense (since `row(X)` can be expressed as `row(X-1) ^ (row(X-1) << 1))`) I guess?
+
+Definitely the weirdest first blood I've ever gotten in a CTF; it's not often you can solve a reversing problem without opening the binary or running it locally even one time.

hackasat2022/bit-flipper/bitflipper

@@ -0,0 +1,31 @@
+# type: ignore
+from pwn import *
+from collections import defaultdict
+
+context.log_level = "debug"
+
+host, port, ticket = "bitflipper.satellitesabove.me", 5100, "ticket{kilo724075quebec3:GHzGbhQyAzk0-vCEHXkseedkyaz6UWKGe81DO24euHhgDqz3TyBpnjMUq5S_FXFNZg}"
+
+freq = defaultdict(lambda: 0)
+conspiracy = [1]
+
+for i in range(15):
+	last = conspiracy[-1]
+	conspiracy.append(last ^ (last << 1))
+
+conn = remote(host, port)
+conn.recvuntil(b"Ticket please:\n")
+conn.sendline(bytes(ticket, "utf-8"))
+print("sent ticket")
+
+for i in range(3):
+	val = 16
+	while True:
+		conn.recvuntil("Guess: ")
+		conn.sendline(str(conspiracy[16 - val]))
+		out = conn.recvline().strip().decode("utf-8")
+		if "Reset" in out:
+			continue
+		val = int(out)
+
+conn.interactive()

hackasat2022/bit-flipper/solve.py

@@ -0,0 +1,7 @@
+# Crosslinks
+
+In this problem, we are given TLE orbital parameters for 75 satellites, and are tasked with determining which of the satellites is "us".  To accomplish this, we are given observations of other satellites relative to ours at known points in time.
+
+Since the distances given were near-exact, the simplest solution was to simply take the first observation and find the satellite with a distance most closely mtching that observation; this is easily accomplished using `skyfield` to do the orbital math, and just checking all 74 possibilities against the selected observation.  Repeating this several times was sufficient to get a flag.
+
+See `solve.py` for our implementation.

hackasat2022/crosslinks/README.md

@@ -0,0 +1,57 @@
+# type: ignore
+from pwn import *
+from collections import defaultdict
+from random import random
+from skyfield.api import EarthSatellite, load
+import numpy as np
+from datetime import datetime
+
+context.log_level = "debug"
+
+host, port, ticket = "crosslinks.satellitesabove.me", 5300, "ticket{foxtrot251655whiskey3:GJs6DkwHX--L4IKX3Xus_mKOHZ66y2BxS326fnIenHp9rihAPow4-yuDsYuXEiFAqw}"
+
+conn = remote(host, port)
+conn.recvuntil(b"Ticket please:\n")
+conn.sendline(bytes(ticket, "utf-8"))
+
+while True:
+	conn.recvuntil(b"TLE\n")
+
+	satellites = {}
+
+	ts = load.timescale()
+
+	for i in range(75):
+		name = conn.recvline().strip().decode("utf-8")
+		l1 = conn.recvline().strip().decode("utf-8")
+		l2 = conn.recvline().strip().decode("utf-8")
+		satellites[name] = EarthSatellite(l1, l2, name, ts)
+
+	print(satellites)
+
+	conn.recvuntil(b"Observations ")
+	target_name = conn.recvline().strip().decode("utf-8")
+	conn.recvline()
+	t_str, d_str, _ = conn.recvline().decode("utf-8").split(", ") # e.g. 2022-01-26T09:10:36.138301+0000
+	time = datetime.strptime(t_str, "%Y-%m-%dT%H:%M:%S.%f%z")
+	d = float(d_str)
+	t = ts.from_datetime(time)
+
+	target = satellites[target_name]
+
+	print(target_name, t)
+
+	closest = ""
+	closest_delta = float("inf")
+
+	for sat in satellites:
+		dist = np.linalg.norm((satellites[sat] - target).at(t).position.km)
+		delta = abs(dist - d)
+		print(sat, dist)
+		if delta < closest_delta:
+			closest_delta = delta
+			closest = sat
+
+	conn.sendline(closest)
+
+# conn.interactive()

hackasat2022/crosslinks/solve.py

@@ -0,0 +1,114 @@
+# Navigation Rebooting
+
+In this problem, we were tasked with determining the position and veolcity of a satellite given psuedorange and velocity data relative to other satellites with known orbits at a fixed point in time.  Initially, misunderstanding the difference between a _range_ and a _pseudorange_, I formulated a solution that solved for the least-squares error on the position and velocity while treating the provided measurements as truth.  The least-squares solution for position arose from the following derivation:
+
+$$
+\begin{align*}
+\vec{p} &= \text{position of the satellite we want to solve for} \\
+\vec{q}&= \text{known position of another satellite} \\
+\vec{r}&= \text{known position of a second satellite} \\
+\\
+\left\Vert \vec{p} - \vec{s} \right\Vert^2 &= \left\Vert \vec{p} \right\Vert^2 - 2 \left( \vec{p} \cdot \vec{s} \right) + \left\Vert \vec{s} \right\Vert^2 & \text{for any satellite $s$} \\
+\Rightarrow \: \: \left\Vert \vec{p} - \vec{q} \right\Vert^2 - \left\Vert \vec{p} - \vec{r} \right\Vert^2 &= \left( \left\Vert \vec{p} \right\Vert^2 - 2 \left( \vec{p} \cdot \vec{q} \right) + \left\Vert \vec{q} \right\Vert^2 \right) - \left( \left\Vert \vec{p} \right\Vert^2 - 2 \left( \vec{p} \cdot \vec{r} \right) + \left\Vert \vec{r} \right\Vert^2 \right) \\
+\Rightarrow \: \: \left\Vert \vec{p} - \vec{q} \right\Vert^2 - \left\Vert \vec{p} - \vec{r} \right\Vert^2 - \left\Vert \vec{q} \right\Vert^2 + \left\Vert \vec{r} \right\Vert^2 &= 2 \left( \vec{p} \cdot \vec{r} - \vec{p} \cdot \vec{q} \right) \\
+\Rightarrow \: \: \left\Vert \vec{p} - \vec{q} \right\Vert^2 - \left\Vert \vec{p} - \vec{r} \right\Vert^2 - \left\Vert \vec{q} \right\Vert^2 + \left\Vert \vec{r} \right\Vert^2 &= 2 p_x (r_x - q_x) + 2 p_y (r_y - q_y) + 2 p_z (r_z - q_z) \\
+\end{align*}
+$$
+
+Since all of these values are known except for $p_x$, $p_y$, and $p_z$, we can approximate the solution by the least squares solution to
+
+$$
+\begin{align*}
+A \begin{bmatrix} p_x \\ p_y \\ p_z \end{bmatrix} &= b \\
+\\
+\text{where} \\
+\\
+A &= \begin{bmatrix}
+2 (r_{1,x} - q_x) & 2 (r_{1,y} - q_y) & 2 (r_{1,z} - q_z) \\
+2 (r_{2,x} - q_x) & 2 (r_{2,y} - q_y) & 2 (r_{2,z} - q_z) \\
+\vdots & \vdots & \vdots \\
+\end{bmatrix} \\
+b &= \begin{bmatrix}
+\left\Vert \vec{p} - \vec{q} \right\Vert^2 - \left\Vert \vec{p} - \vec{r_1} \right\Vert^2 - \left\Vert \vec{q} \right\Vert^2 + \left\Vert \vec{r_1} \right\Vert^2 \\
+\left\Vert \vec{p} - \vec{q} \right\Vert^2 - \left\Vert \vec{p} - \vec{r_2} \right\Vert^2 - \left\Vert \vec{q} \right\Vert^2 + \left\Vert \vec{r_2} \right\Vert^2 \\
+\vdots
+\end{bmatrix}
+\end{align*}
+$$
+
+by picking one of the satellites with known orbit to act as $q$ and using the other satellites as the various values of $r_i$.
+
+For velocity, we used the following derivation:
+
+$$
+\begin{align*}
+v_{pq} &= \text{rate of change of distance from $p$ to $q$ (known)} \\
+\vec{v_p} &= \text{velocity of $p$ (unknown)} \\
+\vec{v_q} &= \text{velocity of $q$ (known)} \\
+\hat{pq} &= \text{unit vector from $p$ to $q$ (known)} \\
+\\
+v_{pq} &= \left( \vec{v_q} - \vec{v_p} \right) \cdot \hat{pq} \\
+\Rightarrow \: \: v_{pq} &= \vec{v_q} \cdot \hat{pq} - \vec{v_p} \cdot \hat{pq} \\
+\Rightarrow \: \: \vec{v_p} \cdot \hat{pq} &= \vec{v_q} \cdot \hat{pq} - v_{pq}
+\end{align*}
+$$
+
+Since the only unknown is $\vec{v_p}$, we can solve for it by finding the least-squares solution to
+
+$$
+\begin{align*}
+A \begin{bmatrix} {v_p}_x \\ {v_p}_y \\ {v_p}_z \end{bmatrix} &= b \\
+\\
+\text{where} \\
+\\
+A &= \begin{bmatrix}
+\hat{pq_1}_x & \hat{pq_1}_y & \hat{pq_1}_z \\
+\hat{pq_2}_x & \hat{pq_2}_y & \hat{pq_2}_z \\
+\vdots & \vdots & \vdots \\
+\end{bmatrix} \\
+b &= \begin{bmatrix}
+\vec{v_{q_1}} \cdot \hat{pq_1} - v_{pq_1} \\
+\vec{v_{q_2}} \cdot \hat{pq_2} - v_{pq_2} \\
+\vdots
+\end{bmatrix}
+\end{align*}
+$$
+
+using the known satellites for the various values of $q_i$.
+
+Running this solution got us _close_, but not close enough.  The reason for this is that we were given _pseudoranges_ rather than ranges, the difference being that ranges are treated as absolute distance measurements while pseudoranges may have errors caused by receiver clock bias and path delays.
+
+To solve using the pseudoranges, I implemented the algorithm described [in this helpful summary of the topic](http://www.grapenthin.org/notes/2019_03_11_pseudorange_position_estimation/); see the implementation in `solve_pseudo.py`.  Once you work through all of the math, it boils down to iterating on this linear system until you sufficiently converge on a solution:
+
+$$
+\begin{align*}
+\vec{p} &= \text{our current solution for the position of the satellite} \\
+t &= \text{our current solution for the clock bias} \\
+\vec{s_i} &= \text{known position of satellite $i$ at time of observation} \\
+\rho_i &= \text{observed distance to satellite $i$} \\
+c &= \text{the speed of light} \\
+\ell &= \text{gradient rate (we used 0.01)}
+\\
+\\
+\text{Solve} \; \; A \begin{bmatrix}\Delta p_x \\ \Delta p_y \\ \Delta p_z \\ \Delta t\end{bmatrix} &= b \\
+\text{where} \; \; A &= \begin{bmatrix}
+	\frac{{s_1}_x}{\left\Vert \vec{p} - \vec{s_1} \right\Vert} &
+	\frac{{s_1}_y}{\left\Vert \vec{p} - \vec{s_1} \right\Vert} &
+	\frac{{s_1}_z}{\left\Vert \vec{p} - \vec{s_1} \right\Vert} &
+	c \\
+	\vdots & \vdots & \vdots & \vdots
+\end{bmatrix} \\
+b &= \begin{bmatrix}
+	\rho_1 - \left\Vert \vec{p} - \vec{s_1} \right\Vert - c t \\
+	\vdots
+\end{bmatrix} \\
+\\
+\\
+\text{and then update} \; \; \vec{p'} &= \vec{p} + \ell \begin{bmatrix}\Delta p_x \\ \Delta p_y \\ \Delta p_z\end{bmatrix} \\
+t' &= t + \ell \Delta t
+\end{align*}
+$$
+
+Note that this solves only for position and not for velocity.
+
+We tried submitting this solution with the best velocity value found from our old solver, but this wasn't close enough.  However, we noticed that the solution that our pseudorange solver converged upon was consistent with almost exactly 50 microseconds of clock bias, or 15km of distance error.  By hardcoding this 15km into the original solver, we were able to produce a solution that was close enough to get a flag; see `solve.py`, and note the hardcoded value on line 85.