HackASat (HAS): Satellite Bus//Magic Bus [91pt]

This last weekend, I had the opportunity to compete in the Air Force sponsored CTF, Hack A Sat. I played this CTF with the team I’ll be joining in July, the Aerospace Cyber Effects Group, out of Northrop Grumman’s Redondo Beach Campus, Los Angeles. We played under the pseudonym ACE, representing the official team name.

We placed well (23/1278 scoring teams), and while I was definitely one of the least experienced, if not the absolute least, experienced person on the team, I am proud of our results. While we didn’t qualify for finals, we did place on the top page of the final unofficial scoreboard.

The following write up is from a challenge that I spent a considerable amount of Saturday working on, and is the only one I actually submitted a flag for myself. I was primarily working with Erwin on this one, another team member, but at the end April joined us and provided some critical insight to get the solve. Without further ado, here we go…

Instructions & Introduction

When we go to the challenge page, unlike many other challenges from this CTF, we don’t have available files. All we are told is that:

There’s a very busy bus we’ve tapped a port onto, surely there is some juicy information hidden in the device memory… somewhere…

Then we are given a socket to connect to. When we connect we are asked for our team ticket, just like the other challenges. This was just the way the HAS admins decided to segregate teams. When we connect, we start receiving a stream of (what appear to be) bytes.

“The numbers mason, what do they mean!?”

The whole byte stream is fairly long, but for starters in the below image you may notice the carrot and period, which could be some sort of start and stop indicator. We also notice repeating patterns and similar strings.

If we sort this out using sed,, to break lines on the “terminating character” (.), we find out a few very interesting and important pieces of information. For starters, it would turn out that these are essentially packets, and the ^ad lines seem to mark a header, while the ^ac lines seem to mark a prefix for data. There are some other indicators, but the bigger takeaway, is that the very unique lines all start with ^20, so maybe this is data.

Lets start by stripping all the ^20 lines out and decoding them into ASCII. When we do this, we end up with 12 strings of data, and they seem to match up with a flag prefix… but unfortunately it comes up short from the standard flag length.

The above will ultimately allow us to reassemble the following string, even though the packets are out of order. Which appears to be the start of the flag. Unfortunately, we don’t see any closing bracket in our capture, and from previous challenges we know the flag format is flag{team-id:87 bytes}. We only have 79 bytes in the following. So something is up–we’re missing data.

flag{yankee44627golf:GKKFhb_d-8kZ8MTVyfafOOkT_9dnwt1bmnR7-Q9IkKHxyp_lF4oi6EwJ4zvvRA5W2ZZdlk1-d_zwDF

We spent 9 hours finding 9 bytes…

Ultimately, this is where another team member, April, came in and solved the final piece of the puzzle. It turns out, during the byte stream on initial connect, the stream pauses. From our packet analysis, we found that ‘^ad+00+00+3f+.’ always precedes the data streams. With this in mind, it makes sense that since we are sitting on a tap we are getting data from both ends of the transmission. It would make sense that this 4 byte stream is a request for data. We can now try to inject this into the tap to recieve additional information.

In the below video you can see the process of injecting this command on every pause, in order to leak additional information from memory, resulting in receiving the entire flag.

Now while we do get a different flag each run, in the below image, you can observe the difference in length between the two runs, indicating that we leaked more information from the memory.

When we convert this second dump back to ASCII, we have enough information to reassemble the entire 87 byte string, and finish the flag.

flag{yankee44627golf:GAank_x9P14VGa-6l9NWv3m73PbnaOD-MNg6XDRMyI1uPvc4XwhlaQiWXEkbgQUKgXMIBcIoy6tcOW7U3bDh8Jg}

Conclusion

We are fairly confident that aside from a potential lack of realism, this was an emulation of the space wire protocol. This protocol is commonly used by NASA to interact with satellites in orbit. We also have heard that there was an automated way to do this, but its fairly simple by hand, so pick your poison.

I had a significant hand in solving this challenge, and appreciated the competition that was put on, even if I was banging my head against 9 bytes for 9 hours and the whole problem for close to 11. Very interesting study in how non IP protocols work, and can be exploited.