A couple of weeks ago we spent : built a room that was filled with smart devices and launched a YouTube broadcast from it. Players could control IoT devices from the game's website; the goal was to find a weapon hidden in the room (a powerful laser pointer), hack it and arrange a short circuit in the room.
To add action, we put a shredder in the room, into which we loaded 200 rubles: the shredder ate one bill per hour. After winning the game, it was possible to stop the shredder and take all the remaining money.
We have already told and project. It's time to talk about hardware and how it was going to.
There were a lot of requests to show the moment of cleaning the room - we show how we take it apart
Hardware architecture: room management
We started designing a hardware solution when the scenario was already approximately clear, the backend was ready, and we had an empty room ready for equipment installation.
Remembering the old anecdote βThe S in IoT stands for Securityβ (βThe letter S in IoT stands for Securityβ), we decided that this time the game scenario players interact only with the front-end and back-end of the site, but do not get the opportunity to get directly to iron.
This was done for safety and entertainment reasons: with players directly accessing the hardware, it would be much more difficult to isolate safe and potentially dangerous actions, such as speeding up a shredder or controlling pyrotechnics.
Before starting the design, we formulated several principles for controlling gaming devices, which became the basis for the design:
Do not use wireless solutions
The entire playing space is in one frame, every corner of which can be reached. There was no real need for wireless connections and they would just become another point of failure.
Do not use any special smart home devices
Basically, for the sake of customization flexibility. It is clear that many boxed versions of smart home systems with a ready-made admin panel and control can be configured for our task, but the labor costs would be comparable to creating our own simple solution.
In addition, it was necessary to come up with devices that would clearly show that it was the players who changed its state: they turned it 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 Coke, couriers Chip and Deep and Leroy constantly came to the site.
The choice to assemble everything 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 controlled elements into one place and hide them behind the scenes in order to be able to control the performance and, if necessary, carefully crawl out of the camera's field of view and replace the failed unit.
As a result, everyone 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 crawling engineer
As a result, we actually got one smart device: it received the state of each of its parts from the backend and changed it with the appropriate command.
In terms of hardware implementation, 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
- Laser controlled via PWM
- Schroeder who ate money on schedule
- A smoke machine that fired before every laser shot
Testing a smoke machine with a laser
Later, another stage light was added, standing behind the scenes and controlled exactly like the lamps from point 1. The stage light worked 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
All the way, Yura, our hardware specialist, tried not to complicate things and came up with the simplest, most minimalistic solution possible.
It was assumed that just a script would run on the VPS that receives json with the state of the devices and sends it to the arduino connected via usb.
Ports connected to:
- 16 ordinary relays (they were the ones that made the click that was heard in the video. We mainly chose them because of this sound)
- 4 solid state relays to control PWM channels such as fans,
- separate PWM output for laser
- output that generates 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 a function with which the command got to the arudino
def callback(ch, method, properties, body):
request = json.loads(body.decode("utf-8"))
print(request, end="n")
send_to_serial(body)To keep track of the moment when the laser finally burns out the rope and the weight flies to the aquarium, we made a small button that responded to the fall of the weight and gave a signal to the system.
Kettlebell movement monitoring button
At this signal, smoke bombs made from ping-pong balls were supposed to light up. We put 4 chimneys directly into the server case and brought a nichrome thread to them, which was supposed to heat up and work like a fuse.
Case with smoke bombs and Chinese garland
Arduino
On the arduino, according to the original plan, two actions took place.
First, when a new request was received, the request was parsed using the ArduinoJson library. Next, each managed device was associated with two of its properties:
- power state "on" or "off" (standard state)
- the period for which the device is turned on β the time in microseconds from the start of the board, when it is time to turn it off, that is, bring the state to the standard
The last time was set when the corresponding parameter was received in JSON, however, it could not be passed, then the value was set to 0 and zeroing did not occur.
The second action that the arduino performed every cycle was the actualization of the states, that is, checking whether there is a need to turn something on or whether it is time to turn off any device.
Laser pointer - the same Megatron 3000
This is a conventional laser cutting and marking module LSMVR450-3000MF 3000mW 450nm with manual focus.
Falcon letters
Made very simply - we just copied the letters from the logo, cut them out of cardboard, and then glued them with led tape. At the same time, I had to solder pieces of tape together, 4 contacts on each seam, but the result was worth it. Our backender Pasha showed miracles of skill, doing it in less than a few hours.
The first tests of the iot device and finishing
We made the first tests and at the same time new tasks approached us. The fact is that in the middle of the process, a real film producer and cameraman from VGIK, Ilya Serov, joined the team - he lined up the frame, added additional cinematic lighting and slightly changed the script of the game to make the plot more emotional, and the picture more dramatic and theatrical.
This significantly increased the quality, but there were elements that also needed to be connected to the relay and prescribe the operation algorithm.
Another problem was the laser: we did several experiments with different types of rope and lasers of different powers. For the test, we simply hung the load vertically on a rope.
When running with the test token, the power regulated through the PWM was less than 10% and the rope did not damage even with a long exposure.
For the combat mode, the laser was defocused to about a spot with a diameter of 10 mm and it confidently burned the rope with a load from a distance of about a meter.
So the laser worked perfectly in tests
When we 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 burns, it melts, stretches and shifts from under the original focus.
And this is how it no longer worked: the rope shifted
Ilya moved the laser to the opposite end of the room from the rope, so that the laser beam went across the entire scene and looked beautiful in the frame, which doubled the distance.
Having carried out a few more experiments with burning the rope already in battle, we decided not to tempt fate and secure the cutting of the rope with the help of 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 smoke bombs when the tear-off contact is triggered, we decided to hard-code it right in the microcontroller hardware.
The thread that ended up burning the rope behind the scenes
Thus, the third task appeared that the arduino solved - to work out the sequences associated with the execution of these commands.
We also decided to give the arduino the need to count money on the TV and run the shredder. Initially, it was assumed that the backend would take care of 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 that prompts viewers that the events in the room are 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 launch of the shredder.
We tied the Arduino to the current time: every full hour the shredder started. The picture on the TV was issued with the help of a raspberry, which at that moment already received requests from the server and sent them to the arduino for execution. Pictures with monetary indicators were drawn by calling 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 kind of mechanics that was programmed into the cross. By the time the final countdown started, we all went to the site, armed ourselves with fire extinguishers and sat down to wait for the fire (which was blazing with might and main only in the discord)
How to make a broadcast that runs for a week: choosing a camera
For the quest, we needed a continuous broadcast on YouTube for 7 days - that's how much we laid as the maximum duration of the game. There were two things that could interfere with us:
- Overheating of the camera from continuous operation
- Internet break
The camera had to give a picture of at least Full HD in order to play and watch the room comfortably.
Initially, we looked towards 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 donβt give them for rent. At the same moment, we miraculously found an Xbox Kinect camera lying in my house, put it in the room and launched 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 tried to bring the look of the broadcast closer to the standards of film and video production: to convey a dynamically changing light scene with bright light sources, a darkened background and objects in the frame. At the same time, I wanted to keep the image elaboration both in the highlights and in the shadows, with minimal digital noise.
Therefore, although the kinect proved to be reliable during 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 fine performance.
We rented a camera, turned it on for a week in conjunction with a video capture board, and realized that with it we could count on continuous broadcasting throughout the entire quest.
Making a Movie: Stage and Lighting
Working on lighting required a certain elegance, 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 a constant light on the shredder. Here we used dedolight 150 - reliable and compact lighting fixtures with low-voltage halogen lamps that allow you to focus the beam on a specific subject without touching the background and other objects.
2. Practical game light - table lamp, floor lamp, star, garland. All practical light was harmoniously distributed in the frame to illuminate its image area, inside there were led lamps with a color temperature of 3200K, the lamp in the floor lamp was covered with a Rosco red foil filter to create an unusual color accent-tip.
I'm my mom's engineer or launch tomorrow
How we reserved 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 stops on YouTube, it means that it will no longer be possible to reconnect using the same link and continue streaming. It was a critical moment, and besides, the room was in an ordinary office.
To do this, we used an OpenWRT-based router and the mwan3 package. It automatically tested the availability of the channel every 5 seconds and, in the event of a break, switched to a 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 power surge would cause all computers to reboot.
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, enough for our purposes.
We decided to sacrifice additional lighting in case the electricity went out in the room - it was not connected to the uninterruptible power supply.
Acknowledgements
- Whole team who designed and developed the game.
- Separately, to the RUVDS admins, for monitoring the work of the servers, the load was acceptable and everything worked normally in normal mode.
- best boss for 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 over it, boom, bang, everything was flooded with water, short circuit, fire!β he always confidently says "do it!"
- Thank you and separately to Mikhail Karpov for not only going forward and allowing us to violate the Terms of Use, but even giving us a business account for a year when we talked about the project.
- Ilya Serov for joining and becoming a co-producer of the project, ready to crawl half the night, sticking LED strip, look for technical solutions and do everything so that we have a real movie.
- for always being ready to save the situation when others shrugged, wrestler, moral support and conversations until the morning.
- for putting us in touch with the best pentester in the country who advised us and helped us with the puzzles.
- for the cool video production of all videos.
- for a firm hand and readiness to work to the last.
- ΠΡ for almost always warm pizza.
And the biggest gratitude is to the players for all the emotions that we experienced while you stormed the quest for two days without sleep and even postponing the work.
Other articles about the quest with the destruction of the server
Source: habr.com