Embedded Device Concepts

My book defines attacks that are applicable to embedded devices.

One of the first questions I get is "What is embedded software?" As the book explains in more detail, the embedded software "space" starts with small micro control devices (FPGAs, ASIC, firmware) which may be found in things such as “smart” switches or other micro devices, then continues to larger control devices such as medical or "smart" mechanical subsystems, and finally ends up with very large smart systems controlling things such as factories, cars, airplanes, and space craft.

One key for me is the user interface (UI). Many users of embedded devices are unaware or only partial aware that they are using software (different from a PC where you a have a screen, a CPU, keyboard, etc.). When someone is driving a car, are they thinking “Gee I am running software to operate my brakes? When a person turns on a smart switch in a smart office or smart factory, is the person thinking software? When a doctor is using a medical device, is that doctor or are you worried about bugs in the software or system? The answers to these qestions are definitely "no" yet for all of these devices to work, the software must work too.
Often embedded software is doing some critical or important function which can impact human life, the world environment, or something else people expect to work. So one good way to identify embedded software is the lack of a UI or a limited UI which can "hide" the software from the user.

I view embedded software devices within a continuum of computing devices. The continuum starts with small devices that use an FPGA, or ASIC, or firmware. It continues on to smart devices that have "inputs" which look "PC like" and continues with devices such as smart phones. A sample continuum is offered below. Given how many devices are smart and embedded, you would need to put embedded devices where you see fit.

FPGA switch for home lighting -> factory line control device -> Medical pacemaker-> avionics controller -> Automobile Info/tainment systems -> Aircraft control system -> Robotics with man in the loop -> Smartphone........

Specific examples of embedded software include:

Avionics systems: planes, cars, rockets, military, etc.
Telecom: switch, routers, phones, cell devices, smart phones, tablets, etc.
Transportation: traffic control, railroad, trucking, etc.
Industrial control: lighting, machines, HVAC, nuclear/power, etc.
Medical: pacemaker, surgical devices, drug dispensers, robots, etc.
Home and office systems: electric controls, entertainment (cable boxes), TVs, etc.
Industry/factory: robots, machine controls, tooling, etc

However, like the mobile-smart phone space, the nature of what is embedded is not always clear and the definition is changing. Embedded devices are getting GUIs. Embedded devices are getting network communications. So while there are unique attacks defined in my book for the embedded domain, more and more the embedded software tester also needs to consider attacks applicable to the IT/PC and Web world (see books by James Whittaker).

Applicable attacks for Embedded Systems from my book : (Book attacks 1, 2,3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 30, 32, or see the book's Appendix E, which lists more details by embedded sub-domain)

Mobile-Smart Phone Blog

Wikipedia defines embedded software as:

"Embedded software is computer software, written to control machines or devices that are not typically thought of as computers. It is typically specialized for the particular hardware that it runs on and has time and memory constraints. This term is sometimes used interchangeably with firmware, although firmware can also be applied to ROM-based code on a computer, on top of which the OS runs, whereas embedded software is typically the only software on the device in question.

A precise and stable characteristic feature is that no or not all functions of embedded software are initiated/controlled via a human interface, but through machine-interfaces instead.

Manufacturers 'build in' embedded software in the electronics in cars, telephones, modems, robots, appliances, toys, security systems, pacemakers, televisions and set-top boxes, and digital watches, for example. This software can be very simple, such as lighting controls running on an 8-bit microprocessor and a few kilobytes of memory, or can become very sophisticated in applications such as airplanes, missiles, and process control systems.^"

Expanding on this Wikipedia definition, embedded software depends on unique hardware to solve a specialized problem interacting with and/or controlling the “real world." The definitions are different than what is broadly found in the software industry, which produces software functions for largely generic PC or workstation platforms dedicated to having users perform specific tasks in the IT domain.

Embedded software comes with all of the problems of IT/PC software, plus adds the following:

software and hardware development cycles done in parallel, where aspects of the hardware may be unknown to the software development effort;
hardware problems which are often fixed with software late in the project;
limited or specialized user interfaces;
small amounts of dense complex functions often in the control theory or safety/hazard domains;
(a big one) very tight real-time performance issues (often in mili- or micro-second ranges); and
highly limited resources (memory, processor speed, band width, etc).

Finally, embedded software usually has significant hardware interface issues and concerns. These concerns can include but are not limited to: initialization, hardware signal noise, power-up, power-down, timers, sensors, interrupts, etc.