Understanding Software Backdoors: Real Cases, Legal Perspectives, and Technical Levels

Yesterday while browsing Zhihu, I came across a question that sparked three particularly interesting answers about software backdoors, which I am sharing here.

Answer 1 (by "特立独行的猪"): In an outsourced Android ROM project, the developer inserted a timestamp check hidden in a driver as a backdoor to ensure payment of the final installment. The backdoor was triggered months later, causing the device to fail to boot, pressuring the client to pay the remaining fees.

This anecdote reminded me of past experiences where freelancers vanished after delivering software, highlighting the risks of undisclosed hidden mechanisms.

Answer 2 (by "tombkeeper"): Chinese law does not specifically criminalize the existence of a backdoor; instead, liability depends on how the backdoor is used. If a backdoor is never exploited, it may not be illegal, but using it for malicious purposes can lead to prosecution.

The legal ambiguity extends to features like automatic updates, hot‑patch mechanisms, or remote maintenance, which may or may not be considered backdoors.

Answer 3 (by "沧海"): Backdoors can exist at various technical layers: low‑level code, toolchain, compiler, and even hardware. Ken Thompson’s famous compiler backdoor in early Unix illustrates a high‑level backdoor that survives source changes because the compiler itself is compromised. Similar techniques were used in the Xcode Ghost incident.

These examples show that backdoors can be extremely difficult to detect without insider knowledge.

Recently, a hacker group poisoned the IDA reverse‑engineering tool, demonstrating how even security‑focused software can be targeted.

Have you ever hidden a backdoor in code? Share your experiences in the comments.