Apress - Smart Home Automation with Linux (2010)- P14 ppt

CHAPTER 1 ■ APPLIANCE CONTROL 48 In this way, you can use an IR remote to interact with other arbitrary applications, including media players on other machines. Additionally, you can adopt the same ideas as Cosmic (mentioned earlier and covered in Chapter 7) to develop a state-based control mechanism using very cheap IR transmitters. Conclusion Each device in your home should have the ability to be controlled remotely, either through the power lines (with X10 or C-Bus), with an Ethernet socket, or through basic Infrared. This is the first step of a two-stage process. The second is when you have a computer able to issue control messages to those devices. At that point, they can be used seamlessly from anywhere in the world. When the device doesn’t support such functionality, you have to hack it. And that’s where the geeky fun begins! C H A P T E R 2 ■ ■ ■ 49 Appliance Hacking Converting Existing Technology There are three classical forms of hacking: software, hardware, and wetware (also known as social engineering). More recently, firmware hacking has become prominent because low-cost hardware utilizing embedded Linux has opened the door to software hackers unable to build hardware. It is hardware hacking, and its associated software, that I will cover in this chapter. Software Hacks For most developers, software is an easier hack, since the chance of breaking something irrevocably is much reduced compared to hacking hardware. In fact, when Steve Wozniak and Steve Jobs were building machines at the Homebrew Computer Club, they reasoned that for every one hacker who was interested in hardware, there were 100 who were keen on software, so they focused on the software capabilities of the Apple computer. Linksys NSLU2 This device, also known as “the Slug,” is a small, embedded Linux device intended to function as a network addressable storage (NAS) device. You plug in power, a network cable, and (up to) two USB hard drives, and you’re able to retrieve the data stored on it from any machine on the same network subnet using the Samba protocol. The machine itself is silent, powered by an Intel XScale IXP420, and incorporates 32MB of SDRAM and 8MB of flash memory where the software is stored. Its low price point and openness of firmware makes it attractive to hackers wanting to add or change the software on the machine. The machine was officially discontinued in 2008 but is still available in various stores and online. In its intended form, the Slug is a suitable machine when only a file server is needed, either to be a remote backup for desktop work (perhaps located under the stairs or in a loft) or to provide music to media players around the house. By changing its firmware, however, it can become the following: • Web server (Apache, PHP, Perl, and Python are all supported) • Mail server CHAPTER 2 ■ APPLIANCE HACKING 50 • Printer server (the cost of a Slug can be less than the difference between a USB printer and its networked equivalent) • Media server (shared through Squeezebox Server, iTunes, or just Samba) Before any software changes take place, you must first install an unrestricted version of Linux into the firmware of the device, which takes place through its built-in web interface. There are two main variations here: Unslung (which uses Optware packages) and SlugOS (formally called OpenSlug) based around OpenEmbedded. Unslung For basic improvements and a minimal of fuss, Unslung (www.nslu2-linux.org/wiki/Unslung/HomePage) is the preferred option because it installs over the top of the existing firmware and appears very similar to the end user, since it is based on the original Linksys code. This firmware provides extra functionality such as the ability to use FAT-formatted disks, which is necessary if you want to use an existing hard drive, since any disk used in the Slug needs to be specially formatted (to ext3) before use. It is also possible to install extra software packages through Optware using commands like the following: ipkg install apache However, you need to be careful since they are installed to the internal flash memory, which can run out very quickly and therefore lead to an unbootable device. To prevent this, you need to move the operating system onto either one of the external drives (either a USB memory stick or an entire hard drive, depending on the scope and size of your intended additions) in a process known as “unslinging your Slug.” Alternatively, you can perform a hardware hack to increase the memory. Several hundred packages are available for an unslung Slug, including the following: • BitTorrent clients • Streamers for Xbox Media Server • Apache web server • Asterisk VoIP • CUPS • Git • MySQL • SSH As you can see, most major packages are available, making this a very low-power machine, capable of providing most home tasks. However, they are all limited by the 2.4 kernel, so for more exotic hardware (like Bluetooth), you will need to adopt SlugOS. CHAPTER 2 ■ APPLIANCE HACKING 51 SlugOS SlugOS is a much larger endeavor and treats the Slug like any other piece of hardware, with a base operating system and separate packages for the main functionality, fitting in with the traditional Unix ideology of “do one thing and do it well.” This also removes the Slug-specific functionality such as the web-based configuration tool and basic services like Samba that you will consequently have to explicitly install. If you are using the Slug as the basis for a much larger home automation server, then this provides greater scope in the upgrade path, because it gives you access to the many thousands of packages provided by the OpenEmbedded project on which SlugOS is based. But doing so requires that you devote some, or all, of one of your connected hard drives to the operating system, which is a process that requires you to install a small system into the flash memory and then bootstrap the operating system onto the hard drive. In doing so, SlugOS permits the use of a 2.6-based kernel, as well as RAID and NFS functionality. When using an external USB drive to hold the operating system, always use a hard drive (as opposed to a memory stick). This is because some applications (such as MySQL) create a lot of memory writes to the swap file, and since flash memory becomes unusable after about 100,000 writes, this can happen sooner rather than later. You could, alternatively, assign the swap file to a second (hard) drive, allowing the operating system to boot and run from a read-only memory stick. Developing on the Slug To write your own software for the Slug, you should start with SlugOS because this gives you access to the standard development tools, which run on the device allowing the code to be written, compiled, and tested on the Slug. This is known as native development. First you need to run the following command, along with the other standard build packages (all detailed at www.nslu2- linux.org/wiki/HowTo/SlugOSNativeCompileEnvironment), before developing your code as normal: ipkg install slugos-native Without a screen, however, you will not be able to use GUI debuggers such as kdbg, which can be a scary downgrade for some. It is perfectly possible to run the machine headless, however, since you can connect remotely through ssh or telnet. This is preferable since the speed of the machine makes a GUI approach impractical for large applications. You would more likely write and test your application for your desktop machine and then, when it’s ready, cross-compile for the Slug. Cross compilation is a process whereby a compiler running on machine A is able to produce code suitable for machine B. To do this, you need a new set of compilers, tools, headers, and libraries (known together as the toolchain) that are built purposely for the other architecture. These are stored separate from your existing development files since they would otherwise conflict with those running your machine. The compilation process then occurs as normal (through either make or a variant of gcc, such as armeb-linux-gnu-gcc) to produce a suitable executable file, or elf in Linux parlance. The best introduction for the installation of these tools is at www.nslu2- linux.org/wiki/DebianSlug/CrossCompiling. Note that if you’re using only existing packages, compilation tools are not necessary in any form, and you can rely solely on the prebuilt packages. CHAPTER 2 ■ APPLIANCE HACKING 52 Hacking Game Consoles Game consoles are great for playing games. Old game console are great for playing old games—and hacking into Linux machines! As the previous generation of machines becomes cheap and technologically obsolete, old game consoles provide a good embedded platform for media players, web servers, control units, and the like. In this section, you will learn primarily at how these machines can be bent to your will, rather than specific uses for them. It is not smooth sailing, alas, because the manufacturers do not make the compilers or development environments available to anyone outside the computer games industry, and even then it is only with strict nondisclosure agreements (NDAs). 1 Although this should be enough to satisfy an overzealous legal department, they then build in security measures to make it difficult to run home-brew code on them by encrypting the disc format, BIOS, or executable. This in itself makes it an interesting problem for hackers. And since most manufacturers lose money on the console (knowing they’ll recoup it on the games), the subversive hackers enjoy this process even more. Despite the ever-decreasing circles of cost, it is not worth buying a new console for the sole purpose of hacking it into a Linux machine, but charity shops and online auctions can provide the hacker with the previous generation of hardware at a cost that makes the time and geek-cred worthwhile. With all technological challenges, however, the interest of those leading these console-hacking projects tends to wane as newer and more powerful machines become available or as the time benefit outweighs the cost of alternative equipment. Therefore, it is likely that some (or all!) of these projects might have fallen out of favor by the time you read this, as the Xbox 360 becomes old hat and the PlayStation 4 is the current console du jour. Sega Dreamcast The Dreamcast was a game console released in 1998 in the wake of the ill-fated Sega Saturn. It was the winner of an internal competition in Sega between two teams of engineers, led by IBM researcher Tatsuo Yamamoto and Sega hardware engineer Hideki Sato. The resulting console featured elements from both designs and was based around a 200MHz Hitachi SH4 RISC processor and the PowerVR2 graphics chip from VideoLogic, which is fast enough for video playback. It also featured an optical GD-ROM drive, which supported a standard CD-ROM partition (on which the OS was included), as well as a proprietary format section for the game. The console also marked Microsoft’s first exploration into the hardware arena by combining the Windows CE OS with its DirectX technology. The console also included a visual memory unit (VMU), which in addition to being a basic memory cartridge also featured an 8-bit process, 48 ×32 pixel LCD screen, D-pad, and four basic buttons. It was intended to be used as an auxiliary play device, rather than a handheld console in itself, and needed to be plugged into a controller in order to function. It was a good idea (and one reused by Sony years later with its PocketStation device, which also featured IR control), but it was not powerful enough for any significant work, compared to the equivalent technology at that time. Sega was also ahead of the curve by providing peripherals for the Dreamcast such as a mouse, keyboard, and Ethernet (known colloquially as a broadband adapter, or BBA). The latter two are considered essential for the installation and use of Linux. 1 An NDA is a legal document formed by companies to prevent you from talking about their technology or ideas with anyone else. . would otherwise conflict with those running your machine. The compilation process then occurs as normal (through either make or a variant of gcc, such as armeb -linux- gnu-gcc) to produce a suitable. along with the other standard build packages (all detailed at www.nslu 2- linux. org/wiki/HowTo/SlugOSNativeCompileEnvironment), before developing your code as normal: ipkg install slugos-native. OpenEmbedded. Unslung For basic improvements and a minimal of fuss, Unslung (www.nslu2 -linux. org/wiki/Unslung/HomePage) is the preferred option because it installs over the top of the existing