Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tamhow to create bootable kali linux usb drive
The simplest way to create a bootable Kali Linux USB drive is:
This is the first decision, and it matters:
If your goal is “boot Kali from USB and use it immediately,” choose Live. If your goal is “install Kali on a laptop/PC,” choose Installer. (kali.org)
Use a USB stick with enough capacity. Kali’s current Windows USB guide specifies 8 GB or larger, while some Linux/macOS pages still mention 4 GB minimum; in practice, 8 GB or more is the safer recommendation, especially if you may later add persistence. All existing data on the USB will be erased. (kali.org)
Kali strongly recommends downloading only from official sources and verifying the checksum. This is not just a corruption check; it is also a basic authenticity check. (kali.org)
On Windows, Kali documents:
certutil -hashfile kali-linux-2026.1-live-amd64.iso sha256On Linux/macOS, Kali documents:
shasum -a 256 kali-linux-2026.1-live-amd64.isoThen compare the result with the SHA256 published on Kali’s official download page. Replace the filename with the one you actually downloaded. (kali.org)
For most users, Etcher is the best path because it is simple and consistent across operating systems. Kali’s official procedure is essentially the same on Windows, Linux, and macOS:
This is the method I would recommend unless you specifically want lower-level control. (kali.org)
If you are on Windows and prefer more control, Rufus is also officially documented by Kali:
Kali also notes that if you are unsure about MBR/GPT details, leaving Rufus defaults is reasonable. Their Windows documentation further notes that MBR is commonly used for legacy BIOS and UEFI+CSM systems, while GPT is required on UEFI systems with CSM disabled. (kali.org)
ddIf you are creating the USB from Linux and prefer terminal tools, Kali documents the dd workflow. The critical engineering point is to write to the whole device such as /dev/sdb, not a partition like /dev/sdb1. Misidentifying the device can destroy data on another disk. (kali.org)
Typical workflow:
Identify the USB device before and after insertion:
sudo fdisk -lWrite the ISO:
sudo dd if=kali-linux-2026.1-live-amd64.iso of=/dev/sdX conv=fsync bs=4M status=progressReplace /dev/sdX with the actual USB device. Kali documents conv=fsync to ensure data is flushed to the USB before the command returns, and recommends bs=4M as a conservative, reliable block size. (kali.org)
ddOn macOS, Kali documents a similar process:
List disks:
diskutil listUnmount the USB:
diskutil unmountDisk /dev/diskXWrite the image using the raw disk device for better performance:
sudo dd if=kali-linux-2026.1-live-amd64.iso of=/dev/rdiskX bs=4M status=progressIf macOS reports 4M as invalid, Kali says to use 4m instead. If status=progress is unsupported on your macOS version, remove it. (kali.org)
As reflected in Kali’s currently published USB documentation, Etcher remains the simplest officially recommended graphical tool across Windows, Linux, and macOS. On Windows, Rufus is still a valid option, with DD Image mode preferred when prompted. (kali.org)
Kali’s current documentation also distinguishes more clearly than many older guides between:
That distinction is important because many tutorials mix them together, but they are technically different use cases. (kali.org)
A bootable USB is not created by simply copying the ISO file onto the drive like a normal file transfer. The imaging tool writes the ISO as a bootable disk image, including partitioning and boot structures required by BIOS/UEFI firmware. That is why tools like Etcher, Rufus, and dd are used. This is also why Windows may later show the USB as having unfamiliar or “corrupted” partitions. (kali.org)
Kali’s verification page explicitly notes that after writing the USB, Windows may not recognize the filesystem layout and may prompt you to format it. Do not format it, or you will destroy the bootable structure. (kali.org)
Also, during imaging on Windows, antivirus products may warn that Kali contains malware or trojans. Kali’s official Windows guide says such warnings are expected because Kali includes penetration-testing tools that are commonly flagged by security software. This is only a reasonable assumption if you used an official, checksum-verified image. (kali.org)
If you want the shortest reliable workflow:
If you want Kali Live to remember files and changes between reboots, use persistence. Kali’s officially supported method is to create an additional ext4 partition labeled persistence, mount it, and place a persistence.conf file containing / union on that partition. (kali.org)
Example commands from Kali’s documentation:
sudo mkfs.ext4 -L persistence /dev/sdX3
sudo mkdir -p /mnt/my_usb
sudo mount /dev/sdX3 /mnt/my_usb
echo "/ union" | sudo tee /mnt/my_usb/persistence.conf
sudo umount /dev/sdX3Then boot using the Live USB Persistence option. (kali.org)
Kali notes that Rufus has a persistence slider, but that path is not officially supported for all images. (kali.org)
dd: this can overwrite another disk completely. (kali.org)dd rejects bs=4M: use 4m. (kali.org)If your real goal is not a live USB but a full Kali installation on an external USB SSD, that is a different setup from a normal live bootable USB. Kali documents that separately as a standalone USB installation. (kali.org)
Also, if you only need Kali occasionally on a Windows machine, a VM or WSL may be more convenient than maintaining a physical boot USB; however, that is a different deployment model from the one you asked about. This is an engineering tradeoff rather than a requirement. (kali.org)
For most users, the correct answer is:
If you want, I can now give you a short exact procedure for Windows, Linux, or macOS only.