What can a Gondosóra running Doom teach us about the security of closed devices?
At first glance, it is easy to see it as an amusing technical feat: artist András Bódai ran a heavily stripped-down version of Doom on hardware associated with the Gondosóra emergency-call wearable. Yet the project is more than another “can it run Doom?” experiment. It puts the spotlight on a closed device whose original purpose is to provide a reliable connection between its user and help when something goes wrong.
The documented project does not demonstrate a security incident affecting the service, nor does it prove that the Gondosóra service can be compromised remotely. It concerns the physical modification of a device for an artwork. That is precisely what makes it interesting: it reveals how a small, everyday emergency-call device is actually a complex cyber-physical system, in which hardware, software, communications and the service process together provide safety.
A game runs, but the original function disappears
According to Qubit’s account, the starting point was to run Doom on a hardware platform identical or very similar to that of the Gondosóra. With no display on the device, the game does not appear in its familiar, playable form. Instead, it runs a headless demo, with sound audible through the modified device’s speaker. Qubit – the story of the project
The project’s own documentation makes the main consequence clear: the conversion completely erases the original software, is irreversible, and leaves the modified unit unable to initiate an emergency call. András Bódai’s project documentation on GitHub
This distinction matters. The project does not demonstrate unauthorised control over a working emergency-call service. It removes a device’s original purpose and gives it another function. Running Doom is technically interesting, but after the conversion the device no longer performs the task it was designed for.
For an emergency-call device, availability is the central value
The official Gondosóra description lists a round-the-clock dispatch centre, two-way communication through the device, location support and fall detection. When help is requested, the dispatcher assesses the situation and may contact a nominated person, the relevant organisations or the 112 emergency service when necessary. Gondosóra – official service information
In a system like this, a device that powers on or an available network is not enough. The entire service chain needs to be available:
User → signalling device → mobile communications → dispatcher → assessment → assistance
If any link fails, the value of the service suffers. With a surveillance camera, the largest risk might be lost data or an inaccessible recording. With an emergency-call device, the question is even more immediate: can the wearer actually request help when it is needed?
The integrity and availability of such a device therefore extend beyond IT. They are directly connected to people’s safety.
A closed system is not necessarily an invulnerable system
One professional lesson is that the term “closed system” says little on its own. A device may be closed in the sense that users cannot install applications, access settings or change how it operates. That is not the same as comprehensive security.
According to the project documentation, the conversion required physical access, opening the device and erasing its original system. It did not happen silently while preserving normal operation: it sacrificed the original function. András Bódai’s project documentation on GitHub
This is an important distinction in risk assessment:
- a remote vulnerability may be exploitable without physical access;
- a destructive physical modification requires access to the device;
- a full erase may prevent restoration of the original system without necessarily giving access to its previous data or service.
The lesson is therefore not that an emergency-call wearable is easy to hack. It is that physical protection, firmware integrity and device lifecycle management are relevant design considerations for every connected endpoint.
Cybersecurity and physical security meet in the same device
Security systems increasingly contain endpoints that are both physical and digital: cameras, access readers, intercoms, alarm communicators, sensors, vehicle units and personal emergency-call devices.
Protecting network access alone is not enough. The following questions matter just as much:
- Who can physically access the device?
- What happens if it is opened, removed or replaced?
- How can approved software operation be verified?
- What happens during a fault, tampering or loss of communication?
- Who is informed when a system component stops fulfilling its original task?
- How is the device replaced, repaired and securely retired?
The answers do not necessarily lie in a single technical feature. Hardware protection, access control, encrypted communications, software updates, remote supervision and operating procedures work together to provide security.
These are general engineering considerations, rather than findings from an audit of the Gondosóra service.
Missing documentation is also an operational risk
Qubit reports that the artist struggled to find detailed technical information about the device. This raises two different questions. Qubit – the story of the project
First, detailed hardware descriptions, debugging interfaces and internal circuit diagrams are not necessarily public documents. Restricting access may be justified in some circumstances. The amount of publicly available technical information is not, by itself, a reliable measure of a system’s security.
The other question is whether authorised operators, service partners and responsible organisations have the documentation needed to operate the system. For a device with a critical function, that is a basic requirement. They need to understand approved device types, software version management, fault indications, replacement procedures and how a faulty or tampered unit is removed from service.
Adequate documentation does not mean making every technical detail freely available. It means that authorised parties understand the chain of responsibility and operation.
Good protection handles faults as well as intrusion
A common weakness in security design is to consider only the attacker’s perspective: can unauthorised access be prevented? That is important, but for an emergency-call or remotely supervised device, detecting abnormal operation is just as significant.
As a design requirement, operators should be informed if a device loses network connectivity, stops responding to status checks, has a damaged enclosure or fails an applicable firmware integrity check. Technology supports real safety when a deviation becomes an event requiring action: review, replacement, notification or an on-site inspection.
This way of thinking is familiar in conventional security engineering. Installing a sensor is not enough; somebody also needs to know whether it works, whether it is reachable and who responds when it fails.
An artwork that asks a question about the whole system
Doom on a Gondosóra is interesting for more than the sound of an old game coming from an unusual device. Its professional relevance lies in drawing attention to the true nature of everyday connected equipment.
Such a wearable is more than consumer electronics. It is a sensor, a communications endpoint, a software platform and the first link in a human assistance process. Protecting it therefore requires more than looking at its enclosure, buttons or mobile connection.
The most important question is not whether it can run a game. It is whether a device operating as intended preserves its purpose throughout its lifecycle: reliably allowing the wearer to request help when it is needed.
Sources: Qubit – the story of the project · András Bódai’s project documentation on GitHub · Gondosóra – official service information
Last reviewed:
Questions, or an idea to talk through?
Whether it is a security system, the IT network behind it or just a thought on this article, I am happy to hear from you.
Get in touch
