[openwrt/openwrt.git] / docs / adding.tex
1 Linux is now one of the most widespread operating system for embedded devices due
2 to its openess as well as the wide variety of platforms it can run on. Many
3 manufacturer actually use it in firmware you can find on many devices: DVB-T
4 decoders, routers, print servers, DVD players ... Most of the time the stock
5 firmware is not really open to the consumer, even if it uses open source software.
7 You might be interested in running a Linux based firmware for your router for
8 various reasons: extending the use of a network protocol (such as IPv6), having
9 new features, new piece of software inside, or for security reasons. A fully
10 open-source firmware is de-facto needed for such applications, since you want to
11 be free to use this or that version of a particular reason, be able to correct a
12 particular bug. Few manufacturers do ship their routers with a Sample Development Kit,
13 that would allow you to create your own and custom firmware and most of the time,
14 when they do, you will most likely not be able to complete the firmware creation process.
16 This is one of the reasons why OpenWrt and other firmware exists: providing a
17 version independent, and tools independent firmware, that can be run on various
18 platforms, known to be running Linux originaly.
20 \subsection{Which Operating System does this device run?}
22 There is a lot of methods to ensure your device is running Linux. Some of them do
23 need your router to be unscrewed and open, some can be done by probing the device
24 using its external network interfaces.
26 \subsubsection{Operating System fingerprinting and port scanning}
28 A large bunch of tools over the Internet exists in order to let you do OS
29 fingerprinting, we will show here an example using \textbf{nmap}:
31 \begin{Verbatim}
32 nmap -P0 -O <IP address>
33 Not shown: 1694 closed ports
35 631/tcp open ipp
36 1033/tcp open netinfo
37 6000/tcp open X11
38 Device type: general purpose
39 Running: Apple Mac OS X 10.4.X
40 OS details: Apple Mac OS X 10.4.8 (Tiger)
41 \end{Verbatim}
43 nmap is able to report whether your device uses a Linux TCP/IP stack, and if so,
44 will show you which Linux kernel version is probably runs. This report is quite
45 reliable and it can make the distinction between BSD and Linux TCP/IP stacks and others.
47 Using the same tool, you can also do port scanning and service version discovery.
48 For instance, the following command will report which IP-based services are running
49 on the device, and which version of the service is being used:
51 \begin{verbatim}
52 nmap -P0 -sV <IP address>
54 \end{verbatim}
56 The web server version, if identified, can be determining in knowing the Operating
57 System. For instance, the \textbf{BOA} web server is typical from devices running
58 an open-source Unix or Unix-like.
60 \subsubsection{Wireless Communications Fingerprinting}
62 Although this method is not really known and widespread, using a wireless scanner
63 to discover which OS your router or Access Point run can be used. We do not have
64 a clear example of how this could be achieved, but you will have to monitor raw
65 802.11 frames and compare them to a very similar device running a Linux based firmware.
67 \subsubsection{Web server security exploits}
69 The Linksys WRT54G was originally hacked by using a "ping bug" discovered in the
70 web interface. This tip has not been fixed for months by Linksys, allowing people
71 to enable the "boot\_wait" helper process via the web interface. Many web servers
72 used in firmwares are open source web server, thus allowing the code to be audited
73 to find an exploit. Once you know the web server version that runs on your device,
74 by using \textbf{nmap -sV} or so, you might be interested in using exploits to reach
75 shell access on your device.
77 \subsubsection{Native Telnet/SSH access}
79 Some firmwares might have restricted or unrestricted Telnet/SSH access, if so,
80 try to log in with the web interface login/password and see if you can type in
81 some commands. This is actually the case for some Broadcom BCM963xx based firmwares
82 such as the one in Neuf/Cegetel ISP routers, Club-Internet ISP CI-Box and many
83 others. Some commands, like \textbf{cat} might be left here and be used to
84 determine the Linux kernel version.
86 \subsubsection{Analysing a binary firmware image}
88 You are very likely to find a firmware binary image on the manufacturer website,
89 even if your device runs a proprietary operating system. If so, you can download
90 it and use an hexadecimal editor to find printable words such as \textbf{vmlinux},
91 \textbf{linux}, \textbf{ramdisk}, \textbf{mtd} and others.
93 Some Unix tools like \textbf{hexdump} or \textbf{strings} can be used to analyse
94 the firmware. Below there is an example with a binary firmware found other the Internet:
96 \begin{verbatim}
97 hexdump -C <binary image.extension> | less (more)
98 00000000 46 49 52 45 32 2e 35 2e 30 00 00 00 00 00 00 00 |FIRE2.5.0.......|
99 00000010 00 00 00 00 31 2e 30 2e 30 00 00 00 00 00 00 00 |....1.0.0.......|
100 00000020 00 00 00 00 00 00 00 38 00 43 36 29 00 0a e6 dc |.......8.C6)..??|
101 00000030 54 49 44 45 92 89 54 66 1f 8b 08 08 f8 10 68 42 |TIDE..Tf....?.hB|
102 00000040 02 03 72 61 6d 64 69 73 6b 00 ec 7d 09 bc d5 d3 |..ramdisk.?}.???|
103 00000050 da ff f3 9b f7 39 7b ef 73 f6 19 3b 53 67 ea 44 |???.?9{?s?.;Sg?D|
104 \end{verbatim}
106 Scroll over the firmware to find printable words that can be significant.
108 \subsubsection{Amount of flash memory}
110 Linux can hardly fit in a 2MB flash device, once you have open the device and
111 located the flash chip, try to find other the Internet its characteristics. If
112 your flash chip is a 2MB or less device, your device is most likely to run a
113 proprietary OS such as WindRiver VxWorks, or a custom manufacturer OS like Zyxel ZynOS.
115 OpenWrt does not currently run on devices which have equal or less than 2MB of
116 flash memory. This limitation will probably not be worked around since those
117 devices are most of the time micro routers, or Wireless Access Points, which are
118 not the main OpenWrt target.
120 \subsubsection{Pluging a serial port}
122 By using a serial port, you may reach the console that is being shown by the device
123 for debugging or flashing purposes. By analysing the output of this device, you can
124 easily notice if the device uses a Linux kenrel or something different.
126 \subsection{Finding and using the manufacturer SDK}
128 Once you are sure your device run a Linux based firmware, you will be able to start
129 hacking on it. If the manufacturer respect the GPL, it will have release with the
130 device, a Sample Development Kit.
132 \subsubsection{GPL violations}
134 Some manufacturers do release a Linux based binary firmware, with no sources at all.
135 The first step before doing anything is to read the license coming with your device,
136 then write them about this lack of Open Source code. If the manufacturer answers
137 you they do not have to release a SDK containing Open Source software, then we
138 recommend you get in touch with the gpl-violations.org community.
140 You will find below a sample letter that can be sent to the manufacturer:
142 \begin{verse}
143 Miss, Mister,
145 I am using a <device name>, and I cannot find neither on your website nor on the
146 CD-ROM the open source software used to build or modify the firmware.
148 In conformance to the GPL license, you have to release the following sources:
150 - complete toolchain that made the kernel and applications be compiled (gcc, binutils, libc)
151 - tools to build a custom firmware (mksquashfs, mkcramfs ...)
152 - kernel sources with patches to make it run on this specific hardware, this does not include binary drivers
154 Thank you very much in advance for your answer.
156 Best regards, <your name>
157 \end{verse}
159 \subsubsection{Using the SDK}
161 Once the SDK is available, you are most likely not to be able to build a complete
162 or functional firmware using it, but parts of it, like only the kernel, or only
163 the root filesystem. Most manufacturers do not really care releasing a tool that
164 do work every time you uncompress and use it.
166 You should anyway be able to use the following components:
168 \begin{itemize}
169 \item kernel sources with more or less functional patches for your hardware
170 \item binary drivers linked or to be linked with the shipped kernel version
171 \item packages of the toolchain used to compile the whole firmware: gcc, binutils, libc or uClibc
172 \item binary tools to create a valid firmware image
173 \end{itemize}
175 Your work is now divided into the following tasks:
177 \begin{itemize}
178 \item create a clean patch of the hardware specific part of the linux kernel
179 \item spot potential kernel GPL violations especially on firewall and USB stack stuff
180 \item make the binary drivers work, until there are open source drivers
181 \item use standard a GNU toolchain to make working executables
182 \item understand and write open source tools to generate a valid firmware image
183 \end{itemize}
185 \subsubsection{Creating a hardware specific kernel patch}
187 Most of the time, the kernel source that comes along with the SDK is not really
188 clean, and is not a standard Linux version, it also has architecture specific
189 fixes backported from the \textbf{CVS} or the \textbf{git} repository of the
190 kernel development trees. Anyway, some parts can be easily isolated and used as
191 a good start to make a vanilla kernel work your hardware.
193 Some directories are very likely to have local modifications needed to make your
194 hardware be recognized and used under Linux. First of all, you need to find out
195 the linux kernel version that is used by your hardware, this can be found by
196 editing the \textbf{linux/Makefile} file.
198 \begin{verbatim}
199 head -5 linux-2.x.x/Makefile
200 VERSION = 2
202 SUBLEVEL = y
204 NAME=Avast! A bilge rat!
205 \end{verbatim}
207 So now, you know that you have to download a standard kernel tarball at
208 \textbf{kernel.org} that matches the version being used by your hardware.
210 Then you can create a \textbf{diff} file between the two trees, especially for the
211 following directories:
213 \begin{verbatim}
214 diff -urN linux-2.x.x/arch/<sub architecture> linux-2.x.x-modified/arch/<sub architecture> > 01-architecture.patch
215 diff -urN linux-2.x.x/include/ linux-2.x.x-modified/include > 02-includes.patch
216 diff -urN linux-2.x.x/drivers/ linux-2.x.x-modified/drivers > 03-drivers.patch
217 \end{verbatim}
219 This will constitute a basic set of three patches that are very likely to contain
220 any needed modifications that has been made to the stock Linux kernel to run on
221 your specific device. Of course, the content produced by the \textbf{diff -urN}
222 may not always be relevant, so that you have to clean up those patches to only
223 let the "must have" code into them.
225 The fist patch will contain all the code that is needed by the board to be
226 initialized at startup, as well as processor detection and other boot time
227 specific fixes.
229 The second patch will contain all useful definitions for that board: adresses,
230 kernel granularity, redifinitions, processor family and features ...
232 The third patch may contain drivers for: serial console, ethernet NIC, wireless
233 NIC, USB NIC ... Most of the time this patch contains nothing else than "glue"
234 code that has been added to make the binary driver work with the Linux kernel.
235 This code might not be useful if you plan on writing from scratch drivers for
236 this hardware.
238 \subsubsection{Making binary drivers work}
240 As we have explained before, manufacturers do release binary drivers in their GPL
241 tarball. When those drivers are statically linked into the kernel, they become GPL
242 as well, fortunately or unfortunately, most of the drivers are not statically linked.
243 This anyway lets you a chance to dynamically link the driver with the current kernel
244 version, and try to make them work together.
246 This is one of the most tricky and grey part of the fully open source projects.
247 Some drivers require few modifications to be working with your custom kernel,
248 because they worked with an earlier kernel, and few modifications have been made
249 to the kernel in-between those versions. This is for instance the case with the
250 binary driver of the Broadcom BCM43xx Wireless Chipsets, where only few differences
251 were made to the network interface structures.
253 Some general principles can be applied no matter which kernel version is used in
254 order to make binary drivers work with your custom kernel:
256 \begin{itemize}
257 \item turn on kernel debugging features such as:
258 \begin{itemize}
265 \end{itemize}
266 \item link binary drivers when possible to the current kernel version
267 \item try to load those binary drivers
268 \item catch the lockups and understand them
269 \end{itemize}
271 Most of the time, loading binary drivers will fail, and generate a kernel oops.
272 You can know the last symbol the binary drivers attempted to use, and see in the
273 kernel headers file, if you do not have to move some structures field before or
274 after that symbol in order to keep compatibily with both the binary driver and
275 the stock kernel drivers.
277 \subsubsection{Understanding the firmware format}
279 You might want to understand the firmware format, even if you are not yet capable
280 of running a custom firmware on your device, because this is sometimes a blocking
281 part of the flashing process.
283 A firmare format is most of the time composed of the following fields:
285 \begin{itemize}
286 \item header, containing a firmare version and additional fields: Vendor, Hardware version ...
287 \item CRC32 checksum on either the whole file or just part of it
288 \item Binary or compressed kernel image
289 \item Binary or compressed root filesystem image
290 \item potential garbage
291 \end{itemize}
293 Once you have figured out how the firmware format is partitioned, you will have
294 to write your own tool that produces valid firmare binaries. One thing to be very
295 careful here is the endianness of either the machine that produces the binary
296 firmware and the device that will be flashed using this binary firmware.
298 \subsubsection{Writing a flash map driver}
300 The flash map driver has an important role in making your custom firmware work
301 because it is responsible of mapping the correct flash regions and associated
302 rights to specific parts of the system such as: bootloader, kernel, user filesystem.
304 Writing your own flash map driver is not really a hard task once you know how your
305 firmware image and flash is structured. You will find below a commented example
306 that covers the case of the device where the bootloader can pass to the kernel its partition plan.
308 First of all, you need to make your flash map driver be visible in the kernel
309 configuration options, this can be done by editing the file
310 \textbf{linux/drivers/mtd/maps/Kconfig}:
312 \begin{verbatim}
314 tristate "Device Flash device"
315 depends on ARCHITECTURE && DEVICE
316 help
317 Flash memory access on DEVICE boards. Currently only works with
318 Bootloader Foo and Bootloader Bar.
319 \end{verbatim}
321 Then add your source file to the \textbf{linux/drivers/mtd/maps/Makefile}, so
322 that it will be compiled along with the kernel.
324 \begin{verbatim}
325 obj-\$(CONFIG_MTD_DEVICE_FLASH) += device-flash.o
326 \end{verbatim}
328 You can then write the kernel driver itself, by creating a
329 \textbf{linux/drivers/mtd/maps/device-flash.c} C source file.
331 \begin{verbatim}
332 // Includes that are required for the flash map driver to know of the prototypes:
333 #include <asm/io.h>
334 #include <linux/init.h>
335 #include <linux/kernel.h>
336 #include <linux/mtd/map.h>
337 #include <linux/mtd/mtd.h>
338 #include <linux/mtd/partitions.h>
339 #include <linux/vmalloc.h>
341 // Put some flash map definitions here:
342 #define WINDOW_ADDR 0x1FC00000 /* Real address of the flash */
343 #define WINDOW_SIZE 0x400000 /* Size of flash */
344 #define BUSWIDTH 2 /* Buswidth */
346 static void __exit device_mtd_cleanup(void);
348 static struct mtd_info *device_mtd_info;
350 static struct map_info devicd_map = {
351 .name = "device",
352 .size = WINDOW_SIZE,
353 .bankwidth = BUSWIDTH,
354 .phys = WINDOW_ADDR,
355 };
357 static int __init device_mtd_init(void)
358 {
359 // Display that we found a flash map device
360 printk("device: 0x\%08x at 0x\%08x\n", WINDOW_SIZE, WINDOW_ADDR);
361 // Remap the device address to a kernel address
362 device_map.virt = ioremap(WINDOW_ADDR, WINDOW_SIZE);
364 // If impossible to remap, exit with the EIO error
365 if (!device_map.virt) {
366 printk("device: Failed to ioremap\n");
367 return -EIO;
368 }
370 // Initlialise the device map
371 simple_map_init(&device_map);
373 /* MTD informations are closely linked to the flash map device
374 you might also use "jedec_probe" "amd_probe" or "intel_probe" */
375 device_mtd_info = do_map_probe("cfi_probe", &device_map);
377 if (device_mtd_info) {
378 device_mtd_info->owner = THIS_MODULE;
380 int parsed_nr_parts = 0;
382 // We try here to use the partition schema provided by the bootloader specific code
383 if (parsed_nr_parts == 0) {
384 int ret = parse_bootloader_partitions(device_mtd_info, &parsed_parts, 0);
385 if (ret > 0) {
386 part_type = "BootLoader";
387 parsed_nr_parts = ret;
388 }
389 }
391 add_mtd_partitions(devicd_mtd_info, parsed_parts, parsed_nr_parts);
393 return 0;
394 }
395 iounmap(device_map.virt);
397 return -ENXIO;
398 }
400 // This function will make the driver clean up the MTD device mapping
401 static void __exit device_mtd_cleanup(void)
402 {
403 // If we found a MTD device before
404 if (device_mtd_info) {
405 // Delete every partitions
406 del_mtd_partitions(device_mtd_info);
407 // Delete the associated map
408 map_destroy(device_mtd_info);
409 }
411 // If the virtual address is already in use
412 if (device_map.virt) {
413 // Unmap the physical address to a kernel space address
414 iounmap(device_map.virt);
415 // Reset the structure field
416 device_map.virt = 0;
417 }
418 }
421 // Macros that indicate which function is called on loading/unloading the module
422 module_init(device_mtd_init);
423 module_exit(device_mtd_cleanup);
426 // Macros defining licence and author, parameters can be defined here too.
428 MODULE_AUTHOR("Me, myself and I <memyselfandi@domain.tld");
429 \end{verbatim}