Verify an ISO and make boot media¶
Exercise verify-an-iso-boot-media-annex.pdf · PDF
You download an operating system. The file has the right name. It is almost exactly the right size. It even installs and works perfectly. And somebody else has been inside your PC since the first boot.
That really happened, to thousands of people, in one weekend. Your installation plan names an ISO file — so before you install anything, three checks: is the file the real one, is it written as a medium the PC can start from, and is the machine told to start from it?
What you will learn
- Explain what a checksum (hash) is: a short fingerprint of a file
- Compute the SHA-256 of an ISO with
sha256sumand compare it with the maker's - Show that changing a single byte changes the whole fingerprint
- Describe how an ISO becomes a bootable USB stick — and why the wrong device name destroys data
- Change the boot order of a machine and explain the error when nothing bootable is found
- Why dragging the ISO onto a USB stick does not make it bootable
The download that let attackers in¶
20 February 2016, a Saturday. Someone breaks into the website of Linux Mint, one of the most downloaded Linux distributions, and changes one link. The download button for Linux Mint 17.3 Cinnamon now points to a server in Bulgaria.
The ISO there is a complete, working Mint — with a backdoor added: a hidden program that lets the attackers into every PC where it is installed. Everyone who downloaded that edition that day got it. The Mint team found out and fixed the site the next day. Nobody could have seen the difference by looking at the file.
The file had the right name and almost the right size. How could you have known?
A fingerprint for a file¶
Fingerprints (we keep it all page)
Two people can have the same name, the same height and the same haircut. Their fingerprints are still different. A checksum is a fingerprint for a file: the name and size can be faked, the fingerprint cannot.
A hash function reads a whole file and gives back a short number of fixed size: its checksum, or hash — the file's fingerprint.
SHA-256 is the hash function you will use. It always gives 256 bits, written as 64 hexadecimal characters (from the Binary page: 4 bits per hex digit, and 64 × 4 = 256). Whether the file is 6 bytes or 4 GB, the fingerprint is always 64 characters.
It has three properties that make it useful:
| Property | What it means |
|---|---|
| Same file → same fingerprint | Always, on any computer, in any year |
| One bit changed → a completely different fingerprint | Not "a bit different": nothing in common |
| You cannot forge it | In practice nobody can build a different file with a chosen fingerprint |
See the second property with your own eyes. One capital letter:
5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03 -
66a045b452102c59d840ec097d59d9467e13a3f34f6494e539ffd32c1bb35f18 -
The - at the end means "the text came from the pipe, not from a file". Compare the two lines: nothing in common.
The method is simple: the maker publishes the fingerprint, you compute yours, and they match — or they do not.
flowchart LR
MAKER["<b>Debian</b><br>publishes SHA256SUMS:<br>the real fingerprints"] --> CMP{"<b>Same 64<br>characters?</b>"}
ISO["<b>Your download</b><br>debian-...-netinst.iso"] -->|"sha256sum"| MINE["<b>Your fingerprint</b>"] --> CMP
CMP -->|"yes"| OK["OK: identical copy,<br>go ahead"]
CMP -->|"no"| BAD["FAILED: damaged or forged,<br>download again"]Careful: a checksum does not repair or protect anything
It only tells you whether your copy is identical to the maker's. If it is not, the file stays broken — you download it again.
Verify the ISO¶
On the class server — the host of your VMs since Your first VM — /srv/isos/ holds the Debian netinst image and the file SHA256SUMS, both downloaded from the same Debian folder on the same day. Open a terminal on your PC (Ctrl+Alt+T), log in to the server with the user and password from today's slip, and follow the Exercise sheet. (cd means "go into this folder".)
The prompt changes to <user>@si: you are typing on the server now. The sha256sum line takes a few seconds: it reads all 756 MB. You get one long line of 64 letters and digits, followed by the file name. Now look at the maker's list:
One line per image Debian publishes. Find yours and compare by eye: do the first 8 and the last 4 characters match? Then let the computer do the full comparison:
-c means "check against this list"; --ignore-missing means "do not complain about the images I did not download". On a system set to Spanish it says La suma coincide.
If it says FAILED, the copy is damaged, or SHA256SUMS belongs to a different point release (Debian publishes a new one, 13.8, 13.9..., every few months). Download both again, together.
Use the Tab key
No such file or directory is almost always a typing mistake in a long name. Type sha256sum deb and press Tab: the shell completes the name for you.
The forgery: change one byte¶
Now prove the second property on a real ISO. Still on the server, copy it to your home folder there, glue one letter to its end, and take the fingerprint again:
cp /srv/isos/debian-13.7.0-amd64-netinst.iso ~/copy.iso
printf 'x' >> ~/copy.iso
sha256sum ~/copy.iso
rm ~/copy.iso
Line by line: cp copies; ~ means "my home folder"; printf 'x' >> appends one x to the end of the file; rm deletes the copy — 756 MB, on a disk the whole class shares, do not leave it lying around. Then type exit to come back to your PC.
The new fingerprint has nothing to do with the first one. One byte in 756 million, and the fingerprint is completely different. That is why a checksum is believable.
What if the attacker changes the checksum too?¶
The Mint attacker controlled the website. If he had also changed the published checksum, comparing them would not have helped: both would be his.
That is why Debian also signs its list (SHA256SUMS.sign). A digital signature proves who published the list, and only Debian holds the key to make it — the same idea as the wax seal behind Secure Boot in Unit 1. Signatures come back in Unit 3.
From ISO to bootable USB stick¶
To install on a real PC, the ISO must become a USB stick the firmware can start from. This is a demo your teacher does: you do not run it on the classroom PCs.
First, find the stick's name. Run lsblk, plug the stick in, and run lsblk again: a new line appears, for example sdb, with the size of the stick.
That name is the whole danger. Debian's own installation manual gives the command: copy the image onto the whole device (/dev/sdb, not the partition /dev/sdb1), with the stick unmounted, as administrator:
sdX is written with an X on purpose: you replace it with the name you saw in lsblk. sync waits until every byte is really on the stick.
The wrong letter erases a disk
Everything that was on the stick is gone. And if you type the name of your own disk instead of the stick's — sda instead of sdb — your own disk is gone. Check lsblk twice.
Graphical tools do the same with fewer chances to get it wrong: Disks → Restore Disk Image or Startup Disk Creator on Ubuntu, and Rufus on Windows.
Careful: dragging the ISO onto the USB stick does not work
Dragging copies one big file into the stick's file system. The firmware looks for something to boot and finds nothing. The image has to be written as the stick, sector by sector.
Boot order¶
Remember from The boot process: the firmware has a list — try this device first, then that one. A PC with a system on its disk and your USB plugged in still starts from the disk, unless the USB is higher in the list or you press the boot-menu key (often F12, F8 or Esc, depending on the maker).
The boot order is the firmware's list of devices to try, in order, when looking for a bootloader.
A VM has exactly the same list. Try it on live-test, the VM from Your first VM with virt-manager. It is still on the class server: in virt-manager, add today's connection to the server again (the address changes every class) and select it.
- Open
live-test→ View → Details → Boot Options. The list shows the disk and the CD-ROM (the ISO), each with a tick box. - Untick the CD-ROM → Apply. Then View → Console and press ▶.
- The firmware tries the 10 GiB disk, which is empty, and stops with a message saying there is no bootable device. The firmware ran fine — it just found no bootloader. You caused one of Unit 1's boot symptoms on purpose.
- Virtual Machine → Shut Down → Force Off. In Boot Options, tick the CD-ROM again, tick Enable boot menu → Apply. Start the VM and press Esc at once: the firmware's boot menu appears. Choose the CD and Debian's menu is back.
flowchart LR
FW["<b>Firmware</b><br>reads the boot order"] --> D1{"<b>1. Disk</b><br>bootloader?"}
D1 -->|"yes"| SYS["Starts the<br>installed system"]
D1 -->|"no"| D2{"<b>2. CD / USB</b><br>bootloader?"}
D2 -->|"yes"| INST["Starts the<br>installer or live system"]
D2 -->|"no, or unticked"| ERR["<b>No bootable device</b>"]Finally, clean up: live-test has done its job. In the main window, right-click live-test → Delete, keep Delete associated storage files ticked → Delete. The disk file goes too. Next week the real VMs are built.
Key takeaways¶
- A hash function gives every file a short checksum — a fingerprint. SHA-256 gives 256 bits, written as 64 hex characters.
- Same file → same fingerprint; one byte changed → a completely different one. Verify with
sha256sum -c --ignore-missing SHA256SUMSand look forOK. - A checksum only proves your copy is identical to the maker's. A digital signature on the list proves who published it.
- A bootable USB is made by writing the image as the whole device (
/dev/sdX, not a partition) — the wrong device name erases that disk. Dragging the file does not work. - The firmware follows a boot order; the boot-menu key overrides it. An empty disk and no other medium gives no bootable device.
- Three checks before any install: right file, bootable medium, machine told to start from it.
Quick check¶
1. Your ISO's SHA-256 matches the one on the maker's site. What do you know?
- Your copy is identical to the maker's file
- The file has no bugs at all
- The file is encrypted and safe from attackers
- The download used the fastest server
A matching checksum proves only one thing: your copy is byte-for-byte the same as the maker's. It says nothing about bugs or speed.
2. Someone changes one byte of a 756 MB file. Its SHA-256...
- changes completely
- stays the same
- changes only in its last character
- gets one character longer
One changed byte gives a completely different fingerprint — and the length never changes: SHA-256 is always 64 hex characters.
3. You write an ISO to /dev/sda, but your stick was /dev/sdb. What happens?
- The disk sda is overwritten
- Nothing, because the system refuses
- The ISO is copied to both devices
- Only the stick is erased
The command writes to exactly the device you name. If sda is your system disk, it is gone. That is why you check lsblk before and after plugging the stick.
4. A PC with Windows on its disk ignores your bootable USB and starts Windows. What is most likely?
- The disk comes first in the boot order
- The ISO checksum was wrong
- The stick needs more RAM to start
- Windows deleted the stick's contents
The firmware tries devices in the boot order and stops at the first one with a bootloader. Move the USB up the list or press the boot-menu key.
5. Why is SHA-256 written as 64 hexadecimal characters?
- It is 256 bits, and each hex digit holds 4 bits
- Each character stands for one megabyte of the file
- It depends on the size of the file being hashed
- The maker chooses the length when publishing it
SHA-256 always produces 256 bits. One hex digit is 4 bits, so 256 ÷ 4 = 64 characters, whatever the size of the file.
6. You drag the ISO file onto a USB stick in the file manager and try to boot from it. What happens?
- The firmware finds nothing to boot, because the image was copied as a file
- The PC boots the installer normally
- The stick is converted into a bootable medium by the file manager
- The ISO checksum changes and the file becomes damaged
Dragging copies the ISO into the stick's file system. A bootable stick needs the image written as the whole device, sector by sector — with cp to /dev/sdX, Disks or Rufus.
7. An attacker hacks a download site and replaces both the ISO and the published checksum. Pick the two that are true.
- Comparing the checksums alone would say OK
- A digital signature on the checksum list would reveal the forgery
- sha256sum would notice the file came from another server
- The forged ISO would refuse to install
If the attacker controls both, the fingerprints match. Only a digital signature — made with a key the attacker does not have — proves the list really comes from the maker. The forged ISO works perfectly; that is what makes it dangerous.
Next: everything is checked — install your first system for real — Installing Debian.