|debcheckroot v2.2: file only repos, some small improvements|
|debcheckroot v2.1: download as user, automatic download continuation|
|debcheckroot v2.0: rewritten in Python3|
|debcheckroot v1.0: old Perl version, worked with Debian 8|
Please sign our Contributor License Agreement if you want to contribute code. Otherwise we can not assimilate and re-distribute your changes here at elstel.org
Here is a listing on how to interprete the results in fileserror.lis:5...... md5sum does not match
The information for md5sums is fetched from the package header. All other information is extracted from the archive of a package. If the archives contain configuration files the direct comparison or the sha256sum may not match since such files can be altered automatically by installation scripts. That does not happen with md5sums as they are hand-picked by package maintainers. f.i. there seem to be some files in the aspell-en package affected by this issue. Verifying installations from more than one data carrier is directly supported from v1.99.7 on. You are prompted to insert the right media if more than one media is listed in /etc/apt/sources.list. You should be able to run this program from a clean Tails, Debian live data carrier or from a live CD of any other distribution. A dot means that the corresponding feature has been checked and was found to be ok. An underscore indicates an unchecked feature.
By default debcheckroot checks the packages in alphabetical order as they appear in /var/lib/dpkg/status. However this is a conspicuous download pattern so that intelligence services monitoring your Tor download may spot and attack you. To forgo this problem there are two options: --shuffle and --by-deps which shuffle the download order arbitrarily and which can additionally download dependent packages first. These options are mainly here for that downloads are not halted deliberately. The integrity of each downloaded archive is ascertained by the sha256sum contained in the repository index.
It is most secure to first download all required packages into ./cache and then verify offline by unplugging your network cable. You may use the --ofline option to prevent debcheckroot from trying to download missing packages. Most secure is to use three boots for a verification run: one to download, one to extract archives and generate sha256sums and one final run to verify. Extracting archives may unleash malware. See at the very bottom of this page on how to do this in detail. This does not prevent downloading packages with spoofed content though (f.i. if tor gets impersonated). The only way to avoid this is to install no updates and only from blue ray media.
If you should be attacked during a download the most likely behaviour will be that the download of a package is stalled for a more or less infinite time to make you interrupt and reinvoke debcheckroot. When you reinvoke debcheckroot it may re-download a spoofed repository description with tampered sha256sums. For every package download the sha256sum provided by the repository is checked. In order not to continue the download from a spoofed repository use the --no-repo-check-upd option. This option prevents debcheckroot from checking for an updated repository desciption. It should make debcheckroot look into the ./cache directory to get the repository description and thereby the already known sha256sums.
Basically there are two ways to verify your system: online and via BD-DL (Blue Ray Double Layer). Which choice may be the better will depend on what threat you want to shield against. If you are a company which wants to shield against criminal endeavor of other parties then we would recommend you online verification and a well configured and updated system. However if your suspected enemies are foreign intelligence services then just updating and configuring your system well can not shield you against them as these services have their own intelligence to implant and spot backdoors in oss and non-oss software also known as zero-days exploits. There are plenty of such weaknesses in any kind of software and just focusing on publicly known weaknesses by updating is ridiculous if you want to shield against intelligence. Updating may be required to shield against the malware of criminals though. For this case we provide the possiblity to download via Tails/Tor and to separate the verification from the archive unpacking; see for the section 'security considerations'.
Consequently you may choose not to update but to install from BD-DL only; that can even be an option if your computer is held online. Besides this issue you can not ultimately trust md5sums as this hashing algorithm is weak. Trailing garbage could be added to keep the md5sum. That is why we also have direct comparison / sha256sum checking. You may also simply install the same system with exactly the same packages in an empty partition from scratch by use of all the packages put in the ./cache directory and compare both root file systems file by file. This will be most effective.
The first thing to do when you experience your system being under attack is to put your machine offline and to keep it offline. Verify in a next step with BD or downloaded archives. You may perform the download by another machine than where you will run the verification task. Make sure you boot from a clean medium. Things like the Intel ME contained in all modern computers can be used by intelligence services to log in without your permission. Note that starting the verification out of an infected system may be useless (usually it is with some exceptions as unshielded mirroring of infected files between /bin and /usr/bin). debcheckroot has been designed the way that you can use it on any system that provides plain Python3. Booting from CD or SD-card with a read-only enforcing sdcard reader is recommended. debcheckroot does not do a chroot or use executables out of the infected system as would be required for debsums because this would infect your freshly booted system. The various unzip routines like the Python3-internal unxzip seem to be an attack vector though. Note that in todays world even the BIOS is an attack vector. Consequently you would have to boot a fresh system, verify or flash the BIOS and then reboot a fresh system (see: flashrom/coreboot) to start the verification. Note that the BIOS should be flashed by software not by a BIOS utility like ASUS EZ-Flash because flashing by the means of a manipulated BIOS/UEFI can be ineffective. If you buy a new computer look for flashrom as well as coreboot support; f.i. many computers from System76 have a disabled Intel ME even if you use UEFI instead of coreboot. The Intel ME can be used to log into a computer by secret services so that you may want to use a ME-free computer or do some things offline.
Things debcheckroot does not check at the moment are the initrd and the MBR (master boot record). You may unpack the initrd by hand and check the files contained there against a sha256sum list generated by debcheckroot. The MBR can first be backuped by confinedrv/diskutils. Then reinstall it with Grub from a fresh boot CD and look if the boot sector has altered. Under normal circumstances Grub would install the exactly same code into the MBR.
You may even want to unmount the hard disk and plug it into a known-to-be-clean computer for verification. Basically even the firmware of any component like the hard disk can be under attack. To place relevant malware into a firmware image it needs to be big enough though. That is just another reason why old BIOS based systems are more secure than newer UEFI based systems. By manipulating the firmware of your hard drive malware could be hidden either in additional backup blocks for use instead of bad sectors or simply on any place where your hdd returns read errors. Such errors could likely be distinguished from real hardware errors by doing a low level format of your drive with a vendor specific tool (like f.i. packed on the Ultimate boot CD): If the errors go away after flashing the HDD firmware or resetting the drive, that is somewhat suspicious.
Change to a new and empty directory where you want the files described below to reside. Then simply invoke debcheckroot /mountpoint. When you verify from CD/DVD/BD you will likely also need to specify the mountpoint with -m /media/cdrom. For a secure verification use tor, i.e. torsocks debcheckroot --download-only --by-deps /mountpoint and later on debcheckroot --offline /mountpoint. You may completely decouple the downloading from the verification: use debcheckroot --copy-config /rootdir /fakeroot to create a fake root directory only containing the configuration files necessary for downloading the required packages. Later on copy the cache directory back to the machine where the root file system you want to verify is located.
Generating sha256sums separately works by -t out.shalis --no-verify. You may always want to generate sha256sums for verifying your initrd content (use gunzip and cpio -idvu <initrd.cpio). Verifying by a previously generated list can be done with -u in.shalis --only --offline. '--only' says not to unpack and parse repository descriptions except for additional repos specified via --repo. You may still want to rename you 'cache' directory to make sure it is not accessed to make you feel 100% safe. Reboot between generation of sha256sum lists and the subsequent verification to render on-unzip-malware infunctional. The -t and -u options may be used together to extend a sha256sum list. "--packages '*'" generates sha256sums for all packages contained on DVD/Blue Ray.
The arch is set to "amd64,i386" by default. This should match for most installations. However when verifying from CD only one of these arches uses to be available. Simply ignore the warning that the other arch is not there. You need multiple arches in case if you have used dpkg --add-architecture. When you verify multiple times and you keep your cache directory you may get warnings that the sha256sums of the directory index files are not correct. This always happens on an update of the repo as that naturally also causes the checksums of the index files to change.