Kali Linux: package modification
We continue to translate the book " Kali Linux Revealed ". The ninth chapter is devoted to the expanded use of the system. In particular, after studying it, you can learn how to create from the basic distribution of Kali exactly what you need. Today we publish the translation of the first section of this chapter. It will be about modifying Kali packages.
Kali is designed as a modular, customizable pentesting environment that is highly customizable and supports various use cases. System tuning can affect multiple levels. If necessary, you can start with the source code. We will consider this setting level first. The source code of the Kali packages is publicly available. In this chapter, we will show you how to find packages, how to modify them, and build your own packages from them, customized as you need. Modification of the Linux kernel is a peculiar area of system configuration, so a separate section is devoted to it. In it we will talk about where to find the source code of the kernel, how to set up its build system, and finally how to compile it and build the necessary kernel packages.
The second level of system configuration is to build Live images. We will show how, using the
')
In addition, we will talk about how to create a permanent data storage for a Live image recorded on a USB flash drive. This configuration allows you to save files and operating system changes between reboots.
Modifying Kali packages is usually a task that project participants and developers are solving: they update packages to new versions released by the developers of these packages, they change standard configurations that allow better integration of packages into the distribution kit, or fix errors reported by users. However, you may have special needs that the official packages do not correspond to, so knowing how to build a modified package can be very useful.
You may wonder why you need to do this at all. In the end, if you need to modify some software, you can always download its source code (usually with
So, when might a package modification be needed? Consider a few examples.
To begin with, imagine that you use SET extensively and notice that the developers of the package have released a new release. You urgently need to try it, and programmers who are working on Kali are busy participating in the conference. As a result, you will have to upgrade the package yourself.
Here is another situation. Let's say you can't make the MIFARE NFC card work and you want to rebuild
Finally, imagine that
We will look at these situations in detail below and try to summarize the explanations in such a way that you can use the presented techniques in other cases. However, we must understand that it is impossible to tell about everything that you may encounter. If you encounter a problem, try to find a solution or contact the appropriate forums for help (for more information, see Chapter 6 , which describes how to search for answers to complex questions).
Whatever changes you want to make to the package, the overall sequence of actions is always the same. Namely, you need to download the source code of the package, unpack it, make changes and build the package. However, in each of these steps, you can usually use a variety of tools designed to solve the same problem. Here we have selected the most appropriate and most popular tools, however, it should be noted that there are other excellent tools that we do not write about here.
Rebuilding the Kali package starts with downloading the source code. A source package consists of many files. The main file is
Source packages are stored on Kali mirrors, which you can work with via HTTP. You can use the browser to download the necessary files, but the easiest way to solve this problem is to use the command
In this example, we load the source package from the Kali mirror. This is the same package as in Debian, since the version string does not contain the “kali.” Substring. This means that no specific Kali-specific changes have been made to this package.
If you need a specific version of the source package that is not available in the repositories listed in
After finding the URL for the
It is worth noting that
Now that you have the source code, you need to install the build dependencies. They are necessary in order to build a binary package. In addition, it is very likely they will come in handy for partial builds that you may need to perform to check for changes in the process of making them into the package.
In each source package, build dependencies are declared in the
In this example, all build dependencies can be resolved using the packages that are accessible by APT. This may not always be the case, as the
In this section, it is impossible to tell about all possible types of changes that may need to be made to a certain package. This would require covering all the subtleties of working with Debian packages. However, here we will talk about the three most common options mentioned above, and describe some of the most important steps in the package modification process that cannot be avoided (
The first thing to do is to change the version number of the package. This is necessary so that new packages can be distinguished from the original ones present in Kali or Debian. In order to do this, we usually add a suffix that identifies the person who makes the changes (usually an individual or a company). So, for example, my nickname in IRC is
If you make such changes regularly, it may be worthwhile to add your full name and email address to the
In one of the situations described above, we downloaded the
The need to do this is common, so there should be no difficulty with this. Unfortunately, the features of working with patches may vary, depending on the format of the source package, and on how exactly the packages are organized in the Git repository (if Git is used to support the package).
So, you have executed the
At this point, you have manually patched the source code, and you can build a binary file of a modified version of the package (we will discuss the build below in section 9.1.4). But if you try to build an updated package, an error will occur, the message of which says about unexpected changes to the package code prepared by its developers (
If the package with the source code uses the format of 1.0 or 3.0 (native), then the requirements for registering changes in the code of packages in the form of patches are not put forward. Change details are automatically embedded in the resulting source package.
If you have used Git to download the source code, the situation is complicated. There are many ways to organize work with Git and related tools, and it’s quite obvious that not all Debian packages are prepared using the same workflow and software tools. The differences in packages regarding the file format already discussed are applicable here, but when working with Git, you need to find out whether patches have already been applied in the source tree or are only stored in
In this situation, the most popular package is
, , . , ,
, , . ,
, . , — SET , (7.4.5), Kali ( 7.4.4). . , , - .
, ,
That's all. .
, , , , , . — , .
,
, , .deb-, . , , . , — , Kali, . Linux.
Dear readers! , Linux? — , .
:
→ 1. Kali Linux: ,
→ 2. Kali Linux: netfilter
→ 3. Kali Linux:
→ 4. Kali Linux:
→ 5. Kali Linux:
→ 6. Kali Linux:
→ 7. Kali Linux:
→ 8. Kali Linux:
Chapter 9. Advanced System Usage
Kali is designed as a modular, customizable pentesting environment that is highly customizable and supports various use cases. System tuning can affect multiple levels. If necessary, you can start with the source code. We will consider this setting level first. The source code of the Kali packages is publicly available. In this chapter, we will show you how to find packages, how to modify them, and build your own packages from them, customized as you need. Modification of the Linux kernel is a peculiar area of system configuration, so a separate section is devoted to it. In it we will talk about where to find the source code of the kernel, how to set up its build system, and finally how to compile it and build the necessary kernel packages.
The second level of system configuration is to build Live images. We will show how, using the
live-build tool, we use a lot of opportunities to fine-tune ready-made ISO images. This includes the use of pre-configured Debian packages instead of the packages available on mirrors.
')
In addition, we will talk about how to create a permanent data storage for a Live image recorded on a USB flash drive. This configuration allows you to save files and operating system changes between reboots.
9.1. Kali package modification
Modifying Kali packages is usually a task that project participants and developers are solving: they update packages to new versions released by the developers of these packages, they change standard configurations that allow better integration of packages into the distribution kit, or fix errors reported by users. However, you may have special needs that the official packages do not correspond to, so knowing how to build a modified package can be very useful.
You may wonder why you need to do this at all. In the end, if you need to modify some software, you can always download its source code (usually with
git ), modify and run the modified version. This approach allows you to achieve the goal, but only when it is possible, and when you use your home directory for this purpose. However, if an application needs an installation that makes it available throughout the system (for example, using make install ), then it will litter the file system with files unknown to dpkg , and will soon become a source of problems that cannot be detected based on package dependency analysis. Moreover, properly prepared packages can be transferred to someone else, it is much easier to deploy them on multiple computers, or cancel changes to them after it was discovered that they do not give the desired effect.
So, when might a package modification be needed? Consider a few examples.
To begin with, imagine that you use SET extensively and notice that the developers of the package have released a new release. You urgently need to try it, and programmers who are working on Kali are busy participating in the conference. As a result, you will have to upgrade the package yourself.
Here is another situation. Let's say you can't make the MIFARE NFC card work and you want to rebuild
libfreefare in order to turn on debug messages and get some meaningful data that you can include in the error report that you are preparing.
Finally, imagine that
pyrit crashes with a mysterious error message. After searching the Internet, you find a commit in the Git developer repository, which you think can fix this problem. Next, you are going to rebuild the package to include the found fix.
We will look at these situations in detail below and try to summarize the explanations in such a way that you can use the presented techniques in other cases. However, we must understand that it is impossible to tell about everything that you may encounter. If you encounter a problem, try to find a solution or contact the appropriate forums for help (for more information, see Chapter 6 , which describes how to search for answers to complex questions).
Whatever changes you want to make to the package, the overall sequence of actions is always the same. Namely, you need to download the source code of the package, unpack it, make changes and build the package. However, in each of these steps, you can usually use a variety of tools designed to solve the same problem. Here we have selected the most appropriate and most popular tools, however, it should be noted that there are other excellent tools that we do not write about here.
9.1.1. Download Source Code
Rebuilding the Kali package starts with downloading the source code. A source package consists of many files. The main file is
*.dsc (Debian Source Control), it contains a list of related files, among which may be *.tar.{gz,bz2,xz} files, sometimes - *.diff.gz , or *.debian.tar.{gz,bz2,xz} .
Source packages are stored on Kali mirrors, which you can work with via HTTP. You can use the browser to download the necessary files, but the easiest way to solve this problem is to use the command
apt source source_package_name . This command requires the deb-src in the /etc/apt/sources.list file and the actual index files (you can use the apt update command to apt update ). By default, the above settings are not included in Kali, as very few users need the source code of the packages, but it is very easy to bring everything to the desired state. To do this, add the line deb-src to the /etc/apt/sources.list file (for information, see section 8.1.3 “ Kali Repositories ”, and section 8.1.2. “ Details of the sources.list File ”) .
$ apt source libfreefare Reading package lists... Done NOTICE: 'libfreefare' packaging is maintained in the 'Git' version control system at: git://anonscm.debian.org/collab-maint/libnfc.git Please use: git clone git://anonscm.debian.org/collab-maint/libnfc.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 119 kB of source archives. Get:1 http://archive-2.kali.org/kali kali-rolling/main libfreefare 0.4.0-2 (dsc) [2,090 B] Get:2 http://archive-2.kali.org/kali kali-rolling/main libfreefare 0.4.0-2 (tar) [113 kB] Get:3 http://archive-2.kali.org/kali kali-rolling/main libfreefare 0.4.0-2 (diff) [3,640 B] Fetched 119 kB in 1s (63.4 kB/s) gpgv: keyblock resource '/home/rhertzog/.gnupg/trustedkeys.gpg': file open error gpgv: Signature made Tue 04 Mar 2014 06:57:36 PM EST using RSA key ID 40AD1FA6 gpgv: Can't check signature: public key not found dpkg-source: warning: failed to verify signature on ./libfreefare_0.4.0-2.dsc dpkg-source: info: extracting libfreefare in libfreefare-0.4.0 dpkg-source: info: unpacking libfreefare_0.4.0.orig.tar.gz dpkg-source: info: unpacking libfreefare_0.4.0-2.debian.tar.xz $ cd libfreefare-0.4.0 $ ls AUTHORS CMakeLists.txt COPYING HACKING m4 README ChangeLog configure.ac debian libfreefare Makefile.am test cmake contrib examples libfreefare.pc.in NEWS TODO $ ls debian changelog copyright libfreefare-dev.install rules compat libfreefare0.install libfreefare-doc.install source control libfreefare-bin.install README.Source watch
In this example, we load the source package from the Kali mirror. This is the same package as in Debian, since the version string does not contain the “kali.” Substring. This means that no specific Kali-specific changes have been made to this package.
If you need a specific version of the source package that is not available in the repositories listed in
/etc/apt/sources.list at the time of download, in this case it is easiest to download it by first finding out the URL of its .dsc file, finding it on http : //pkg.kali.org and using it in the dget (from the devscripts package).
After finding the URL for the
libfreefare source libfreefare available in kali-bleeding-edge , you can load it with dget . First, the .dsc file will be loaded, after which it will be parsed in order to find out which other files it refers to, then these files will be downloaded:
$ dget http://http.kali.org/pool/main/libf/libfreefare/libfreefare_0.4.0+0~git1439352548.ffde4d-1.dsc dget: retrieving http://http.kali.org/pool/main/libf/libfreefare/libfreefare_0.4.0+0~git1439352548.ffde4d-1.dsc % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 364 100 364 0 0 852 0 --:--:-- --:--:-- --:--:-- 854 100 1935 100 1935 0 0 2650 0 --:--:-- --:--:-- --:--:-- 19948 dget: retrieving http://http.kali.org/pool/main/libf/libfreefare/libfreefare_0.4.0+0~git1439352548.ffde4d.orig.tar.gz [...] dget: retrieving http://http.kali.org/pool/main/libf/libfreefare/libfreefare_0.4.0+0~git1439352548.ffde4d-1.debian.tar.xz [...] libfreefare_0.4.0+0~git1439352548.ffde4d-1.dsc: dscverify: libfreefare_0.4.0+0~git1439352548.ffde4d-1.dsc failed signature check: gpg: Signature made Wed Aug 12 06:14:03 2015 CEST gpg: using RSA key 43EF73F4BD8096DA gpg: Can't check signature: No public key Validation FAILED!! $ dpkg-source -x libfreefare_0.4.0+0~git1439352548.ffde4d-1.dsc gpgv: Signature made Wed Aug 12 06:14:03 2015 CEST gpgv: using RSA key 43EF73F4BD8096DA gpgv: Can't check signature: No public key dpkg-source: warning: failed to verify signature on ./libfreefare_0.4.0+0~git1439352548.ffde4d-1.dsc dpkg-source: info: extracting libfreefare in libfreefare-0.4.0+0~git1439352548.ffde4d dpkg-source: info: unpacking libfreefare_0.4.0+0~git1439352548.ffde4d.orig.tar.gz dpkg-source: info: unpacking libfreefare_0.4.0+0~git1439352548.ffde4d-1.debian.tar.xz
It is worth noting that
dget does not automatically unpack packages with source code, as it cannot verify the PGP signatures of these packages. Thus, we need to do this manually using the dpkg-source -x dsc-file command. In addition, you can activate the forced extraction of packages with the source code using the option --allow-unauthenticated or -u . Conversely, you can use the --download-only option to skip the unpacking step.
▍Download source code from Git
You might have noticed that when you callapt sourceyou are told that the Git repository can be used to support the package. This may be the Debian repository or the Kali repository.
All packages specifically prepared for Kali can be found in the Git repositories located on git.kali.org . You can download code from these repositories using a command likegit clone git://git.kali.org/packages/source-package. If this command fails to load what you need, try switching to thekali/masterbranch withgit checkout kali/master.
Unlike what can be downloaded using theapt sourcecommand, patches will not be automatically applied in the resulting tree. Take a look at thedebian/patches/in order to learn about the possible changes made in Kali.
$ git clone git://git.kali.org/packages/kali-meta Cloning into 'kali-meta'... remote: Counting objects: 760, done. remote: Compressing objects: 100% (614/614), done. remote: Total 760 (delta 279), reused 0 (delta 0) Receiving objects: 100% (760/760), 141.01 KiB | 0 bytes/s, done. Resolving deltas: 100% (279/279), done. Checking connectivity... done. $ cd kali-meta $ ls debian $ ls debian changelog compat control copyright rules source
You can use Git repositories as an alternative way to download source code and, in general, follow other recommendations from this section. But when the Kali developers work with these repositories, they use a different package preparation process and tools from thegit-buildpackage, which we don’t talk about here. Details on these tools can be found here .
9.1.2. Installing Build Dependencies
Now that you have the source code, you need to install the build dependencies. They are necessary in order to build a binary package. In addition, it is very likely they will come in handy for partial builds that you may need to perform to check for changes in the process of making them into the package.
In each source package, build dependencies are declared in the
Build-Depends field of the debian/control file. Use apt to install these dependencies (assuming you are in the directory containing the unpacked package with source code):
$ sudo apt build-dep ./ Note, using directory './' to get the build dependencies Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: autoconf automake autopoint autotools-dev debhelper dh-autoreconf dh-strip-nondeterminism gettext intltool-debian libarchive-zip-perl libfile-stripnondeterminism-perl libtool po-debconf 0 upgraded, 13 newly installed, 0 to remove and 0 not upgraded. Need to get 4 456 kB of archives. After this operation, 14,6 MB of additional disk space will be used. Do you want to continue? [Y/n] […]
In this example, all build dependencies can be resolved using the packages that are accessible by APT. This may not always be the case, as the
kali-rolling build tools do not check the possibility of installing assembly dependencies (only binary package dependencies are taken into account). In practice, binary and build dependencies are often closely related, and for most packages, build dependencies are sufficient.
9.1.3. Changes to package code
In this section, it is impossible to tell about all possible types of changes that may need to be made to a certain package. This would require covering all the subtleties of working with Debian packages. However, here we will talk about the three most common options mentioned above, and describe some of the most important steps in the package modification process that cannot be avoided (
changelog file up to date).
The first thing to do is to change the version number of the package. This is necessary so that new packages can be distinguished from the original ones present in Kali or Debian. In order to do this, we usually add a suffix that identifies the person who makes the changes (usually an individual or a company). So, for example, my nickname in IRC is
buxy , so I will use it as a suffix. This change is best done using the dch (Debian CHangelog) command from the devscripts package. In my case, calling this command will look like dch --local buxy . This command calls the text editor ( sensible-editor , which launches the editor specified in the VISUAL or EDITOR environment EDITOR , otherwise /usr/bin/editor is called), which allows you to document changes made to a specific assembly. In this case, you can see that the dch command really changed the debian/changelog file:
$ head -n 1 debian/changelog libfreefare (0.4.0-2) unstable; urgency=low $ dch --local buxy [...] $ head debian/changelog libfreefare (0.4.0-2buxy1) UNRELEASED; urgency=medium * Enable --with-debug configure option. -- Raphael Hertzog<buxy@kali.org> Fri, 22 Apr 2016 10:36:00 -0400 libfreefare (0.4.0-2) unstable; urgency=low * Update debian/copyrtight. Fix license to LGPL3+.
If you make such changes regularly, it may be worthwhile to add your full name and email address to the
DEBFULLNAME and DEBEMAIL environment variables. This data can be used by a variety of tools for working with packages, including dch , which dch them into a line starting with “ -- ” in the above code.
▍9.1.3.1. Patch application
In one of the situations described above, we downloaded the
pyrit source pyrit and are going to apply the patch that we found in the Git repository of the developers of the package.
The need to do this is common, so there should be no difficulty with this. Unfortunately, the features of working with patches may vary, depending on the format of the source package, and on how exactly the packages are organized in the Git repository (if Git is used to support the package).
▍9.1.3.1.1. Apply patch to unpacked source package
So, you have executed the
apt source pyrit and you have a folder pyrit-0.4.0 . In this situation, you can apply the patch directly, using the patch -p1< patch-file command:
$ apt source pyrit [...] $ cd pyrit-0.4.0 $ wget https://github.com/JPaulMora/Pyrit/commit/14ec997174b8e8fd20d22b6a97c57e19633f12a0.patch -O /tmp/pyrit-patch [...] $ patch -p1
At this point, you have manually patched the source code, and you can build a binary file of a modified version of the package (we will discuss the build below in section 9.1.4). But if you try to build an updated package, an error will occur, the message of which says about unexpected changes to the package code prepared by its developers (
unexpected upstream changes ). This is due to the fact that pyrit (like most source packages) uses the source code format (take a look at the debian/source/format file), known as 3.0 (quilt), where changes in the code made by the developers of the package should written in separate patches stored in debian/patches/ , with the debian/patches/series file indicating the order in which these patches should be applied. You can register the changes as a new patch using the dpkg-source --commit :
$ dpkg-source --commit dpkg-source: info: local changes detected, the modified files are: pyrit-0.4.0/cpyrit/pckttools.py Enter the desired patch name: fix-for-scapy-2.3.patch dpkg-source: info: local changes have been recorded in a new patch: pyrit-0.4.0/debian/patches/fix-for-scapy-2.3.patch $ tail -n 1 debian/patches/series fix-for-scapy-2.3.patch
▍Patch management using quilt
The patch agreement in question has become popular thanks to a tool calledquilt. The source code “3.0 (quilt)” format is thus compatible with this tool — with a slight change in the fact that it usesdebian/patchesinstead ofpatches. This tool can be found in the package with the same name. Here you can read the manual on it.
If the package with the source code uses the format of 1.0 or 3.0 (native), then the requirements for registering changes in the code of packages in the form of patches are not put forward. Change details are automatically embedded in the resulting source package.
▍9.1.3.1.2. Apply the patch to the code obtained from the Git repository
If you have used Git to download the source code, the situation is complicated. There are many ways to organize work with Git and related tools, and it’s quite obvious that not all Debian packages are prepared using the same workflow and software tools. The differences in packages regarding the file format already discussed are applicable here, but when working with Git, you need to find out whether patches have already been applied in the source tree or are only stored in
debian/patches (with this approach they are used during the build).
In this situation, the most popular package is
git-buildpackage . That is what we use to manage repositories on git.kali.org. When you use it, patches are not applied in the source tree in advance; instead, they are stored in debian/patches . You can manually add patches to this directory and list them in debian/patches/series , but git-buildpackage usually use the gbp pq tool to edit the entire sequence of patches as one branch, which you can expand or rebuild to suit your needs. See the gbp-pq(1) help for how to do this.
git-dpm ( ) — Git, . debian/.git-dpm , rebase debian/patches .
▍9.1.3.2.
, , . , ,
./configure , .
debian/rules , . , ( ./configure … ), ( $(MAKE) … make … ) . , , , . , , . , dh , dh_auto_configure dh_auto_build ( , , ).
, , . ,
libfreefare , --enable-debug ./configure , NFC MIFARE NFC, . , , dh , (, , ) override_dh_auto_configure . debian/rules libfreefare :
override_dh_auto_configure: dh_auto_configure -- --without-cutter --disable-silent-rules --enable-debug
▍9.1.3.3.
, . , — SET , (7.4.5), Kali ( 7.4.4). . , , - .
, ,
debian . debian/changelog .
$ apt source set Reading package lists... Done NOTICE: 'set' packaging is maintained in the 'Git' version control system at: git://git.kali.org/packages/set.git Please use: git clone git://git.kali.org/packages/set.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 42.3 MB of source archives. [...] dpkg-source: warning: failed to verify signature on ./set_7.4.4-0kali1.dsc dpkg-source: info: extracting set in set-7.4.4 dpkg-source: info: unpacking set_7.4.4.orig.tar.gz dpkg-source: info: unpacking set_7.4.4-0kali1.debian.tar.xz dpkg-source: info: applying edit-config-file dpkg-source: info: applying fix-path-interpreter.patch $ wget https://github.com/trustedsec/social-engineer-toolkit/archive/7.4.5.tar.gz -O set_7.4.5.orig.tar.gz [...] $ tar xvf set_7.4.5.orig.tar.gz [...] social-engineer-toolkit-7.4.5/src/wireless/wifiattack.py $ cp -a set-7.4.4/debian social-engineer-toolkit-7.4.5/debian $ cd social-engineer-toolkit-7.4.5 $ dch -v 7.4.5-0buxy1 "New upstream release"
That's all. .
, , , , , . — , .
9.1.4.
,
.deb . dpkg-buildpackage :
$ dpkg-buildpackage -us -uc -b dpkg-buildpackage: source package libfreefare dpkg-buildpackage: source version 0.4.0-2buxy1 dpkg-buildpackage: source distribution UNRELEASED dpkg-buildpackage: source changed by Raphael Hertzog<buxy@kali.org> dpkg-buildpackage: host architecture amd64 [...] dh_builddeb dpkg-deb: building package 'libfreefare0-dbgsym' in '../libfreefare0-dbgsym_0.4.0-2buxy1_amd64.deb'. dpkg-deb: building package 'libfreefare0' in '../libfreefare0_0.4.0-2buxy1_amd64.deb'. dpkg-deb: building package 'libfreefare-dev' in '../libfreefare-dev_0.4.0-2buxy1_amd64.deb'. dpkg-deb: building package 'libfreefare-bin-dbgsym' in '../libfreefare-bin-dbgsym_0.4.0-2buxy1_amd64.deb'. dpkg-deb: building package 'libfreefare-bin' in '../libfreefare-bin_0.4.0-2buxy1_amd64.deb'. dpkg-deb: building package 'libfreefare-doc' in '../libfreefare-doc_0.4.0-2buxy1_all.deb'. dpkg-genchanges -b >../libfreefare_0.4.0-2buxy1_amd64.changes dpkg-genchanges: binary-only upload (no source code included) dpkg-source --after-build libfreefare-0.4.0 dpkg-buildpackage: binary-only upload (no source included)
-us -uc ( .dsc , .changes ), GnuPG, , changelog . -b , . ( .dsc ), .deb-. , : , .
dpkg-deb , ( , ). dpkg -i apt install .
$ sudo apt install ../libfreefare0_0.4.0-2buxy1_amd64.deb ../libfreefare-bin_0.4.0-2buxy1_amd64.deb Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'libfreefare0' instead of '../libfreefare0_0.4.0-2buxy1_amd64.deb' Note, selecting 'libfreefare-bin' instead of '../libfreefare-bin_0.4.0-2buxy1_amd64.deb' The following packages will be upgraded: libfreefare-bin libfreefare0 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/69,4 kB of archives. After this operation, 2 048 B of additional disk space will be used. [...]
apt install , dpkg -i , apt . , dpkg , apt .deb-, .
▍- dpkg-buildpackage
Debian-, , -debuild. , ,dpkg-buildpackage, , , (lintian), Debian. , , , .debuild— ,devscripts, , , , .
Results
, , .deb-, . , , . , — , Kali, . Linux.
Dear readers! , Linux? — , .
:
→ 1. Kali Linux: ,
→ 2. Kali Linux: netfilter
→ 3. Kali Linux:
→ 4. Kali Linux:
→ 5. Kali Linux:
→ 6. Kali Linux:
→ 7. Kali Linux:
→ 8. Kali Linux:
Source: https://habr.com/ru/post/340824/
All Articles