If you’ve been following along with our Linux Basics For Hackers series, welcome back! In the last article/video, we tackled “Group Management”. It was a bit dry, I know, lekin zaruri tha . We learned how to segregate users, manage permissions with getent, delgroup, and addgroup, and essentially make sure that random users can’t mess with your sensitive files.
Why does that matter today? Well, to install software on Linux, you usually need root or sudo privileges. If you don’t understand permissions, you can’t manage your arsenal. And that’s exactly what we are building today.
In the next part, we’ll look at “Process and Services Management”—basically, how to keep these tools running in the background. But before we can run them, we have to get them on the machine.
To understand how Linux software works, we need to zoom in. We’re going to start with the smallest atom of the system and work our way up.
Let’s get into it.
1. The Atomic Unit: The Package
Coming from Windows, you’re probably used to downloading an .exe or .msi file from a random website, double-clicking it, and praying it doesn’t install a toolbar you didn’t ask for.
In the Linux world (specifically Debian-based systems like Kali and Ubuntu), we don’t really do .exe. We use Packages.
Think of a Package (usually a .deb file) as a sealed, standardized shipping container.
Inside this container, you don’t just get the program (the binary). You get three critical things:
- The Binaries: The actual code that runs the program.
- Configuration Files: The default settings so the program knows how to behave.
- Metadata & Dependencies: This is the magic part. The package contains a manifest that says, “Hi, I am Nmap. To run me, you also need to install library X and library Y.”
Do you know you can extract
.exeandmsixfiles and see what’s inside them?
This “Dependency” system is what makes Linux so stable. Instead of every program bundling its own version of a library (causing “DLL Hell” in Windows), Linux packages share resources. It’s efficient.
But where do these packages come from?
2. The Warehouse: The Repository
If the Package is a shipping container, the Repository (or “repo”) is the massive warehouse where thousands of these containers are stored.
A repository is essentially a server on the internet—maintained by the creators of your Linux distribution (like the Kali Linux team)—that holds all the verified, safe, and compatible packages for your system.
When you want to install a tool, you don’t go googling for it. You tell your system to look in the warehouse.
For a hacker, this is crucial for Trust.
If you download a tool from a random blog, it might have a backdoor. If you download it from the official Kali repository, you know it must be good software. Trust matters in our line of work.
But wait… how does your computer know where these warehouses are located?
3. The Map: sources.list
Your Linux system isn’t psychic. It needs a map to find the repositories. This map is a simple text file located at /etc/apt/sources.list.
This file is arguably one of the most important files on your system. It tells your package manager exactly which URLs to check when you ask for software.
Let’s look at yours right now. Open your terminal:
Bash
cat /etc/apt/sources.list
You will see lines that look something like this:
Plaintext
deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware
Let’s break that down, because it looks like gibberish but it’s actually quite simple:
- deb: This tells the system, “Look for pre-compiled binary packages here.” (The stuff ready to run).
- http://…: This is the URL of the warehouse.
- main/contrib/non-free: These are different sections of the warehouse (e.g., open source software vs. proprietary drivers).
Sometimes, you’ll see lines starting with #. In Linux config files, a # means a comment. That line is ignored.
A word of caution: You might be tempted to add random repositories here to get newer software. Be very careful. Mixing repositories (like adding Ubuntu repos to Kali) is a great way to create a “Franken-Debian” system that breaks itself. Mat karna yeh sab (Don’t do this stuff) unless you really know what you are doing.
4. Decoding the Warehouse: The Structure of Linux Repos
You might be wondering, “Okay, I see this URL http://http.kali.org/kali, but what is actually at that address?”
If you copy that URL and paste it into your web browser, you won’t see a fancy website. You’ll see a simple file directory. It looks old-school, but this structure is the standard for almost every Linux distribution out there.
It’s actually divided into two main areas. Think of it like a giant IKEA:
1. The Showroom (dists)
The dists (short for distributions) folder is like the showroom or the catalog. This is where apt goes to read the list of what is available.
- Inside here, you’ll find folders matching the branch name in your source list (e.g.,
kali-rolling). - Inside that, you see the categories we talked about: Main, Contrib, and Non-Free.
- The Index Files: In these folders, there are massive text files (often compressed, like
Packages.gz). These text files contain the list of every software available, its version, its description, and—most importantly—exactly where the.debfile is hidden in the warehouse.
When you run sudo apt update, your computer is basically downloading these text files from dists to build its own local menu.
2. The Warehouse (pool)
The pool folder is the massive self-serve warehouse downstairs. This is where the actual .deb files live.
If you click into pool, you won’t see software organized by “Hacking Tools” or “Office Apps.” That would be a nightmare to maintain. Instead, it is organized alphabetically:
a,b,c…zliba,libb(for libraries)
Example: If you go to pool -> non-free -> n -> nmap (or main depending on the specific DFSG compliance of the version), you will see every version of the tool ever uploaded.
So, when you type apt install nmap:
aptlooks at the list it downloaded from dists.- The list says: “Nmap is located in
pool/non-free/n/nmap/nmap_7.94.deb“. aptgoes to that specific path in the pool and grabs the file.
The “Aisles”: Main, Contrib, Non-Free
Now, within that structure, the software is tagged by its license. You saw these words in your sources.list, and they dictate which “aisle” apt is allowed to shop in.
- Main: This is the V.I.P. section. It contains software that is 100% Free and Open Source Software (FOSS). The distribution (Kali/Debian) fully supports these packages.
- Examples:
nano,python,bash.
- Examples:
- Contrib (Contributed): This section is a bit tricky. The software packages here are open source, but they depend on other software that is NOT open source to function.
- Example: An open-source downloader for a proprietary game. The tool is free, but what it fetches is not.
- Non-Free: This is the aisle for software with restrictive licenses. As you pointed out, tools like Nmap (due to the NPSL license) or Burp Suite (Pro/Community) often live here because they don’t meet the strict “Free Software” guidelines of Debian/GNU. You can use them, but the code isn’t “free” in the same way
pythonis. - Non-Free-Firmware: A newer section containing binary drivers for hardware like Wi-Fi cards.
- Why hackers need this: If you want your Wi-Fi adapter to go into “Monitor Mode” for packet sniffing, you often need proprietary firmware from this section. Bina iske hacking mushkil hai (Without this, hacking is difficult).
So, the repo isn’t magic. It’s just a very organized file server with a list (dists) and a pile of boxes (pool). Simple, right?
4. The Logistics Team: The Package Manager
So, we have the box (Package), the warehouse (Repository), and the map (sources.list). Now we need the logistics team to actually go fetch the box, check the inventory, and deliver it to your doorstep.
This is your Package Manager.
In our world, we have two main players: APT and DPKG.
The Manager: APT (Advanced Package Tool)
apt is the smart manager. You tell it what you want, and it handles the details. It checks the map, calls the warehouse, downloads the package and all its dependencies, and installs them.
Updating the Cache
Before apt can find anything, it needs to know what’s currently in the warehouse.
Bash
sudo apt update
- What it does: This downloads the latest “product list” from the repositories in your
sources.list. - Why run it: If you don’t run this, your computer might try to download version 1.0 of a tool when the warehouse only has version 1.1.
Seeing What You Have
Curious about what is already installed?
Bash
apt list --installed
This prints a massive list. It’s useful if you want to pipe it into grep to check for a specific tool:
Bash
apt list --installed | grep python3
Installing Software from Repos
To install a standard tool like nmap:
Bash
sudo apt install nmap -y
5. Installing Local .deb Files (The Manual Way)
Sometimes, the tool you want isn’t in the repository. Maybe it’s too new, or maybe it was removed (like Neofetch). In these cases, you have to download the .deb file manually from a website and install it yourself.
There are two ways to do this. The “Old School” way and the “Modern Smart” way.
Let’s use Neofetch as our example. First, let’s download it:
Bash
wget http://ftp.us.debian.org/debian/pool/main/n/neofetch/neofetch_7.1.0-2_all.deb
Now that we have the file, how do we install it?
Method A: The Old School Way (dpkg)
dpkg (Debian Package) is the low-level tool that actually unpacks the software.
Bash
sudo dpkg -i neofetch_7.1.0-2_all.deb
(The -i flag stands for install).
The Catch: dpkg is powerful but “dumb.” It doesn’t know how to fetch dependencies. If Neofetch needs a specific font or library that isn’t on your computer, dpkg will fail and leave your system in a “broken” state.
If that happens, you have to run this command to ask apt to come in and clean up the mess:
Bash
sudo apt --fix-broken install
Method B: The Modern Way (apt)
Did you know apt can also install local files? This is the preferred method because it solves the dependency problem automatically.
The syntax is slightly different. You must provide the path to the file (using ./ for the current directory).
Bash
sudo apt install ./neofetch_7.1.0-2_all.deb
Why is this better?
When you run this, apt looks at the .deb file, sees what dependencies it needs, checks the online repositories, and downloads everything in one go. No errors, no broken states. Sahi hai na? (Pretty cool, right?)
If you forget the ./, apt will think you are looking for a package named “neofetch…” in the online repo and will fail. The path is key.
The Outsider: Git
Finally, we have the “Wild West” method.
As a cybersecurity enthusiast, you’ll often find tools on GitHub that haven’t been packaged into a .deb file yet. They aren’t in any repository. They are just raw code.
To get these, we use git.
Bash
sudo apt install git -y
Then, we clone (copy) the repository to our machine:
Bash
git clone https://github.com/username/toolname.git
This isn’t strictly “package management”—it’s source code management. But for us hackers, it’s a daily driver. Just remember: when you git clone, you don’t get automatic updates. You have to manually pull changes later.
Conclusion
And there you have it—the full lifecycle of a Linux program.
We started with the Package (the box), moved to the Repository (the warehouse), checked our sources.list (the map), and finally used APT and DPKG to install our tools.
It seems like a lot of steps compared to “double-click install,” but this system is what makes Linux so incredibly powerful and secure. You have total control over exactly what code is running on your machine.
Next in this series, we’ll dive into services and processes — because packages don’t just sit on your system. They create services, and every time you run one, it spins up its own process. It’s time to see how those moving parts actually come to life.
Until then, update your repos, check your sources, and stay curious.
See you in the next one!
Frequently Asked Questions (FAQs)
Q: What is the difference between apt and apt-get?
A: apt is the newer, user-friendly version designed for humans. apt-get is the older, lower-level command often used in scripts. For daily use, stick to apt—it gives you progress bars and nicer colors!
Q: My sources.list is empty or missing! What do I do?
A: Don’t panic. You can generate a new one. Search online for “Kali Linux default sources.list”, copy the text, and paste it into /etc/apt/sources.list using a text editor like nano.
Q: Why do I prefer apt install ./file.deb over dpkg -i?
A: Because apt handles dependencies automatically. dpkg will fail if a dependency is missing, forcing you to do extra work to fix it. apt is just smarter.
Q: Is it safe to use git clone for everything?
A: Generally, yes, but be careful. GitHub code is not vetted by the Kali team. Always read the code (or at least the README) before running scripts from unknown developers. You don’t want to run a “hacker tool” that actually hacks you.
Q: How do I remove a package I installed?
A: Easy. Run sudo apt remove package_name. If you want to delete the configuration files too (for a fresh start), use sudo apt purge package_name.
