Project name: WEIRDFEED
Project name: WEIRDFEED
Instruction on installing Kali Linux 2020.4 AMD64 using an ISO file downloaded from kali.org on a Windows 10 2004 host/"hypervisor" running VirtualBox 6.1.16 r140961 (w/ VirtualBox Extension Pack) and get the Hak5 Shark Jack available to the VM
Make sure that virtualization is enabled in BIOS/UEFI (VT-x/AMD-V) otherwise you might get the turtle
Create a new VM in VirtualBox by clicking "New"
Name the VM and select Linux as Type and Debian 64-bit as Version
Set the desired amount of RAM (using 2048 MB here)
Create a Virtual storage device (using 24 GB here)
The VM is now created, click "Settings" and make any additional config to the VM (# of CPUs/cores, video RAM, disable floppy, disable audio, shared folders, etc. anything of choice that is valid)
Last but not least, attach the Kali Linux ISO file to the virtual optical drive of the VM
Click "OK"
Click "Start" to boot the VM
Select the startup disk if asked (once again the Kali ISO image)
Select Graphical Install (default selection) and press enter
Select language, location and keyboard
Enter a hostname (skip domain if it's not something you need for some reason)
Enter user information
Select clock/time
Partition disks using the "Guided - use entire disk" and select the virtual storage device that was previously created (24 GB ish...), all files in one partition, finish and write to disk
Selected "options" are: Xfce, top10 and default
Do some push-ups while waiting...
Install the GRUB boot loader to the primary drive, select /dev/sda
The installer should detect that Kali is installed in a VM as a last step, so no need of installing Guest Additions like in other VirtualBox VMs (if missing, it can be installed manually, search for it, it's out there...)
Finish the installation (or Finnish the installation, if you're from Finland...)
Reboot into your new Kali VM
Login and resize the VM window (the first "proof" of the fact that the Guest Additions has been installed)
Upgrade the Kali VM
sudo apt clean
sudo apt update
sudo apt upgrade
or put it all together with some &&&&&&&&&&&&& and ------yyyyy
(more push-ups..., but with 0.5 Gbps down, there will be just a few push-ups during that 1 minute, lucky me!)
Run some more to really get it all in a clean upgraded state
sudo apt autoremove
sudo apt upgrade
sudo apt dist-upgrade
Shutdown the VM
OK, so now the fun begins... Hak5 time! Make the Shark Jack swim and bite in the VM
Since the onboard ethernet NIC on the Windows host machine is already used for main network access on the PC used in this particular instruction, an ASIX AX88772B based USB NIC is used (the "Hak5 branded" one from the Ethernet Essentials) to get access to the Shark from within the VM
Although the ASIX is a USB device, don't mess with USB filters, it will be enumerated/made available as a NIC in Windows and can be used directly in the VM settings
Plug the ASIX USB NIC into the host Windows PC
Make sure it's enumerated on the host Windows PC (I'm old fashioned, so... Control Panel > Network and Internet > Network and Sharing Center> Change Adapter Settings or... just run ipconfig /all from the Command Prompt)
Put the Shark in arming mode (middle position of the Shark switch) and plug it into the ASIX USB NIC
Try to ping the Shark @ 172.16.24.1 from the host Windows PC
Since Windows 10 is equipped with ssh, we don't need no PuTTY anymore, try to ssh into the Shark from the Command Prompt, should be no problem at all
Exit out of the ssh session
OK, with that verified, head over to VirtualBox again, note that the VM should still be powered off!
Click on "Settings" and the move to the "Network" section
Leave the "Adapter 1" tab as it is and click on the "Adapter 2" tab
Enable the adapter
Select "Bridged Adapter" in the "Attached to" drop down box
Select the USB NIC (ASIX) in the drop down box called "Name"
Close the Settings dialog box using the OK button
Start the VM
Open a Terminal and run ifconfig or ip addr
The Shark should be "visible" using its 172.16.24.0/24 range
ssh into the Shark using the 172.16.24.1 address, no problems!
Done! The Shark is alive!
If you want internet access (and name resolution) from the Shark, then some additional work is needed... Internet will most likely also disappear on the VM when the Shark is connected
To enable networking, on the VM, do:
Edit /etc/sysctl.conf and "enable" IPv4 forwarding
net.ipv4.ip_forward=1
Edit /etc/resolv.conf and add nameserver(s), remove any local ones
nameserver 1.1.1.1
nameserver 8.8.8.8
Set a static IP address in the VM for the NIC that is connected to the Shark, use 172.16.24.24/24 (or any address that corresponds with the address selected for the route command below on the Shark)
Restart networking service or reboot the VM
sudo service networking restart
Adjust the bb.sh or wp6.sh script from Hak5 to make it work with the Shark, call it sj.sh (if I'm kind enough, I might make my edited one available)
Execute sj.sh with sudo
The guided setup might not work, if so edit the defaults in the script instead and connect using saved settings, it should end up letting you know that the Shark is connected to the interwebs
NOTE! The below might mess with your Shark default setup, you have been warned and it's on your own risk, there's no risk for bricking it but you might have to use the firmware recovery to get it back to its original state if you don't memorize it all and reverse it
On the Shark, run:
route add default gw 172.16.24.24 eth0
or
ip route add default via 172.16.24.24
uci add_list dhcp.@dnsmasq[0].server="1.1.1.1"
uci add_list dhcp.@dnsmasq[0].server="8.8.8.8"
uci commit dhcp
service dnsmasq restart
now ping for example 1.1.1.1 or 8.8.8.8 from the Shark
then ping www.google.com to verify name resolution
Run some OpenWrt updates (the Hak5 package list will throw an error, it has been broken "for ages", or... at least a year ish)
opkg update
Tip: If having problems with not being able to connect to the Shark from the VM (even if it has worked before), make sure that the virtual network adapter hasn't been assigned to some other physical NIC than the one that the Shark is connected to, it may happen, verify (and change) under Network for the VM
EOF