October 24, 2017 at 13:43Kali Linux: package modification
- Transfer
We continue to translate the book Kali Linux Revealed . The ninth chapter is devoted to advanced use of the system. In particular, having studied it, you can learn about how to create exactly what you need from the basic Kali distribution. Today we are publishing a translation of the first section of this chapter. It's about modifying Kali packages.
Kali is designed as a modular, customizable, pentest-oriented environment that is highly customizable and supports a variety of usage scenarios. System customization can affect many levels. If necessary, you can start with the source code. We will consider this setting level first. The source code for Kali packages is publicly available. In this chapter, we will show how to find packages, how to modify them, and assemble custom packages from them that are configured exactly as you need. Modification of the Linux kernel is a kind of system configuration area, therefore a separate section is devoted to it. In it, we will talk about where to find the source code of the kernel, how to configure the system of its assembly, and, finally, how to compile it and compile the necessary kernel packages.
The second level of system configuration is to build live-images. We will show how to use the tool
In addition, we’ll talk about how to create a permanent data warehouse for a live image recorded on a USB flash drive. This configuration allows you to save files and changes to the operating system between reboots.
Modifying Kali packages is usually the task that project participants and developers solve: they update packages to new versions released by the developers of these packages, they change the standard configurations that allow better integration of packages into the distribution package, or fix errors reported by users. However, you may have special needs that official packages do not meet, so knowing how to build a modified package can be very useful.
You might be wondering 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 can package modifications be needed? Let's look at a few examples.
To begin with, let's say 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 the programmers who work on Kali are busy participating in the conference. As a result, you will have to update the package yourself.
Here is another situation. Let's say you are unable to get the MIFARE NFC card to work and you want to rebuild it
And finally, imagine that the program
We will consider these situations in detail below and try to generalize the explanations in such a way that you can use the presented methods in other cases. However, you 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 ask for help in suitable forums (more on this can be found in Chapter 6 , which tells how to look for answers to complex questions).
Whatever changes you want to make to the package, the overall sequence of actions always remains the same. Namely, you need to download the package source code, unzip it, make changes and compile the package. However, at each of these steps, you can usually use many tools designed to solve the same problem. Here we have selected the most suitable 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 begins by 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 over HTTP. You can use a browser to download the necessary files, but the easiest way to solve this problem is to call the command
In this example, we download the source package from the Kali mirror. This is the same package as in Debian, since the version string does not contain the substring “kali.”. This means that no Kali-specific changes have been made to this package.
If you need a specific version of the package with the source code that is not available at the time of download in the repositories listed in
After finding the URL for the source package
It is worth noting that it
Now that you have the source code, you need to install the build dependencies. They are necessary in order to assemble a binary package. They are also very likely to come in handy for partial builds, which you may need to perform to check for changes as they are introduced into the package.
In each source package, assembly dependencies are declared in the
In this example, all build dependencies can be resolved using packages that are available to APT. This may not always be the case, since the build tools
In this section it is impossible to talk about all the possible types of changes that may need to be made in a package. This would require coverage of all the intricacies 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 of the package modification process that cannot be avoided (water support in the current state of the file
The first thing to do is 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 identifying the person who makes the change (usually a private person or company). So, for example, my nickname in IRC is
If you make such changes regularly, it might make sense to make environment variables
In one of the situations described above, we downloaded the package with the source code
The need to do this is common, so there should not be any difficulties with this. Unfortunately, the features of working with patches may vary, depending on the format of the package with the source code, and on how the work with packages is organized in the Git repository (if Git is used to support the package).
So, you have executed the command
At this point, you have the source code manually patched, and you can build the binary file of the modified version of the package (we will talk about the assembly later 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 in the package code prepared by its developers (
If the package with the source code uses the format 1.0 or 3.0 (native), then the requirements for registering changes in the package code in the form of patches are not advanced. Information about changes is automatically embedded in the resulting package with the source code.
If you used Git to download the source code, then the situation is complicated. There are many ways to organize work with Git and related tools, and it is obvious that not all Debian packages are prepared using the same workflows and software tools. The difference in packages already discussed regarding the file format is applicable here, but when working with Git, you need to find out if patches are already applied in the source tree, or if they are only stored in
In this situation, the most popular package is this
A tool
Usually, you need to configure the assembly parameters in cases where you need to enable additional functions or behavior features of the package that are not activated in its official version. This is also necessary in cases when special values of parameters are required that are set during assembly by means of an option
In such cases, the changes are usually limited
In order to bring these explanations closer to practice, we apply them to one of the above scenarios. Namely, we are going to modify
Take a look at another example, as we are talking about packaging official versions of packages. Let's say you are an experienced SET user and notice that a new official release (7.4.5) has been released, which is not yet available in Kali (there is only version 7.4.4 here). You would like to collect and test the updated official package. Since there was only a slight increase in the package version, you do not expect the change to require any changes at the package level.
In order to update the code, you extract a new archive next to the current package with the source code and copy the directory
That's all. Now you can build the updated package.
Depending on the changes made to the new build of the official version, you may also need to change the build dependencies and run-time dependencies, install new files. These are much more complex operations that we do not consider here.
When all the necessary changes are made to the source code of the package, you can start creating binary files in the format
Options
How can I find out from messages
We prefer to use
In this article, we talked about how to download the source code of packages, modify it and build new .deb packages that meet your needs. These packages, after assembly, are installed on the system. This is required in a variety of cases, among which is the need to get access to the updated package as early as possible, the new version of which is not yet included in Kali, as well as the need to configure the package in accordance with some non-standard requirements. Next time we'll talk about building our own Linux kernels.
Dear readers! Have you encountered situations when you needed to modify and build Linux packages yourself? If so, please tell us why you needed it and what tools you used.
Previous parts:
→ Part 1.Kali Linux: security policy, protecting computers and network services
→ Part 2. Kali Linux: filtering traffic using netfilter
→ Part 3. Kali Linux: monitoring and logging
→ Part 4. Kali Linux: exercises to protect and monitor the system
→ Part 5. Kali Linux: assessment of system security
→ Part 6. Kali Linux: types of checks of information systems
→ Part 7. Kali Linux: formalization of studies and types of attacks
→ Part 8. Kali Linux: control questions on the study of system security
Chapter 9. Advanced System Usage
Kali is designed as a modular, customizable, pentest-oriented environment that is highly customizable and supports a variety of usage scenarios. System customization can affect many levels. If necessary, you can start with the source code. We will consider this setting level first. The source code for Kali packages is publicly available. In this chapter, we will show how to find packages, how to modify them, and assemble custom packages from them that are configured exactly as you need. Modification of the Linux kernel is a kind of system configuration area, therefore a separate section is devoted to it. In it, we will talk about where to find the source code of the kernel, how to configure the system of its assembly, and, finally, how to compile it and compile the necessary kernel packages.
The second level of system configuration is to build live-images. We will show how to use the tool
live-buildto use many opportunities for fine-tuning of ready-made ISO images. In particular, it will focus on using Debian packages pre-configured to meet your needs instead of packages available on mirrors. In addition, we’ll talk about how to create a permanent data warehouse for a live image recorded on a USB flash drive. This configuration allows you to save files and changes to the operating system between reboots.
9.1. Modification of Kali packages
Modifying Kali packages is usually the task that project participants and developers solve: they update packages to new versions released by the developers of these packages, they change the standard configurations that allow better integration of packages into the distribution package, or fix errors reported by users. However, you may have special needs that official packages do not meet, so knowing how to build a modified package can be very useful.
You might be wondering 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), change 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 dpkgand will soon become a source of problems that cannot be detected based on an analysis of the package dependencies. Moreover, correctly prepared packages can be transferred to someone else, it is much easier to deploy them on many computers, or cancel the changes in them after it was found that they do not give the desired effect. So when can package modifications be needed? Let's look at a few examples.
To begin with, let's say 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 the programmers who work on Kali are busy participating in the conference. As a result, you will have to update the package yourself.
Here is another situation. Let's say you are unable to get the MIFARE NFC card to work and you want to rebuild it
libfreefarein order to enable debugging messages and get some meaningful data that you can include in the error report that you are preparing. And finally, imagine that the program
pyritcrashes with a mysterious error message. After searching the Internet, you find a commit in the Git repository of developers, which, in your opinion, can fix this problem. Next, you are going to rebuild the package, including the fix found in it. We will consider these situations in detail below and try to generalize the explanations in such a way that you can use the presented methods in other cases. However, you 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 ask for help in suitable forums (more on this can be found in Chapter 6 , which tells how to look for answers to complex questions).
Whatever changes you want to make to the package, the overall sequence of actions always remains the same. Namely, you need to download the package source code, unzip it, make changes and compile the package. However, at each of these steps, you can usually use many tools designed to solve the same problem. Here we have selected the most suitable 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
Rebuilding the Kali package begins by 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, which may include files *.tar.{gz,bz2,xz}, sometimes files *.diff.gz, or *.debian.tar.{gz,bz2,xz}. Source packages are stored on Kali mirrors, which you can work with over HTTP. You can use a browser to download the necessary files, but the easiest way to solve this problem is to call the command
apt source source_package_name. This command requires a line deb-srcin the file /etc/apt/sources.listand current index files (you can use the command to update themapt update) By default, in Kali, the above settings are not included, since very few users need the source code of the packages, but it is very simple to bring everything to the desired state. To do this, add a line deb-srcto the file /etc/apt/sources.list(information on this can be found in section 8.1.3 “ Kali Repositories ”, and in 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 watchIn this example, we download the source package from the Kali mirror. This is the same package as in Debian, since the version string does not contain the substring “kali.”. This means that no Kali-specific changes have been made to this package.
If you need a specific version of the package with the source code that is not available at the time of download in the repositories listed in
/etc/apt/sources.list, then it is easiest to download it by first finding out the URL of its .dsc file by finding it at http://pkg.kali.org and using it in a team dget(from a package devscripts). After finding the URL for the source package
libfreefareavailable at kali-bleeding-edge, you can download it using dget. The file will be uploaded first.dsc, after which it will be parsed in order to find out what 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.xzIt is worth noting that it
dgetdoes not automatically unpack packages with the source code, since it cannot verify the PGP signatures of these packages. Thus, we need to do this manually using the command dpkg-source -x dsc-file. In addition, you can enable forced extraction of source packages by using the --allow-unauthenticatedor option -u. Conversely, you can use the option --download-onlyto skip the unpack step.▍Download source code from Git
You might have noticed that whenapt sourceyou call you are informed about the possibility of using the Git repository to support the package. It can be a Debian repository or a Kali repository.
All packages specially prepared for Kali can be found in the Git repositories located at git.kali.org . You can download code from these repositories using the view commandgit clone git://git.kali.org/packages/source-package. If during the execution of this command what you need cannot be loaded, try switching to the branch with thekali/mastercommandgit checkout kali/master.
Unlike what can be downloaded using the commandapt source, patches will not be automatically applied in the resulting tree. Take a look atdebian/patches/to find out about the possible changes made to 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 Kali developers work with these repositories, they use a different package preparation process and tools from the packagegit-buildpackage, which we are not talking about here. Details about these tools can be found here .
9.1.2. Set build dependencies
Now that you have the source code, you need to install the build dependencies. They are necessary in order to assemble a binary package. They are also very likely to come in handy for partial builds, which you may need to perform to check for changes as they are introduced into the package.
In each source package, assembly dependencies are declared in the
Build-Dependsfile field debian/control. We use aptto install these dependencies (it is assumed that you are in the directory containing the unpacked package with the 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 packages that are available to APT. This may not always be the case, since the build tools
kali-rollingdo not check the possibility of installing build dependencies (only binary package dependencies are taken into account). In practice, binary dependencies and build dependencies are often closely related and for most packages build dependencies are sufficient.9.1.3. Modifying Package Code
In this section it is impossible to talk about all the possible types of changes that may need to be made in a package. This would require coverage of all the intricacies 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 of the package modification process that cannot be avoided (water support in the current state of the file
changelog). The first thing to do is 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 identifying the person who makes the change (usually a private person or company). So, for example, my nickname in IRC is
buxy, so I will use it as a suffix. Such a change is best done using the command dch(Debian CHangelog) from the package devscripts. In my case, calling this command will look like dch --local buxy. This command calls a text editor ( sensible-editorwhich launches the editor specified in the environment variable VISUALor EDITOR, otherwise, is called /usr/bin/editor), which allows you to document changes made to a particular assembly. In this case, it can be seen that the command dchreally changed the file debian/changelog:$ 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 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 might make sense to make environment variables
DEBFULLNAMEand DEBEMAIL, accordingly, your full name and email address. This data can be used by many tools for working with packages, including the dchone that embedded them in the line starting with " --" in the above code.▍9.1.3.1. Applying patches
In one of the situations described above, we downloaded the package with the source code
pyritand are going to apply the patch that we found in the Git repository of the package developers. The need to do this is common, so there should not be any difficulties with this. Unfortunately, the features of working with patches may vary, depending on the format of the package with the source code, and on how the work with packages is organized in the Git repository (if Git is used to support the package).
▍9.1.3.1.1. Applying a patch to an unpacked source package
So, you have executed the command
apt source pyritand you have a folder pyrit-0.4.0. In such a situation, you can apply the patch directly using the command patch -p1< patch-file:$ 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 the source code manually patched, and you can build the binary file of the modified version of the package (we will talk about the assembly later 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 in the package code prepared by its developers (
unexpected upstream changes). This happened because pyrit(like most packages with source code) it uses the source code format (take a look at the file debian/source/format), known as 3.0 (quilt), where changes to the code made by the developers of the package must be recorded in separate patches, stored in debian/patches/, with the filedebian/patches/seriesindicates the order in which these patches should be applied. You can register your changes as a new patch using the command 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 with quilt
The patch agreement in question has become popular thanks to the tool calledquilt. The format of the source package "3.0 (quilt)" is thus compatible with this tool - with a slight change, which is what it usesdebian/patchesinsteadpatches. This tool can be found in the package of the same name. Here you can read the manual on it.
If the package with the source code uses the format 1.0 or 3.0 (native), then the requirements for registering changes in the package code in the form of patches are not advanced. Information about changes is automatically embedded in the resulting package with the source code.
▍9.1.3.1.2. Applying a patch to code retrieved from a Git repository
If you used Git to download the source code, then the situation is complicated. There are many ways to organize work with Git and related tools, and it is obvious that not all Debian packages are prepared using the same workflows and software tools. The difference in packages already discussed regarding the file format is applicable here, but when working with Git, you need to find out if patches are already applied in the source tree, or if they are only stored in
debian/patches(with this approach, they are used during assembly). In this situation, the most popular package is this
git-buildpackage. We use it to manage repositories on git.kali.org. When you use it, patches are not applied previously in the source tree, instead they are stored indebian/patches. You can manually add patches to this directory and list them in debian/patches/series, but users git-buildpackageusually use the tool gbp pqto edit the entire sequence of patches as a single branch, which you can expand or rearrange to suit your needs. See the help for gbp-pq(1)how to do this. A tool
git-dpm(and a team with the same name) is another tool for working with packages in Git that you may come across. It writes metadata to debian/.git-dpmand keeps patches up to date in the source tree, using the command rebaseas applied to the branch that it collects from the content debian/patches.▍9.1.3.2. Configure build options
Usually, you need to configure the assembly parameters in cases where you need to enable additional functions or behavior features of the package that are not activated in its official version. This is also necessary in cases when special values of parameters are required that are set during assembly by means of an option
./configureor by using variables set in the assembly environment. In such cases, the changes are usually limited
debian/ruleswhere the sequence of steps of the package assembly process is specified. In the simplest cases, the lines related to the original configuration ( ./configure …), or the build commands themselves ( $(MAKE) …ormake …) is easy to find. If these commands are not directly called, it is likely that they are invoked through other commands that are called explicitly. In such cases, you should refer to the documentation of these commands in order to learn how to change their standard behavior. When working with packages that use it dh, you may need to redefine the commands dh_auto_configureor dh_auto_build(see the help on them in order to learn how to do this). In order to bring these explanations closer to practice, we apply them to one of the above scenarios. Namely, we are going to modify
libfreefareby passing the option --enable-debugto the script./configureso that as a result, you can get more information from tools for working with NFC and prepare a better report on the MIFARE NFC card, which cannot be recognized. Since the package uses to control the assembly process dh, you need to add (or, in this case, modify) the target override_dh_auto_configure. Here is the corresponding extraction from the file debian/rules libfreefare:override_dh_auto_configure:
dh_auto_configure -- --without-cutter --disable-silent-rules --enable-debug▍9.1.3.3. Packing the new official version of the package
Take a look at another example, as we are talking about packaging official versions of packages. Let's say you are an experienced SET user and notice that a new official release (7.4.5) has been released, which is not yet available in Kali (there is only version 7.4.4 here). You would like to collect and test the updated official package. Since there was only a slight increase in the package version, you do not expect the change to require any changes at the package level.
In order to update the code, you extract a new archive next to the current package with the source code and copy the directory
debianfrom the current package to the new one. Then you increase the version to 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. Now you can build the updated package.
Depending on the changes made to the new build of the official version, you may also need to change the build dependencies and run-time dependencies, install new files. These are much more complex operations that we do not consider here.
9.1.4. Build start
When all the necessary changes are made to the source code of the package, you can start creating binary files in the format
.deb. The whole process runs under the control of the team dpkg-buildpackageand looks like this:$ 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
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) Options
-us -ucdisable signatures for some of the generated files ( .dsc, .changes), as this operation will fail if you do not have GnuPG keys associated with the credentials placed in the file changelog. The option is -bintended to organize the assembly process, the output of which is only binary files. With this approach, a package with source code ( .dsc) is not created , but only binary .deb packages are created. Use this option in order to avoid failures during the assembly phase of packages with the source code: if you have not registered the changes in the patch management system accordingly, warnings may occur during this operation and the assembly process will be interrupted. How can I find out from messages
dpkg-deb, the created binary packages are now available in the parent directory (in the one in which the source package directory is located). Install such packages using the dpkg -ior command 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.
[...]We prefer to use
apt installrather than dpkg -i, because it aptmakes it easy to deal with the problem of missing dependencies. True, I had to use it not so long ago dpkg, because the team aptcould not work with .deb files that are located outside the repositories.▍ Shell programs for dpkg-buildpackage
Most often, Debian developers use shell programs like to build packagesdebuild. This program, for example, startsdpkg-buildpackageas usual, but also calls a script (lintian), which performs many checks of the generated package for compliance with Debian rules. This script also cleans up the environment; as a result, local environment variables cannot affect the package build process. A teamdebuildis one of the tools included in the packagedevscripts, the tools of which, due to their uniformity, make life easier for those who support packages.
Summary
In this article, we talked about how to download the source code of packages, modify it and build new .deb packages that meet your needs. These packages, after assembly, are installed on the system. This is required in a variety of cases, among which is the need to get access to the updated package as early as possible, the new version of which is not yet included in Kali, as well as the need to configure the package in accordance with some non-standard requirements. Next time we'll talk about building our own Linux kernels.
Dear readers! Have you encountered situations when you needed to modify and build Linux packages yourself? If so, please tell us why you needed it and what tools you used.
Previous parts:
→ Part 1.Kali Linux: security policy, protecting computers and network services
→ Part 2. Kali Linux: filtering traffic using netfilter
→ Part 3. Kali Linux: monitoring and logging
→ Part 4. Kali Linux: exercises to protect and monitor the system
→ Part 5. Kali Linux: assessment of system security
→ Part 6. Kali Linux: types of checks of information systems
→ Part 7. Kali Linux: formalization of studies and types of attacks
→ Part 8. Kali Linux: control questions on the study of system security