The 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 largesmart 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.
embedded software is doing some critical or important function which
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........
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 the
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)
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 usually has significant hardware interface
issues and concerns. These concerns can include but are not limited to: initialization, hardware
noise, power-up, power-down, timers, sensors, interrupts, etc.