A couple of weeks ago, we conducted an online quest for hackers : we built a room that was filled with smart devices and launched a YouTube broadcast from it. Players could control IoT devices from the game site; the goal was to find the weapon hidden in the room (a powerful laser pointer), hack it, and short-circuit the room.
To add a thrilling plot, we put a shredder in the room, into which we loaded 200,000 rubles: the shredder ate a bill per hour. After winning the game, it was possible to stop the shredder and take all the remaining money.
We have already described the passage of the game , as well as how the backend of the project was made . It's time to tell you about the hardware and how it was going.
There were a lot of requests to show the moment of cleaning the room - we show how we disassemble it
Iron architecture: room control
We began to design the hardware solution when the scenario was already approximately clear, the backend was ready and we had an empty room ready for equipment installation.
Recalling the old joke "The S in IoT stands for Security" ("The letter S in the abbreviation IoT stands for Security"), we decided that this time players in the game scenario interact only with the front-end and back-end of the site, but do not get the opportunity to get directly to the gland.
This was done for reasons of safety and entertainment of what is happening on the screen: with the direct access of players to the hardware, it would be much more difficult to isolate safe and potentially dangerous actions, for example, speeding up the shredder or controlling pyrotechnics.
Before starting the design, we formulated several principles for controlling gaming devices, which became the basis of the design:
Do not use wireless solutions
The entire playing space is in one frame, every corner of which you can reach. There was no real need for wireless connections and they would just become another point of failure.
Do not use any special devices from the smart home
Mostly for the sake of customization flexibility. It is clear that it is possible to customize many boxed versions of smart home systems with a ready-made admin panel and management for our task, but the labor costs would be comparable to creating your own simple solution.
In addition, it was necessary to come up with devices that would clearly show what exactly the players change its state: turned on / off or put a specific light on the letters FALCON.
We collected all the elements from publicly available iron, which can be bought in ordinary radio parts stores: between the delivery of pizza and diet cola, couriers Chip and Deep and Leroy constantly came to the site.
The choice to assemble everything by ourselves simplified debugging, scalability, however, required more accuracy during installation.
All relays and arudino should not be visible in the frame
We decided to bring all the controllable elements into one place and hide them behind the scenes in order to be able to monitor the performance and, if necessary, to neatly crawl out of the camera's field of view and replace the failed unit.
As a result, everything was hidden under the table, and the camera was installed so that nothing could be seen below the table. This was our "blind
spot " for the engineer crawling.From a hardware point of view, this device controlled 6 elements:
- Several table lamps, they have an on / off state and are controlled by the players
- Letters on the wall, they can change their color at the command of the players
- Fans that spin and open the flipchart when the server is under load
- PWM controlled laser
- The shredder who ate money on a schedule
- A smoke machine that triggered before each laser shot
We test the smoke machine together with the laser.
Later, a stage light was added, which stood behind the frame and was controlled exactly like the lamps from point 1. The stage light was triggered in two cases: it illuminated the laser when power was applied to it and illuminated the weight before the laser was launched in combat mode.
What was this smart device?
We actually ended up with one smart device: it received the state of each of its parts from the backend and changed it with the appropriate command.
It was assumed that a simple script will be running on the computer that receives json with the state of the devices and sends it to the arduinka connected via usb. Later this computer was replaced by rasberry, it was connected to the backend because of nat.
Connected to ports:
- 16 conventional relays (they were the ones that made the clicking sound that was heard in the video. We mainly chose them because of this sound)
- 4 solid state relays for controlling PWM channels such as fans,
- separate PWM output for laser
- output that forms a signal to the LED strip
Here is an example of a json command that came to the relay from the server
{"power":false,"speed":0,"period":null,"deviceIdentifier":"FAN"}And this is an example of the function with which the team got to Arudino
def callback(ch, method, properties, body):
request = json.loads(body.decode("utf-8"))
print(request, end="\n")
send_to_serial(body)
To track the moment when the laser finally burns the rope and the weight will fly to the aquarium, we made a small button that triggered the weight falling and gave a signal to the system.
Button-monitoring of kettlebell movement
At this signal, smoke bombs made from ping-pong balls should have lit up. We put 4 smoke ducts directly into the server case and brought a nichrome thread to them, which was supposed to heat up and work like a fuse.
Body with smoke bombs and Chinese garland
Arduino
On the arduinka, according to the initial plan, two actions took place.
First, when a new request was received, the request was parsed using the ArduinoJson library. Further, several of its properties were associated with each controlled device:
- «» «» ( )
- , ( JSON , , )
- PWM ,
- , . 587 . , , , . .
The last time was set when the corresponding parameter was received in JSON, but it could not have been transmitted, then the value was set to 0 and zeroing did not occur.
The second action that the arduinka performed every cycle was the actualization of the states, that is, checking whether it was necessary to turn on something or whether it was time to turn off a device.
Laser pointer - the same Megatron 3000
This is a conventional laser module for cutting and marking LSMVR450-3000MF 3000mW 450nm with manual focus.
Falcon letters
Made very simple - we just copied the letters from the logo, cut them out of cardboard, and then pasted over with led tape. In this case, it was necessary to solder pieces of tape together, 4 contacts at each seam, but the result was worth it. Our backend Pasha showed miracles of skill, doing it in less than a few hours.
First tests of the iot device and finishing
We did the first tests and at the same time we got new problems. The fact is that in the middle of the process, a real film producer and cameraman from VGIK, Ilya Serov, joined the team - he built the frame, added additional cinematic lighting and slightly changed the scenario of the game so that the plot was more emotional, and the picture was more dramatic and theatrical.
This significantly increased the quality, but there were elements that also needed to be connected to the relay and the operation algorithm was prescribed.
The laser turned out to be another problem: we did several experiments with different types of ropes and lasers of different powers. For the test, we simply hung the load vertically on a rope.
When launched with a test token, the power adjustable through the PWM was less than 10% and the rope did not damage even after prolonged exposure.
For combat mode, the laser was defocused to approximately a spot with a diameter of 10 mm and it confidently burned through the rope with a load from a distance of about a meter.
This is how the laser worked perfectly on tests.
When we already started testing everything right in the room on a suspended weight, it turned out that it was not so easy to securely fix the laser. Then, when the rope is on fire, it melts, stretches and shifts from under the original focus.
But this is how it no longer worked: the rope was displaced
Ilya moved the laser to the end of the room opposite to the rope so that the laser beam would go through the entire scene and look beautiful in the frame, which doubled the distance.
After conducting a few more experiments with rope burning already in battle, we decided not to torture fate and insure the rope cutting with nichrome wire. She destroyed the thread 120 seconds after turning on the laser in combat mode. This, as well as the disconnection of the wire and the fuse of the smoke bombs when the breakaway contact is triggered, we decided to hard-code right in the hardware of the microcontroller.
The thread, which eventually burned the rope off-screen.
Thus, a third task appeared that the arduinka solved - to work out the sequences associated with the execution of these commands.
We also decided to give raspberry, which used to simply send ad-hoc JSON received from the backend, and the need to keep track of money on the TV and run the shredder. Initially, it was assumed that the backend would do this and the current balance would be visible on the site, and on the TV we would show comments from YouTube as an additional interactive element prompting viewers that events in the room were happening in real time.
But during the test run, Ilya watched the scene and suggested showing the game balance on the largest screen: how much money was left, how much was eaten, and the countdown until the next start of the shredder.
We tied Raspberry to the current time: every full hour the shredder was started. The picture was displayed on the TV with the help of the raspberry, which at that moment was already receiving requests from the server and sending them for execution to the arduinka. Pictures with monetary indicators were drawn using a call to the fim console utility like this
image = subprocess.Popen(["fim", "-q", "-r", "1920×1080", fim_str]), fim_str
And it was formed based on the required amount or time.
We generated the pictures in advance: we just took the finished video with a timer and exported 200 pictures.
This is the mechanic that was programmed in the quest. By the time the final countdown started, we all drove to the site, armed ourselves with fire extinguishers and sat down to wait for the fire (which burned with might and main only in discord)
How to make a broadcast that works for a week: choosing a camera
For the quest, we needed a continuous broadcast on YouTube for 7 days - that is how much we laid as the maximum duration of the game. There were two things that could hinder us:
- Overheating of the chamber from continuous operation
- Internet cut
The camera had to give at least Full HD picture in order to play and observe the room comfortably.
Initially, we looked in the direction of webcams that are released for streamers. We cut the budget, so we didn't want to buy a camera, but, as it turned out, they were not available for rent. At the same moment, we miraculously found the Xbox Kinect camera lying in my house, put it in the room and started a test broadcast for a week.
The camera coped well and did not overheat, but Ilya almost immediately noticed that it lacked settings, in particular, it was impossible to set the exposure.
Ilya strove to bring the type of broadcast closer to the standards of film and video production: to convey a dynamically changing light scene with bright light sources, darkened background and objects in the frame. At the same time, I wanted to preserve the elaboration of the image both in highlights and in shadows, with minimal digital noise.
Therefore, although the kinect proved to be reliable in tests and did not require a video capture card (another point of failure), we decided to abandon it. After three days of testing different cameras, Ilya chose the Sony FDR-AX53 - a small, reliable camcorder, affordable for rent, but at the same time with sufficient reliability and visual characteristics.
We rented a camera, turned it on for a week in conjunction with a video capture card, and realized that with it we could count on continuous broadcasting throughout the entire quest.
:
Working on the lighting required a certain grace, we needed to build a light score with minimal means:
1. Illumination of objects when they are found by players (laser, weight), as well as constant light on the shredder. Here they used dedolight 150 - reliable and compact cinema lighting devices with low-voltage halogen lamps, which allow you to focus the beam on a specific subject, without touching the background and other objects.
2. Practical play light - table lamp, floor lamp, star, garland. All practical light was harmoniously distributed in the frame to illuminate its area of the image, inside there were led lamps with a color temperature of 3200K, the lamp in the floor lamp was covered with a red Rosco folium filter to create an unusual color hint accent.
I'm an engineer with my mom or launch tomorrow
How we backed up internet and electricity
The issue of fault tolerance was approached almost like in a data center: they decided not to deviate from the basic principles and reserved according to the usual N + 1 scheme.
If the broadcast on YouTube stops, it means that it will be impossible to reconnect using the same link and continue the stream. It was a critical moment, and the room was in a regular office.
For this, we used an OpenWRT-based router and the mwan3 package. It automatically tested the channel availability every 5 seconds and, in case of a break, switched to the backup modem from Yota. As a result, switching to the backup channel took less than a minute.
It was also equally important to exclude power outages, because even a short-term power surge would cause a restart of all computers.
Therefore, we took the ippon innova g2 3000 uninterruptible power supply, which would back up all gaming devices: the total power consumption of our system was around 300 watts. It would be enough for 75 minutes, quite enough for our purposes.
We decided to sacrifice additional lighting in case the electricity goes out in the room - it was not connected to the UPS.
Acknowledgments
- To the entire RUVDS team , who invented and implemented the game.
- Separately for RUVDS admins, for monitoring the work of the servers, the load was acceptable and everything worked normally in normal mode.
- To the best boss ntsaplinfor the fact that in response to the call "there is an idea: we will take a server, put an aquarium on it, and hang a weight above it, boom, bang, everything is flooded with water, short circuit, fire!" he always confidently says "do it!"
- Tilda Publishing , - , .
- S_ILya , , , , , .
- zhovner , , , , .
- samat , , .
- daniemilk .
- delfphe .
- Dodo Pizza Engineering .
And the biggest gratitude is to the players for all the emotions that we experienced while you stormed the quest without sleep for two days and even postponed work.
Other articles about the quest with the destruction of the server
- Beginning of the game
- First clue
- Who stopped the shredder or how it was necessary to complete the quest with the destruction of the server
- Backend of a hacker game
