Exercise 01, Chapter 2 – Getting set up, downloading and verifying and burning Kali
- Install a virtual machine (VM) program, like VMWare Fusion (OSX), VirtualBox, etc.
- Download a (likely 64-bit) Kali Linux VM release.
- Launch the Kali VM.
- From this point forward, you should be in the VM. Log into the VM (root/toor) and download the “Kali 64 bit” ISO from https://www.kali.org/downloads/ into your Kali VM.
- Download and import Kali’s public keys.
- Extract the fingerprint and get the SHA256SUMS and the associated signature file for the Kali ISOs.
- Verify the sha256 checksum for your downloaded ISO matches the one in the SHA256SUMS file
- Create a bootable USB device with the image.
- You shouldn’t need help installing a VM program.
- You shouldn’t need help downloading Kali. If you do, this course is not for you.
- Extract the Kali VM .7z file, launch the .VMX file in the extracted directory to run the VM.
- Download the Kali ISO. Note that through this exercise your version numbers may differ:
- Download and import Kali public keys:
123wget -q -O - https://www.kali.org/archive-key.asc | gpg --import#orgpg --keyserver hkp://keys.gnupg.net --recv-key 44C6513A8E4FB3D30875F758ED444FF07D8D0BF6
- Extract the fingerprint and get the ISO SHASUMS:
1234gpg --fingerprint 44C6513A8E4FB3D30875F758ED444FF07D8D0BF6wget http://cdimage.kali.org/kali-2017.1/SHA256SUMSwget http://cdimage.kali.org/kali-2017.1/SHA256SUMS.gpg
- Now, we will verify the signature, to see if the SHA256SUMS file is authentic:
123gpg --verify SHA256SUMS.gpg SHA256SUMS
You should see a confirmation: “Good signature from “Kali Linux Repository (email@example.com)”
But wait, there’s an ugly warning that’s freaking me out!123gpg: WARNING: This key is not certified with a trusted signature!
This warning is normal. You can avoid it by using the “–trust-model always” option. The warning just says that there’s no path between your set of trusted keys and the Kali key in the web of trust. If you don’t have any key and/or if you never signed anyone’s else key, you will never be able to have a trust path to any other key.
Now that you know the SHA256SUMS file is authentic, you can trust the hashes that are in that file. Now, get the SHA sum of the ISO you downloaded:1234root@kali:~# shasum -a 256 ./kali-linux-2017.1-amd64.iso49b1c5769b909220060dc4c0e11ae09d97a270a80d259e05773101df62e11e9d ./kali-linux-2017.1-amd64.iso
Compare your hash with the hash listed in the (now-trusted) SHA256SUMS file:1234root@kali:~# grep kali-linux-2017.1-amd SHA256SUMS49b1c5769b909220060dc4c0e11ae09d97a270a80d259e05773101df62e11e9d kali-linux-2017.1-amd64.iso
If the hashes don’t match, you’ve done something wrong (or had something wrong happen to you!).
- Put in your USB drive, attach it to the VM, find it with dmesg and burn the bootable image with something like this. Beware! This is destructive! Use the right disk identifier (/dev/sdb in this case)!
12345678910111213141516171819202122232425root@kali:~# dmesg[ 4117.132811] usb 1-1: new high-speed USB device number 2 using ehci-pci[ 4117.287319] usb 1-1: New USB device found, idVendor=0781, idProduct=5583[ 4117.287321] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3[ 4117.287322] usb 1-1: Product: Ultra Fit[ 4117.287322] usb 1-1: Manufacturer: SanDisk[ 4117.287323] usb 1-1: SerialNumber: 4C530001231103111240[ 4117.407902] usb-storage 1-1:1.0: USB Mass Storage device detected[ 4117.408855] scsi host3: usb-storage 1-1:1.0[ 4117.410370] usbcore: registered new interface driver usb-storage[ 4117.465386] usbcore: registered new interface driver uas[ 4118.421308] scsi 3:0:0:0: Direct-Access SanDisk Ultra Fit 1.00 PQ: 0 ANSI: 6[ 4118.429107] sd 3:0:0:0: Attached scsi generic sg2 type 0[ 4118.432151] sd 3:0:0:0: [sdb] 242614272 512-byte logical blocks: (124 GB/116 GiB)[ 4118.438709] sd 3:0:0:0: [sdb] Write Protect is off[ 4118.438713] sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00[ 4118.441969] sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA[ 4118.468903] sdb: sdb1[ 4118.492354] sd 3:0:0:0: [sdb] Attached SCSI removable diskroot@kali:~# dd if=kali-linux-2017.1-amd64.iso of=/dev/sdb bs=1M2664+1 records in2664+1 records out2794307584 bytes (2.8 GB, 2.6 GiB) copied, 93.8987 s, 29.8 MB/s
Food for thought
- What good examples can you think of for booting Kali live? What about bad examples?
- Zen question of the day : Does it strike you weird that you can simply dd an ISO to a USB key, and have it boot?
- Kali Live is great when you want to: keep a portable copy of Kali in your pocket; test out Kali Linux without making any changes on your computer; need to engage forensics mode. It’s a bad idea to use Kali live as any kind of permanent installation, especially if you’re hoping to save changes (no persistence!) or if you have limited memory on the boot machine.
- Zen answer: The Kali (and Debian) ISO is an isohybrid. When the ISO is built, a syslinux utility runs the isohybrid command on the ISO, which adds a partition table to the ISO, while still keeping it a valid ISO file.