Immutable. This exact content is served forever at /api/v1/blob/cece1f89a6cf51d4.
--- name: kali-linux description: > · Administer Kali: apt, branches, metapackages, images, live USB persistence, NetHunter, wireless/GPU. Triggers: 'kali', 'kali rolling', 'kali snapshot', 'kali-tweaks', 'nethunter'. license: MIT compatibility: "Requires Kali Linux or Kali images with apt and Kali repositories" metadata: source: iuliandita/skills date_added: "2026-04-22" effort: high argument_hint: "[issue-or-workflow]" --- # Kali Linux: Kali Administration, Tooling, and Lab Workflow Kali is Debian-shaped, but the places where it goes wrong are usually Kali-specific: branch mixing, metapackage sprawl, stale images, persistence mistakes, hardware edge cases, or people using the wrong tool family for the job. Administer Kali Linux without flattening it into plain Debian or into a bag of offensive tools. Start by identifying which Kali lane you are actually on - rolling install, last-snapshot, live USB, VM image, Purple image, NetHunter, or a throwaway lab box - then separate base OS health from tool-selection questions, branch hygiene, hardware support, and engagement scope. **Target versions** (verified September 2026): Only pin versions or dated anchors here when they materially affect compatibility or troubleshooting shape. For ordinary package work, prefer the live branch and repo state over a stale package table. | Component | Version or date | Why it matters | |-----------|-----------------|----------------| | **Current dated Kali image release** | 2026.2 | current image baseline and release notes | | Branch docs | September 2026 recheck / verify live | branch behavior and safe lane selection matter more than a single package version | | Metapackage docs | 2025-07 / verify live | tool-family grouping and install scope matter more than memorizing one package list | | Kali 2026.2 kernel lane | 6.19 | release-image baseline for hardware and driver expectations | ## When to use - Package management on Kali with `apt`, `dpkg`, `apt-cache`, repo sanity checks, keyrings, or branch validation - Kali image and install questions: live ISO, netinst, ARM and SBC images, VM images, persistence, and recovery - Kali branch and source-list questions: `kali-rolling`, `kali-last-snapshot`, selective branch use, and mirror hygiene - Metapackage planning: `kali-linux-default`, `kali-linux-everything`, focused `kali-tools-*` bundles, desktop metapackages, and `kali-tweaks` - Selecting the right Kali tool family for the job before installing half the archive by accident - Kali desktop and laptop work: Xfce, GNOME, KDE, i3, PipeWire, GPU drivers, capture tooling, and VM guest behavior - Wireless, SDR, Bluetooth, RFID, HID, USB, and offensive-hardware support that is really a Kali host or package problem - NetHunter and mobile-adjacent Kali questions where the issue is image, package, kernel, or host-tooling shape rather than exploit technique - Safe lab setup, intentionally vulnerable practice targets, snapshot workflow, and separation between lab and production systems - Base Linux ops on Kali when the Kali-specific repo, branch, image, or tool context matters more than generic Debian advice ## When NOT to use - Generic Debian, Ubuntu, Mint, or Pop!_OS administration without Kali-specific context - use **debian-ubuntu** - Shell syntax, quoting, or script portability - use **command-prompt** - Network architecture, DNS, VPNs, reverse proxies, or firewall design - use **networking** - Docker, Podman, image builds, or container runtime issues - use **docker** - Hypervisor configuration, passthrough wiring, or VM platform issues where the fault is clearly outside the Kali guest - use **virtualization** - Kubernetes cluster or manifest work - use **kubernetes** - Fleet-wide Linux configuration via playbooks - use **ansible** - Exploitation, privilege escalation, lateral movement, or post-exploitation on live targets - use **lockpick** - Novel vulnerability hunting, reverse engineering depth work, fuzzing, or proof-of-concept research - use **zero-day** - Defensive hardening, vuln triage, or broad security review - use **security-audit** - OPNsense or pfSense appliance work - use **firewall-appliance** --- ## AI Self-Check Before returning Kali commands or tool recommendations, verify: - [ ] **Kali lane identified**: rolling install, last-snapshot, live USB, VM image, Purple image, NetHunter, or a custom lab box. Advice diverges fast. - [ ] **Not flattened into plain Debian**: do not give generic Debian advice without checking Kali branches, metapackages, and package origin first. - [ ] **Branch model understood**: `kali-rolling` vs `kali-last-snapshot` vs partial or development branches such as `kali-experimental`, `kali-bleeding-edge`, and `kali-dev`. Do not mix them casually. - [ ] **Repo state is clean**: no blind Debian repo additions, no stale image assumptions, no broken `kali-archive-keyring`, and no contradictory source lists. - [ ] **Upgrade path is coherent**: prefer `apt update` plus `apt full-upgrade` on Kali when package transitions matter. Do not cargo-cult `apt upgrade` and call it done. - [ ] **Image mode identified**: installed system, live media, persistence-backed live media, VM image, or mobile image. Recovery steps differ. - [ ] **Metapackage scope is intentional**: do not suggest `kali-linux-everything` when a focused `kali-tools-*` bundle is the sane answer. - [ ] **Tool family matches the task**: information gathering, vulnerability assessment, web, passwords, wireless, reverse engineering, exploitation, post-exploitation, forensics, reporting, or labs. - [ ] **Authorization boundary respected**: Kali tool recommendations still require authorized scope. A tool index is not permission. - [ ] **Lab packages are treated as intentionally vulnerable**: `kali-linux-labs` exists for controlled practice, not for everyday workstation installs. - [ ] **Wireless and hardware path is real**: chipset, firmware, monitor mode, injection support, SDR stack, USB passthrough, and kernel modules match the actual hardware. - [ ] **GPU and capture stack is coherent**: VM passthrough, host acceleration, PipeWire, browser capture, and desktop session line up before blaming the tool. - [ ] **NetHunter is not treated like normal desktop Kali**: mobile kernels, Android host constraints, rootless vs full chroot shape, and missing systemd-style tooling can change which checks even make sense. - [ ] **Correct handoff chosen**: once the question becomes exploitation methodology, route to **lockpick**. Once it becomes original vulnerability discovery, route to **zero-day**. - [ ] **Diagnostic errors are not silenced**: do not hide useful failure output with `2>/dev/null` on commands whose error reason matters. Use `2>&1 || true` when gathering. - [ ] **Channel checked**: kali-rolling, snapshots, metapackages, and NetHunter advice matches official docs - [ ] **Lab boundary explicit**: offensive tooling stays in authorized labs, CTFs, or owned systems - [ ] Cross-cutting agent hygiene applied - see `references/agent-hygiene.md` --- ## Performance - Install task-specific metapackages instead of full tool collections when disk, bandwidth, or update time matters. - Use snapshots or pinned images for repeatable labs rather than debugging rolling drift mid-exercise. - Keep wordlists, captures, and VM disks outside small root partitions. --- ## Best Practices - Do not treat Kali as a hardened daily-driver server by default. - Snapshot before major upgrades, GPU/wireless driver work, or live persistence changes. - Separate client data, lab artifacts, and exploit tooling with clear storage boundaries. ## Workflow ### Step 1: Identify the Kali lane first | Lane | Default stance | What changes | |------|----------------|--------------| | **Installed Kali rolling** | default for most users | continuous updates, package drift matters, repo hygiene is everything | | **Kali last-snapshot** | safer, more frozen lane | release-like behavior between versioned snapshots | | **Live ISO / live USB** | treat as ephemeral first | persistence, overlay state, and storage layout change recovery | | **VM image** | check guest tooling and hypervisor assumptions | shared clipboard, display, USB passthrough, and virtual NIC quirks matter | | **ARM / SBC image** | check board-specific image assumptions first | boot firmware, storage media, peripherals, and package expectations differ from amd64 installs | | **Kali Purple image** | security distro with blue-team flavor | package mix and image choice differ from a standard red-team workstation | | **NetHunter** | mobile and kernel-sensitive | Android host, custom kernels, HID, and wireless support change the answer | | **Partial or development branch user** | slow down immediately | `kali-experimental`, `kali-bleeding-edge`, and `kali-dev` are not casual defaults | ### Step 2: Gather current system state Start narrow, then widen only if the failing layer is still unclear. Baseline checks for every Kali case: ```bash cat /etc/os-release uname -r grep -Rhv '^#\|^$' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>&1 || true apt-cache policy 2>&1 || true apt-cache policy kali-archive-keyring kali-defaults kali-linux-core kali-linux-default 2>&1 || true apt list --upgradable 2>&1 | tail -n +2 findmnt / lsblk -f dpkg -l | grep '^ii kali-' | head -40 ``` Add subsystem probes only when the task needs them. On NetHunter or other mobile-adjacent environments, skip desktop or systemd-specific probes that do not exist there. ```bash # services and logs ps -p 1 -o comm= command -v systemctl >/dev/null 2>&1 && systemctl --failed 2>&1 || true command -v journalctl >/dev/null 2>&1 && journalctl -b -p warning..alert 2>&1 || true # boot and storage findmnt /boot 2>&1 || true findmnt /boot/efi 2>&1 || true # desktop and capture path echo "Session=$XDG_SESSION_TYPE Desktop=$XDG_CURRENT_DESKTOP" loginctl list-sessions 2>&1 || true systemctl status display-manager 2>&1 || true systemctl --user --failed 2>&1 || true systemctl --user status pipewire pipewire-pulse wireplumber xdg-desktop-portal 2>&1 || true command -v wpctl >/dev/null 2>&1 && wpctl status # hardware, wireless, GPU, and NetHunter lspci -k | grep -Ei 'vga|3d|display|network|wireless' lsusb rfkill list 2>&1 || true iw dev 2>&1 || true journalctl -b | grep -Ei 'nvrm|nvidia|amdgpu|i915|xe|ath|iwlwifi|brcm|rtl|mt76|drm' 2>&1 || true command -v dkms >/dev/null 2>&1 && dkms status 2>&1 || true command -v airmon-ng >/dev/null 2>&1 && airmon-ng 2>&1 || true command -v nethunter >/dev/null 2>&1 && nethunter -h 2>&1 | head -20 ``` ### Step 3: Load only the relevant reference | Task type | Reference | |-----------|-----------| | apt, sources, keyrings, rolling vs snapshot, mirrors | `references/packages-branches-and-repos.md` | | choosing metapackages and understanding Kali tool families | `references/metapackages-and-tool-families.md` | | live USB, persistence, installers, VM images, recovery | `references/images-live-persistence-and-recovery.md` | | wireless, GPU, SDR, USB, Bluetooth, NetHunter, hardware support | `references/wireless-gpu-hardware-and-nethunter.md` | | scope discipline, vulnerable labs, snapshots, safe practice | `references/lab-safety-and-scope.md` | | recurring Kali breakage patterns and edge cases | `references/gotchas-and-special-situations.md` | Do not load every reference by default. Pick the one that matches the failure mode, then widen only if the first layer is clean. ### Step 3.5: Stay here or hand off | Request shape | Route | |---------------|-------| | install, package, image, persistence, hardware, or tool-family selection on Kali | stay in **kali-linux** | | hypervisor config, USB passthrough, guest display acceleration, or VM platform wiring | use **virtualization** | | exploit, pivot, privilege escalate, or run post-exploitation workflow on an authorized target | use **lockpick** | | fuzz, reverse engineer deeply, hunt a novel bug, or build a PoC | use **zero-day** | | review the target code or service for defensive findings | use **security-audit** | | generic Debian-family host admin with no Kali-specific context | use **debian-ubuntu** | ### Step 4: Change one layer at a time - Fix source lists and package state before debugging tools that may simply be missing or mismatched. - Fix image or persistence layout before declaring the live USB broken. - Fix desktop session and capture plumbing before blaming Burp, Wireshark, or browser tooling. - Fix hardware support and firmware before blaming monitor mode, injection, SDR, or Bluetooth tools. - Pick the smallest metapackage that matches the workflow instead of installing everything. - Keep labs and production separate. Prefer snapshots, throwaway VMs, and isolated USB media. ### Step 5: Validate before closing ```bash apt-cache policy package_name command -v systemctl >/dev/null 2>&1 && systemctl status unit_name 2>&1 || true journalctl -u unit_name -b 2>&1 || true dpkg -l | grep '^ii kali-' | head -20 command -v msfconsole 2>/dev/null || true command -v nmap 2>/dev/null || true command -v aircrack-ng 2>/dev/null || true ``` Reboot only when the boot path, persistence story, or kernel change is understood and at least one known-good recovery path remains. --- ## Troubleshooting Pattern Keep triage cross-layer and boring: 1. Confirm the Kali lane, branch, image type, and repo state. 2. Identify the failing layer: packages, image or persistence, desktop session, hardware, or tool selection. 3. Pull the right logs before changing config. 4. Change one layer at a time and retest. 5. Keep scope and safety separate from tool installation. Core log sweep: ```bash journalctl -b -p warning..alert journalctl --user -b dmesg --level=err,warn journalctl -u unit_name -b 2>&1 || true ``` Broad pattern sweeps when you need correlation, not first-pass precision: ```bash journalctl -b | grep -Ei 'nvrm|nvidia|amdgpu|i915|xe|ath|iwlwifi|brcm|rtl|mt76|drm' 2>&1 || true journalctl --user -b | grep -Ei 'portal|pipewire|webrtc|burp|wireshark' 2>&1 || true ``` When the problem smells like "Kali is broken," check the boring causes first: - source-list drift or stale keyring - branch mixing - huge metapackage install on weak hardware - USB passthrough or monitor-mode expectations that the chipset cannot satisfy - live USB persistence corruption - VM guest additions and display stack mismatch --- ## Default Decisions - **Kali means branch hygiene first.** The repo state explains more failures than exotic package folklore. - **Prefer `kali-rolling` unless there is a clear reason not to.** It is the main branch most users should be on. - **Use `kali-last-snapshot` when the user wants calmer release-like behavior.** Do not enable it beside `kali-rolling` just because more sounds better. - **Prefer focused metapackages.** `kali-tools-*` bundles beat `kali-linux-everything` unless the box truly exists to be a giant toolbox. - **Treat Kali as a workflow distro, not just a package repo.** Image choice, persistence, hardware, and scope matter as much as package names. - **Stay package-focused when the ask is package-focused.** Installing `nuclei`, `burpsuite`, `hashcat`, or reversing tools stays here until the question turns into defensive review, offensive workflow, or novel vulnerability research. - **Labs should be disposable.** Snapshots, throwaway VMs, and isolated media beat hand-maintaining a single sacred pentest laptop forever. - **Tool families come before individual tool bikeshedding.** Pick the category, then the tool, then the package. - **Wireless and SDR work are hardware stories first.** Chipset support, firmware, passthrough, power, and monitor-mode reality matter more than menu entries. - **Route offensive depth correctly.** Kali can install the tools, but **lockpick** owns exploitation workflow and **zero-day** owns novel bug discovery. --- ## Quick Triage Checklist | Symptom | First checks | |---------|-------------| | `apt` weirdness after install | source lists, `apt-cache policy`, keyring package, branch mixing, `apt full-upgrade` pending | | Tool missing even though metapackage was installed | `dpkg -l`, `apt-cache depends`, command path, package split, transitional package | | Live USB lost changes | persistence partition, mount state, overlay corruption, wrong image mode | | VM feels broken or blind to USB gear | hypervisor guest tools, USB passthrough, network mode, display acceleration | | Wireless tools do not see monitor mode or injection | chipset support, firmware, rfkill, USB power, passthrough, kernel module | | SDR or hardware tools misbehave | package state, udev access, kernel modules, USB permissions, device firmware | | Burp or browser capture feels broken | desktop session, CA import, proxy binding, PipeWire or portal path for GUI helpers | | NetHunter issue | Android version, kernel support, image flavor, HID and wireless support, mobile package lane | | System is huge and slow | metapackage sprawl, desktop choice, background services, `kali-linux-everything` regret | | Nothing makes sense | check gotchas reference - branch mixing, stale keyring, persistence drift, VM passthrough mistakes, and unsupported Wi-Fi chipsets explain a lot | --- ## Reference Files - `references/packages-branches-and-repos.md` - Kali branch model, source lists, keyrings, updates, and package-state recovery - `references/metapackages-and-tool-families.md` - what the main Kali metapackages install, how the tool families map to real workflows, the `kali-tweaks` configuration menu, and when to hand off to lockpick or zero-day - `references/images-live-persistence-and-recovery.md` - installer ISOs, netinst, live images, Purple images, VM images, persistence, and recovery flow - `references/wireless-gpu-hardware-and-nethunter.md` - Wi-Fi, Bluetooth, RFID, SDR, GPU, USB passthrough, and NetHunter-specific hardware realities - `references/lab-safety-and-scope.md` - disposable lab setup, intentionally vulnerable targets, snapshots, and authorization boundaries - `references/gotchas-and-special-situations.md` - recurring Kali breakage patterns and edge cases --- ## Output Contract See `references/output-contract.md` for the full contract. - **Skill name:** KALI-LINUX - **Deliverable bucket:** `audits` - **Mode:** conditional. When invoked to **analyze, review, audit, or improve** existing repo content, emit the full contract - monospace inline header, severity-grouped inline summary, linked Markdown deliverable, and concise monospace conclusion - and write the deliverable to `docs/local/audits/kali-linux/<YYYY-MM-DD>-<slug>.md`. When invoked to **answer a question, teach a concept, build a new artifact, or generate content**, respond freely without the contract. - **Severity scale:** `P0 | P1 | P2 | P3 | info` (see shared contract; only used in audit/review mode). ## Related Skills - **debian-ubuntu** - base Debian-family administration. Use it for generic apt-family hosts; use this skill when Kali-specific branches, images, metapackages, or tool context matter. - **lockpick** - exploitation, post-exploitation, and escalation on authorized targets. This skill helps choose and maintain Kali tooling; lockpick handles the offensive workflow itself. - **zero-day** - vulnerability discovery, reverse engineering depth, fuzzing, and proof-of-concept work. This skill covers the Kali environment and tool families that support that work. - **security-audit** - defensive hardening and vuln review instead of offensive distro workflow. - **virtualization** - hypervisor setup, guest provisioning, passthrough, and VM platform issues once the fault is clearly outside the Kali guest. - **command-prompt** - shell syntax, wrappers, aliases, and script portability when the real issue is the shell rather than Kali. - **networking** - network services, VPNs, DNS, proxies, and firewall design beyond host-level Kali package questions. --- ## Rules 1. **Identify the Kali lane before prescribing commands.** Installed rolling, snapshot, live media, VM image, Purple, and NetHunter differ where it matters. 2. **Do not treat Kali like generic Debian with a dragon wallpaper.** Branches, metapackages, images, and hardware expectations change the answer. 3. **Do not mix branches casually.** `kali-rolling`, `kali-last-snapshot`, `kali-experimental`, `kali-bleeding-edge`, and `kali-dev` each have a purpose. Random mixing usually ends in package pain. 4. **Prefer focused metapackages over giant installs.** Install the tool family that matches the job before reaching for `kali-linux-everything`. 5. **Keep lab and production separate.** Practice targets, vulnerable apps, and offensive tooling belong on disposable systems or isolated boxes. 6. **Respect scope.** Recommending Kali tools is not permission to use them outside authorized environments. 7. **Treat hardware claims as hardware claims.** Monitor mode, injection, SDR capture, HID, and GPU acceleration depend on actual chipsets, firmware, and passthrough support. 8. **Live USB and persistence are their own failure domain.** Do not debug them like a normal installed root filesystem. 9. **Hand off correctly.** Once the work becomes exploitation methodology, use **lockpick**. Once it becomes original vulnerability research, use **zero-day**. 10. **Reach for common Kali failure patterns before exotic explanations.** Stale keyrings, branch drift, metapackage sprawl, persistence corruption, and unsupported hardware explain a large share of the mess.