ExamFinch.com My Study

Study guide

12.1 Introduction to APT

Practice this exam

Kali Linux Certified Professional KLCP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 How to Use This Guide & Study Strategy 1.3 PEN-103 Syllabus & Study Path

2 About Kali Linux

2.1 A Bit of History: From BackTrack to Kali 2.2 Kali's Relationship with Debian 2.3 Purpose and Use Cases 2.4 Main Features and Design Policies

3 Getting Started with Kali Linux

3.1 Downloading and Verifying a Kali ISO 3.2 Booting Kali in Live Mode 3.3 Installation Options Overview 3.4 Troubleshooting Installations

4 Linux Fundamentals

4.1 What Linux Is and What It Does 4.2 The Command Line 4.3 The Filesystem Hierarchy Standard 4.4 Useful Commands: Files, Search, Environment

5 Permissions and Process Management

5.1 File Permissions and Ownership 5.2 Managing Processes 5.3 Shells, Variables, and the Environment

6 Installing Kali Linux

6.1 Minimal Installation Requirements 6.2 Step-by-Step Installation on a Hard Drive 6.3 Unattended Installations with Preseeding 6.4 ARM Installations

7 Configuring the Network, Users, and SSH

7.1 Configuring the Network 7.2 Managing Unix Users and Groups 7.3 Configuring SSH

8 Configuring Services

8.1 Apache Web Server 8.2 PostgreSQL Database 8.3 Managing Services with systemd

9 Helping Yourself and Getting Help

9.1 Documentation Sources 9.2 Kali Linux Communities 9.3 Filing Good Bug Reports

10 Security Policy and Network Services

10.1 Defining a Security Policy 10.2 Possible Security Measures 10.3 Securing Network Services

11 Firewalling and Monitoring

11.1 Netfilter and iptables Behavior 11.2 Writing iptables Rules and NAT 11.3 Monitoring and Logging

12 Debian Package Management: APT

12.1 Introduction to APT 12.2 The sources.list File 12.3 Kali Repositories 12.4 Basic Package Interaction with apt

13 dpkg and Advanced Package Management

13.1 dpkg Fundamentals 13.2 Inspecting .deb Files and Package State 13.3 Maintainer Scripts and Conffiles 13.4 APT Pinning and Package Authenticity

14 Advanced Usage

14.1 Modifying and Rebuilding Kali Packages 14.2 Recompiling the Kernel 14.3 Building Custom Kali Live ISO Images 14.4 USB Persistence with LUKS Encryption

15 Kali Linux in the Enterprise

15.1 Network Installation with PXE Boot 15.2 Configuration Management with SaltStack 15.3 Metapackages and Custom Repositories 15.4 Configuration Packages and Forking

16 Introduction to Security Assessments

16.1 Kali Linux in an Assessment 16.2 Types of Assessments 16.3 Types of Attacks 16.4 Formalization and the Road Ahead

12.1 Introduction to APT

Key Takeaways Explain This Topic AI

A .deb package is an ar archive containing debian-binary, a control.tar archive (metadata and maintainer scripts), and a data.tar archive (the actual files to install)

The control file's Depends field lists the packages that must be installed first; APT uses this dependency metadata to build a full installation plan automatically

dpkg is the low-level tool that installs individual .deb files, while APT is the high-level front end that resolves dependencies and downloads packages from repositories

On modern Kali, use the apt command for interactive work; apt-get and apt-cache remain for scripts because their output is stable

APT downloads from repositories defined in /etc/apt/sources.list and verifies packages against GPG-signed Release files

Last updated: July 2026

What a .deb Package Actually Is

Every piece of software on Kali Linux — from the kernel to the smallest command-line utility — is delivered as a Debian package , a file with the .deb extension. Because Kali is built on Debian, it inherits Debian's entire packaging system, and the KLCP exam expects you to understand that system at a mechanical level.

A .deb file is not a proprietary format; it is a standard ar archive containing exactly three members:

  • debian-binary — a plain text file with a single line (the format version, normally 2.0)
  • control.tar (compressed as control.tar.gz, .xz, or .zst) — the package's metadata and maintainer scripts
  • data.tar — the actual files the package installs, laid out as they will appear in the filesystem

You can prove this yourself: run ar t somepackage.deb to list the members, or dpkg-deb --info somepackage.deb and dpkg-deb --contents somepackage.deb for friendlier views of the metadata and file list.

The control file and dependency metadata

Inside control.tar, the most important file is control . It holds the fields that drive the entire package management system:

Package and Version — the unique name and version string (for example 1:9.3p1-2, where 1: is the optional epoch, 9.3p1 is the upstream version, and -2 is the Debian revision)

Architecture — amd64, arm64, all, and so on

Depends — a comma-separated list of packages that must be present for this one to work, optionally with version constraints such as libc6 (>= 2.36)

Recommends , Suggests , Pre-Depends , Conflicts , Breaks , Provides — softer or inverse relationships the resolver also honors

Maintainer and Description

The control.tar may also contain maintainer scripts — preinst, postinst, prerm, and postrm — which run before/after installation and removal. This is how a package can create a system user or restart a service automatically when installed.

Why Dependencies Matter

Debian splits software into small, interlocking packages rather than shipping monolithic bundles. When you install a tool like Metasploit, you are really installing a tree of hundreds of packages: Ruby runtimes, shared libraries, database clients. The Depends metadata is what makes this practical — a package manager reads those fields and computes the complete set of packages to download, in the correct order. Without that automation you would be hunting shared libraries by hand, which is exactly the problem APT was built to solve.

Version strings and epochs

Debian version strings deserve a second look because APT's entire upgrade logic rests on comparing them. A version like 1:9.4-2 breaks into an optional epoch (the leading 1:, used when upstream numbering resets or regresses), the upstream version, and the Debian revision after the hyphen. APT upgrades a package only when the candidate version sorts strictly newer than the installed one — which is why downgrades require explicit force options or pinning. To inspect every version APT knows about, run apt-cache policy packagename : it prints the installed version, the candidate version, and which repository each available version would come from.

How APT Resolves and Fetches Packages

APT (Advanced Package Tool) is the high-level package management system. It works from repositories — servers hosting pools of .deb files plus index files describing them. When you run apt install nmap , APT:

  • Consults its local package index (downloaded earlier by apt update into /var/lib/apt/lists/)
  • Reads nmap's Depends/Recommends and recursively walks the dependency graph
  • Computes a full transaction: which packages to download, install, upgrade, or remove
  • Downloads every required .deb over HTTP/HTTPS into /var/cache/apt/archives/

Verifies integrity and hands the packages, in order, to the low-level tool that performs the actual installation

Repositories are authenticated: each ships a Release file signed with GPG (GNU Privacy Guard), and the index files carry checksums for every package. This is why adding a third-party repository requires importing its GPG key — APT will refuse or loudly warn about unauthenticated packages.

dpkg vs APT: Low Level vs High Level

dpkg is the low-level tool. It unpacks a .deb file that is already on your disk, runs its maintainer scripts, and records it in the dpkg database (/var/lib/dpkg/status). Crucially, dpkg does not download anything and does not resolve dependencies — dpkg -i foo.deb on a package with missing dependencies fails or leaves the system in a half-configured state (which you then repair with apt --fix-broken install ). APT sits on top: it handles the network, the resolution, and the ordering, then calls dpkg for each package. The exam loves this layering:

  • dpkg -i installs a local .deb file only
  • apt install ./foo.deb installs a local .deb and resolves its dependencies from the repositories
  • Everything dpkg knows, APT knows, because APT uses the same underlying database
  • apt vs apt-get vs aptitude

Three front ends exist, and the exam expects you to distinguish them:

Command Role When to use

apt Modern, user-friendly front end (progress bars, colored output, combined subcommands) Interactive day-to-day use on Kali

apt-get / apt-cache The classic, script-stable tools Shell scripts and automation; some options (like apt-get dist-upgrade ) predate apt

aptitude Full-screen ncurses interface with an interactive dependency resolver Interactive conflict resolution; not installed by default on Kali

The apt command essentially merges the most-used apt-get and apt-cache features ( apt install , apt search , apt show , apt update ). One important caveat: apt's output format is explicitly not guaranteed stable across versions — it even prints 'WARNING: apt does not have a stable CLI interface' when piped — so scripts should call apt-get/apt-cache instead. aptitude's resolver sometimes proposes solutions apt declines (for example, holding a package back instead of removing it), which is the main reason some administrators still keep it around.