Exercise 01, Chapter 2 - Getting set up, downloading and verifying 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. Your version may differ:
- Download and import Kali public keys. Again, your version may differ:
123wget -q -O - https://www.kali.org/archive-key.asc | gpg --import#orgpg --keyserver hkp://keys.gnupg.net --recv-key 7D8D0BF6
- Extract the fingerprint and get the ISO SHASUMS:
1234gpg --fingerprint 7D8D0BF6wget http://cdimage.kali.org/kali-201X.X/SHA256SUMSwget http://cdimage.kali.org/kali-201X.X/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-201X.X-amd64.iso49b1c5769b909220060dc4c0e11ae09d97a270a80d259e05773101df62e11e9d ./kali-linux-201X.X-amd64.iso
Compare your hash with the hash listed in the (now-trusted) SHA256SUMS file:1234root@kali:~# grep kali-linux-201X.X-amd SHA256SUMS49b1c5769b909220060dc4c0e11ae09d97a270a80d259e05773101df62e11e9d kali-linux-201X.X-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
Exercise 02, Chapter 2 - Booting Kali
- Boot the Kali USB drive you created in the previous exercise, and select Live mode
- Create a 6 GB file in /root.
- What happened and why?
- Verify that changes do not persist in live mode by rebooting.
- There a couple ways you can do this. You can reboot your host machine, and boot from the USB. You can also boot VirtualBox with USB (google "boot usb virtualbox") or you can boot the USB from VMWare. See the kali.org article (coming soon) for more info on booting USB from VMWare.
- To create the 6 GB file:
1dd if=/dev/zero of=test.img bs=1M count=6144
- Eventually, you'll get a message that there's "no space on the device", although you configured a 20GB hard drive...what's happening? Well, since you're in live mode, you're working in RAM. Therefore all your "filesystem" writes end up in volatile memory. Once you run out of RAM...you run out of disk space.
- Reboot, and verify your changes.
Exercise 03, Chapter 2 - Editing Boot parameters
- We've booted from a pre-made Kali VM and a Kali USB drive. Now, we'll boot another way. Boot a VM from the Kali ISO. Make sure the network is in NAT mode.
- Edit the live boot option and add the “quiet” option on the kernel line for a less-verbose boot up.
- Confirm this makes a difference in the boot verbosity.
- Check out the boot parameters for live and forensics mode. What are the differences?
- In order to boot from an ISO, connect the Kali ISO to a virtual CD drive before booting. In VMWare, this is in Virtual Machine > Settings > CD/DVD (IDE). Check the box to enable CD, and select the disk image. To enable NAT mode: In VMWare > Virtual Machine > Network Adapter
- At the boot menu, choose live boot, press e and add quiet to the linux line:Boot with CTRL-X for F10.
- Did it?
- The differences are in the noswap and noautomount boot parameters which exist in the forensics mode option. While noswap is a standard Debian boot parameter, the noautomaount is a Kali specific feature, implemented by the /etc/X11/Xsession.d/52kali_noautomount file, shipped in the kali-defaults package.
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.