No Heatsinks Allowed

No Heatsinks Allowed

Speakers: Trey Keown, Security Researcher, Crystal Peak Security

Conference: DistrictCon

YouTube: https://www.youtube.com/watch?v=sSAK6wxZZ64

Overview

In his DistrictCon talk, "No Heatsinks Allowed," Trey Keown, a Security Researcher at Crystal Peak Security, delves into the often-overlooked world of low-resource devices. Keown affectionately refers to these as "little guys" – ubiquitous, constrained pieces of technology that, despite their pervasive presence, rarely receive the security attention afforded to more powerful systems. The talk serves as both an exploration of these devices' unique challenges and an inspiring call to action for security researchers to engage with the "junk drawer" of forgotten or ignored hardware.

Keown's core thesis is that the constraints inherent in low-resource computing, far from being deterrents, can foster innovation and reveal profound insights into fundamental computing principles. By dissecting various forms of constraint—memory, storage, power, size, expressiveness, and cost—he illustrates how these limitations shape device architecture and behavior. The talk culminates in a deep dive into smart cards, revealing their surprising technical sophistication (including running Java) and demonstrating how a custom C compiler, JCC, can unlock their hidden potential for purposes far beyond their intended design, even running classic video games.

This presentation is highly relevant to the cybersecurity community as it highlights a vast attack surface that is often ignored. From critical infrastructure like smart utility meters and payment systems to personal identity cards, these constrained devices underpin significant aspects of modern life. Understanding their unique architectures, common programming paradigms, and the tooling required to interact with them is essential for identifying and mitigating vulnerabilities that could have widespread impact, urging defenders to look beyond conventional targets and embrace the complexity of the "little guys."

Background

▶ Watch: What's in your junk drawer: finding cool projects (3:00)

Keown begins his talk by framing the exploration of low-resource devices through a personal anecdote: the acquisition of a peculiar, home-built dial-up modem from Vetco Electronics in Seattle for a mere $20. This "weird brown box," a relic from the 1970s, sat in his "junk drawer" for a year—a metaphor for the countless interesting, yet unexamined, devices that accumulate in many enthusiasts' collections. This experience sparked his interest in understanding the initial knowledge required to transform such dormant projects into something genuinely interesting.

The catalyst for digging deeper came a year later, when Keown attended the Low Resource Computing workshop at Dartmouth. The workshop's premise was a "cold start to society" scenario: if the internet collapsed, how would one establish communication and networking with only basic, low-resource devices? This challenge resonated with Keown's developer mindset, offering a chance to "refactor society technology exactly as simple as it needs to be and nothing more complex." Participants engaged in diverse projects, from Game Boy programming to LoRa mesh networking.

Keown's contribution to this "primitive network" was a dial-up backbone, connecting a CCTV camera to a recipient computer through a complex chain: CCTV IP camera -> iMac G4 -> switch -> modem -> PBX -> another modem -> recipient computer. The goal was to pull frames from the IP camera over this network. This setup, while eventually functional, went at a "blazing 15 seconds per frame" for a 2-bit per pixel PNG image (offering four shades of gray). The modem itself, a 50-year-old device, proved particularly challenging. It predated the AT command set, meaning it lacked a dialer and required a manual "answer" button press. Operating at a modest 600 baud, it highlighted the extreme constraints and unique historical context of early networking hardware. This experience underscored the effort required to make "junk drawer" tech useful and prompted Keown to ponder the concept of a "minimum viable modem," a device stripped down to its absolute essentials for data transfer.

Key Findings

▶ Watch: Exploring various low-resource device constraints (9:45)

Keown's talk systematically categorizes low-resource devices based on their primary constraints, drawing examples from his personal "junk drawer" and broader technological history. This taxonomy highlights how limitations fundamentally shape engineering decisions and user interaction:

1. Memory Constraints: Exemplified by the Game Boy, which possesses a mere 8 kilobytes of working memory. Keown emphasizes that "every byte is a decision," forcing developers to optimize relentlessly and work intimately with the hardware. This constraint often groups with others, such as power.
2. Storage Constraints: The Apple QuickTake 150, an early digital camera, can store a "whopping 16 images." This severe limitation directly influenced user behavior, forcing careful consideration of each shot, a stark contrast to modern digital photography.
3. Size Constraints: Keown showcases a tiny mechanical hard drive from an iPod, a "feat of engineering" to shrink spinning metal platters into a portable device. This constraint drives miniaturization efforts across various embedded systems.
4. Power Constraints: LoRa (Long Range) technology is highlighted for its ability to send data while "sipping power," making it ideal for applications like smart utility meters and agriculture sensors where power sources are scarce. Keown envisioned using LoRa for a "Twitch Plays Pokémon" setup with the CCTV camera and Game Boy.
5. Expressiveness/Instruction Count Constraints: This category explores the complexity of CPU instruction sets. While x86-64 boasts over 1,000 to 3,500 instructions, making it incredibly expressive but daunting, simpler architectures exist. AVR has around 120 instructions, Brainfuck has 8, and a one-instruction set computer (OISC) is theoretically Turing complete. Keown demonstrated his hand-built Brainfuck CPU using 7400 series logic gates, showcasing how extreme constraint (8 symbols) makes building a CPU from scratch "relatively doable."
6. Cost Constraints: The drive for affordability leads to devices like the ESP8266, an extremely cheap yet capable microcontroller. Keown also presents a physical crypto bill, essentially a smart card disguised as currency, containing cryptocurrency within a secure element—a fascinating example of a low-cost, specialized computing device.

The "mystery guest device" that ties many of these constraints together is the smart card. Keown reveals that there are an estimated 30 to 50 billion smart cards in the world today, with every credit card being a smart card. Astonishingly, many of these credit cards run Java, specifically a stripped-down version of Java 1.7. This pervasive, yet often unnoticed, technology becomes the primary focus of the talk's technical deep dive.

Technical Deep Dive

▶ Watch: Credit cards run Java: a surprising fact (18:00)

The revelation that billions of smart cards, including standard credit cards, run Java is a central point of Keown's technical exposition. He explains that a smart card fundamentally consists of a microprocessor, memory, and basic communication contact pads. A significant challenge for researchers is that these microprocessors are "often undocumented" and finding detailed datasheets or specifications is exceedingly rare. Furthermore, smart cards are severely constrained in memory, typically operating with only a few kilobytes of RAM.

The decision to run Java on these highly constrained devices stems from the mid-1990s, the "peak Java craze time." Visa and other payment networks sought to standardize on a common platform, leading to the adoption of a basic Java Virtual Machine (JVM) for smart cards. This is a stripped-down version of Java 1.7, notably lacking support for floats and optimized for minimal resource consumption.

A critical technical hurdle in Java Card development is memory allocation. By default, every object allocation in Java Card goes into persistent storage, which is "extremely slow" if frequent updates are required. To overcome this, the concept of transient arrays was introduced. These arrays are allocated directly into the card's volatile RAM, offering significantly faster read/write performance. Keown notes that few resources exist for deep dives into Java Card, mentioning the JCALGTest website as a valuable reference for profiling and differential analysis of various cards to infer CPU architectures.

Keown's personal journey into smart card development, aimed at pushing their limits, led him to create JCC, a C to Java Card bytecode compiler. His initial attempts to write Java for smart cards quickly revealed the cumbersome nature of manual memory management for performance-critical applications. The need for precise control over transient array allocations, combined with the desire to define structures, nested arrays, and constants within these memory regions, naturally evolved into the creation of a compiler.

JCC addresses several Java Card specificities:

• Data Type Conversion: It converts arrays of structures into structures of arrays, which aligns better with the native data types (bytes, shorts, and integers) and memory access patterns of Java Card.
• Signed-Only Types: Java Card lacks unsigned integer types. JCC helps manage the "very subtle bugs" that can arise when porting C code that relies on unsigned comparisons.
• Static Allocation: JCC enforces static allocation for all data, completely removing the need for dynamic memory allocation functions like malloc.
• No Recursion: To prevent stack overflows in the highly constrained environment, JCC disallows recursion.
• Feature Limitations: The compiler explicitly does not support floats, unsigned types (directly, as it converts them), and unions, reflecting the limitations of the target architecture.

Despite these restrictions, JCC provides the basic functionality necessary to port "workable C demo[s]" to Java Card. Keown emphasizes that JCC's primary goal is to make writing "performant, weird applications for smart cards" accessible, largely by leveraging transient arrays to maximize speed. The release of JCC on GitHub is intended to lower the barrier for others to explore this fascinating and constrained computing platform.

Demo / Proof of Concept

▶ Watch: Doom E1M1 rendering on a smart card (30:00)

Trey Keown's presentation culminates in a series of impressive live demonstrations, showcasing the unexpected capabilities of smart cards when pushed to their limits with optimized tooling like JCC. The demos illustrate the creative solutions required to render complex visuals and interactive experiences on devices with minimal resources.

1. 2048 on a Smart Card: Keown first demonstrates the popular puzzle game 2048 running entirely on a smart card. He clarifies that "everything you're seeing inside of the inner border is fully rendered on the card." The display is achieved by returning a 4 bits per pixel image from the card, which is then "blitted straight back" to the screen using a Python driver script. This operates on a request-response architecture: keystrokes are sent as requests, and the card returns the frame buffer as a response. Keown humorously notes that the RNG isn't hooked up yet, so it's the "same sequence every time," allowing him to become quite proficient.

1. Flappy Bird on a Smart Card: Next, Keown ports Flappy Bird, an interactive, time-sensitive game. To achieve a "serviceable" frame rate, the game is rendered at 1 bit per pixel (on or off), and the frame size is significantly constrained. He explains that while the simulator runs about 80 times faster than the physical smart card, the actual card manages roughly 20 frames per second. This demo highlights the trade-offs between visual fidelity, frame size, and interactivity when dealing with extreme performance limitations.

1. Pokémon on a Smart Card: Drawing a callback to his earlier "Twitch Plays Pokémon" dream, Keown reveals his "own smart card Pokémon." While not a full game, this demo shows a character moving within a tiled environment, proving that more complex, state-based interactions are feasible. The audience's applause acknowledges the ingenuity of running such a recognized franchise on such a tiny platform.

1. Doom E1M1 on a Smart Card: The most ambitious demonstration is a rendering of Doom's E1M1 level on the smart card. Keown admits to "so many hacks for this," including "trig is all wrong" and "division's an approximation." Despite these compromises, the game sometimes hits "two frames per second," which he proudly declares "an absolute win." This is particularly impressive given that smart cards lack floating-point units; Doom's original engine wisely used fixed-point integers instead of floating-point, making a port theoretically possible, albeit extremely challenging. He contrasts the live performance with the "full speed" simulator version, illustrating the potential with higher-performance smart cards.

1. Bad Apple on a Smart Card: The final demo is the internet meme Bad Apple, where the animated music video is rendered on the smart card. This showcases the ability to handle sequential frame playback, albeit at a very low resolution and frame rate, demonstrating the card's capacity for media display.

Keown reiterates that the ability to achieve "any reasonable speed" for these demos is entirely thanks to the "tooling around making sure that memory and allocations actually go to RAM instead of being persistent," referring directly to the crucial role of transient arrays and his JCC compiler in making C code workable on the Java Card platform.

Defensive Implications

▶ Watch: Dream: Game Boy with smart card CPU cartridge (40:00)

The detailed exploration of low-resource devices, particularly smart cards, by Trey Keown carries significant defensive implications for the cybersecurity community. The sheer ubiquity of these "little guys," from credit cards and identity badges to critical infrastructure components like smart utility meters and agricultural sensors, means they represent a vast and often neglected attack surface.

Firstly, the undocumented nature of many smart card microprocessors and the scarcity of public datasheets create a "security through obscurity" scenario. While this might deter casual attackers, it significantly hinders legitimate security research and auditing. Defenders need to recognize that this lack of transparency does not equate to security; rather, it makes discovering and mitigating vulnerabilities more challenging for everyone, including the vendors themselves.

Secondly, the prevalence of Java Card in financial and identity systems introduces a unique set of security considerations. While Java is generally considered a safer language than C/C++, the stripped-down Java 1.7 JVM on highly constrained hardware might have its own quirks and potential for subtle bugs. The default allocation to persistent storage, if not carefully managed with transient arrays, could expose timing side channels or lead to performance issues that could be exploited. Furthermore, the standardization on "global platform" means that vulnerabilities found in one type of smart card implementation could potentially affect a wide range of devices globally.

The discussion around "mutable memory" in the Q&A section highlights a practical security control challenge. In secure environments, mass storage devices are typically disallowed to prevent data exfiltration or malware introduction. However, smart card readers are often permitted (e.g., for ID badges). If a smart card can be made mutable or can be programmed to emulate a different device type (e.g., a mass storage device), it could bypass existing security controls, creating a covert channel for data transfer or code injection. While Keown's demos focus on benign applications, the underlying techniques for programming and interacting with these cards could be adapted for malicious purposes.

Defenders must therefore:

• Expand their threat models to include low-resource, embedded devices, recognizing that they are not immune to sophisticated attacks.
• Investigate the specific architectures and programming paradigms (e.g., Java Card, transient arrays) used in critical low-resource systems within their purview.
• Promote transparency and access to documentation for embedded systems where possible, to enable thorough security auditing.
• Implement robust secure development practices specifically tailored for constrained environments, focusing on memory safety, input validation, and secure boot processes.
• Consider the potential for unconventional attack vectors that leverage the unique characteristics of these devices, such as side-channel attacks based on timing or power consumption, which the JCALGTest community already explores.

Ultimately, Keown's work underscores that neglecting the "little guys" in security research leaves a significant blind spot. Understanding how to interact with, program, and push the boundaries of these devices is crucial for anticipating and defending against future threats.

Key Takeaways

• Explore the "Junk Drawer": Many overlooked, low-resource devices possess unique technical challenges and untapped potential for security research and innovation.
• Constraints Drive Innovation: Limitations in memory, storage, power, size, expressiveness, and cost force engineers to be creative and optimize, revealing fundamental computing principles.
• Smart Cards are Ubiquitous and Powerful: Billions of smart cards, including credit cards, run a stripped-down version of Java 1.7, representing a massive and often misunderstood computing platform.
• Leverage Specialized Tooling: Tools like JCC (a C to Java Card bytecode compiler) are essential for overcoming the unique programming challenges of constrained environments, especially for performance-critical applications using concepts like transient arrays.
• Low-Resource Devices are a Critical Attack Surface: The pervasive nature of these devices in payment systems, identity, and IoT demands increased security scrutiny and a deeper understanding of their underlying architectures.
• The Future of Embedded Hacking: The dream of a Game Boy where the CPU is on the cartridge itself (a smart card reader acting as the console) illustrates the vast potential for creative embedded systems design and security exploration.

About the Speaker(s)

Trey Keown is a Security Researcher at Crystal Peak Security, a firm that specializes in embedded device security. His work involves hacking around, discovering cool things, and developing tools for various embedded systems. Keown demonstrates a clear passion for understanding and manipulating constrained hardware, evident in his personal projects such as building a Brainfuck CPU by hand using 7400 series logic gates. He has prior experience in security research related to ATMs and enjoys exploring the intersection of physical and digital security in financial devices. His approach emphasizes hands-on experimentation and a deep dive into the fundamental workings of technology.