DRAFT
Background
Our client ELT, has designed proprietary Counter-Drone software and hardware for use at sport stadiums, airports, and even military bases. Their system allows for “drone catching” aka targeted jamming of Wi-Fi and radio to cause the drone to land, without causing major disruptions that you’d have with broadcasted jamming.
ELT had asked us to make training software that could interface with Thor, to allow Operators to get familiar with the software with in realistic scenarios.
ELT was not able to provide us source code since it was developed by another group of contractors.
What this boiled down to is reverse engineering the communication protocol. This was because ELT was not able to give us source code since Thor had been made by another group of contractors.
Tech Stack
As this was my first project at TXT, I was working with my senior Pieter Van Duin, who suggested we use C#, which at the time was the language we were both most comfortable in. (Though, Nodejs was brought up as another option.)
We developed the app using dotnet 3.1 (LTS at the time) as a WPF app, which allowed us to build a singular .exe including the mock server backend and control panel to select and play various scenarios.
Nitty Gritty
Pieter and I initially pair programmed to get something we could both work on simultaneously. Once we got a basic TCP Server that could playback the samples, we could split up the work. Pieter, having more experience, worked primarily on the server implementation (though I would take that over, as Pieter was involved on other projects) meanwhile I worked on the UI.
Challenges
TODO make this section shorter
Also include sections
Protocol
Playback speed
Realistic Reactions
Playback generation
Slerp
(spherical linear interpolation)
As previously mentioned, we had to reverse engineer the protocol being used. Luckily for us Thor itself comes with a record and playback mode and ELT provided us some playback samples.
This playback mode came with several limitations and could not be used in collaboration with multiple operators. Most features were also disabled during playback.
Using the playback samples, we could see that Thor communicated via a stream of JSON messages. This meant that we could simply create a TcpServer. We were effectively making a Game server, though we had the benefit that “Multiplayer” would only ever be on a LAN network, meaning we didn’t have to deal with latency related issues.
Protocol changed half way thru development
One day we received an updated version of the Thor client, which was no longer able to communicate with our Game Server. After an hour and some amount of panic, we found that the Thor client was now expecting a
\ncharacter at the end of the JSON blobs.
This case study is part of a series Interesting Projects I’ve Shipped.