Beyond the Application: Protocol, Device, and Physical Context
Claude-Red’s wireless, mobile, and IoT skills reveal a boundary that application-focused thinking can miss: the system under test may have a body, a radio, a firmware image, or a physical process. This chapter focuses on how those conditions change context selection and validation. The reader will see why hardware capability, authentication mode, protocol negotiation, device state, and potential operational impact must be established before a skill’s guidance is treated as relevant.
A security boundary with a physical body
A web application usually presents a request interface. A wireless or embedded system presents a mixture of interfaces: radio signals, authentication exchanges, device services, firmware, hardware buses, and sometimes a physical process that can be affected by an incorrect action. A mobile application sits between those worlds. It runs on a device with local storage, platform permissions, sensors, operating-system controls, and network connections. The correct security question cannot be separated from the conditions under which the system exists.
Claude-Red’s category map places wireless, mobile, and IoT/embedded skills beside web, cloud, identity, and exploit research. That organization says something important about the project’s unit of context. A skill is not limited to a software feature or a programming language. It describes a boundary where an authorized assessor may need a distinct vocabulary, observation method, and safety model.
The wireless skill makes this concrete from its first step. It asks the assessor to choose an adapter with appropriate monitoring and transmission capabilities and to account for the relevant band and physical layer. That is not a tool-shopping detail. It is an initial condition. If the observation hardware cannot see the target protocol or cannot represent the required state, later conclusions are about the test setup rather than the target.
The same principle appears in mobile and embedded work. A mobile assessment may depend on the operating system, application packaging, local storage, certificate behavior, and whether a device is rooted or otherwise instrumentable. An IoT assessment may depend on access to a board, firmware acquisition, a bootloader, a hardware interface, a real-time operating system, or an industrial protocol. A general security skill can remind the reader to ask about those conditions, but it cannot infer them from the product name.
Passive discovery comes before active choice
The wireless workflow begins with passive airspace mapping and explicitly warns against deauthentication before the topology is understood. The reason is both safety and interpretation. An active action can disconnect clients, alter association behavior, create noise in monitoring systems, or change which devices are visible. Without a baseline, a later observation may be impossible to distinguish from a condition the test itself created.
Passive discovery answers foundational questions. Which networks or devices are present? Which identifiers, channels, and signal characteristics are visible? What authentication and protection modes are advertised? Which clients appear associated? What features suggest that a newer protocol or protection mechanism is in use? These observations narrow the possible test branches without forcing a transition in the environment.
This is the physical equivalent of mapping an API before testing an authorization boundary. The reader first identifies the interface and its state, then chooses a validation method that fits.