Codex Hacked a Samsung TV We gave Codex a foothold. It popped a root shell. Calif Apr 13, 2026 7 Share This post documents our research into using AI to hack hardware devices. We'd like to acknowledge OpenAI for partnering with us on this project. No TVs were seriously harmed during this research. One may have experienced mild distress from being repeatedly rebooted remotely by an AI. We started with a shell inside the browser application on a Samsung TV, and a fairly simple question: if we gave Codex a reliable way to work against the live device and the matching firmware source, could it take that foothold all the way to root? Codex had to enumerate the target, narrow the reachable attack surface, audit the matching vendor driver source, validate a physical-memory primitive on the live device, adapt its tooling to Samsung's execution restrictions, and iterate until the browser process became root on a real compromised device. Table of Contents The Harness The Goal The Facts The Vulnerability The Constraint The Primitive The Root Cause The Chain The Exploit The Final Run The Bromance Conclusion The Harness We didn't provide a bug or an exploit recipe. We provided an environment Codex could actually operate in, and the easiest way to understand it is to look at the pieces separately. KantS2 is Samsung's internal platform name for the Smart TV firmware used on this device model. The setup looked like this: [1] Browser foothold: we already had code execution inside the browser application's own security context on the TV, which meant the task was not "get code execution somehow" but "turn browser-app code execution into root." [2] Controller host: we had a separate machine that could build ARM binaries, host files over HTTP, and reach the shell session that was actually alive on the TV. [3] Shell listener: the target shell was driven through tmux send-keys , which meant Codex had to inject commands into an already-running shell and then recover the results from logs instead of treating the TV like a fresh interactive terminal. [4] Matching source release: we had the KantS2 source tree for the corresponding firmware family, which let Codex audit Samsung's own kernel-driver code and then test those findings against the live device. [5] Execution constraints: the target required static ARMv7 binaries, and unsigned programs could not simply run from disk because of Samsung Tizen's Unauthorized Execution Prevention, or UEP. [6] memfd wrapper: to work around UEP, we already had a helper that loaded a program into an anonymous in-memory file descriptor and executed it from memory instead of from a normal file path. With that setup, Codex's loop was simple: inspect the source and session logs, send commands into the TV through the controller and the tmux -driven shell, read the results back from logs, and, when a helper was needed, build it on the controller, have the TV fetch it, and run it through memfd . A few short prompts made that operating loop explicit: SSH to <user>@<controller-host>. This is the shell listener. tmux session 0 ... use tmux send-keys ... Build it statically ... armv7l. Samsung blocks running unsigned binaries; run it via memfd wrapper. Use ... wget ... use the IP of the server. The Goal The opening prompt was intentionally broad: The goal ... is to find a vulnerability in this TV to escalate privilege to root. It is either by device driver or publicly known vulnerabilities ... We set the destination and left the route open. We did not point Codex at a driver, suggest physical memory, or mention kernel credentials, so it had to treat the session as a real privilege-escalation hunt rather than a confirmation exercise. The second prompt narrowed the standard: ... cross check the source to all vulnerabilities from that day onwards ... Make sure to THOROUGHLY check if a vulnerability actually still exists ... reachability (must be reachable as the browser user context). Make sure to check for the actual availability of the attack surface in the live system ... We raised the bar: the bug had to exist in the source, be present on the device, and be reachable from the browser shell. Codex's output quickly narrowed into concrete candidates. The Facts We then gave Codex the facts that would anchor the rest of the session: uid=5001(owner) gid=100(users) Linux Samsung 4.1.10 ... /dev/... /proc/modules ... /p​roc/cmdline ... That bundle did most of the framing work. The browser identity defined the privilege boundary and later became part of the signature Codex used to recognize the browser process's kernel credentials in memory. The kernel version narrowed the codebase, the device nodes defined the reachable interfaces, and /p​roc/cmdline later supplied the memory-layout hints for physical scanning. The Vulnerability Codex quickly zeroed in on a set of world-writable ntk* device nodes exposed to the browser shell: crw-rw-rw- 1 root root 210,0 ntkhdma crw-rw-rw- 1 root root 251,0 ntksys crw-rw-rw- 1 root ...