Cheat Sheet - jonelo/jacksum GitHub Wiki
This cheat sheet covers the usage of Jacksum on the command line.
It is good practise to explicitly specify the algorithm(s) with option -a, because the default algorithm could change in later releases. You also should specify how the hash value should be encoded for the output, because by default the encoding depends on the algorithm (a checksum usually is encoded in decimal, while one-way hash function is usually encoded in hex). Alternatively you can use a compatibility file which specifies the algorithm, the encoding of the hash value and the output format. A compat file also has regex information for the parser to read checkfiles again. A compat file can set a lot of command line options for you. In this case we use the linux comatibility file and we overwrite the options that are coming from that file with our own algorithm selection. For more information about compatibility files enter jacksum -h -C
jacksum -a sha3-256 -C linux -O checkfile .
If you specify the same folders that you entered while you were calculating the hashes, Jacksum can also detect files that have been added after the checkfile was created.
jacksum -a sha3-256 -C linux -c checkfile .
On Debian there are precalculated hash files located in /var/lib/dpkg/info/. MD5 hashes are used, and the paths are stored relatively to the root folder. With Jacksum you can verify those packages by using the linux style for reading, and making the paths absolute by specifying the option --path-relative-to /. Example to verify files from the sudo package:
jacksum --check-file /var/lib/dpkg/info/sudo.md5sums --style linux -a md5 --path-relative-to /
If you want to verfiy packages including all their dependencies you could install the debsums package and call rdebsums.
Jacksum supports algorithm filtering. Since all algorithms have the "sha" in the name, you can simply search for that string by using -a all:sha.
By default all algorithms that have been found are concatenated togeter by a + sign. You can get the full list by entering jacksum -a all:sha --list or jacksum -a all:sha --info. By default also all message digests are concatenated together as bytes, because it is very easy to perform integrity checks on single hashes only. If you want to list the hashes for each algorithm separately you can use option -F. To get more information about the format option, enter jacksum -h -F. The dot at the end of the command represents the current working directory. In order to output all hashes in the BSD-format from all files in and below the current working directory, the full command would be:
jacksum -a all:sha -F "#ALGONAME{i}(#FILENAME) = #HASH{i}" .
If you don't want to see the obsolete SHA-0, and also not the SHAKE-algorithms which are also part of the result of the search, you have to enter all algorithms explicitly, separated by a comma. Again, to make things easier you can use jacksum -a all:sha --info and copy and adjust the long algorithm identifier. So the following command would calculate all SHA-1, SHA-2-, and SHA-3 hahses from all files recursively starting in the current directory.
jacksum -a sha1+sha224+sha256+sha384+sha512+sha512/224+sha512/256+sha3-224+sha3-256+sha3-384+sha3-512 -F "#ALGONAME{i}(#FILENAME) = #HASH{i}" .
We want to create a csv with fields "name,input data (as hex),hash (as hex)", input data should be the string "0123456789".
jacksum -a all:crc -F "#ALGONAME{i},#SEQUENCE,#HASH{i,hex}" -q txt:0123456789
Result (for Jacksum 3.3.0)
crc8,30313233343536373839,45
crc16,30313233343536373839,443d
crc16_minix,30313233343536373839,f833
crc24,30313233343536373839,d08ea3
crc32,30313233343536373839,a684c7c6
crc32_mpeg2,30313233343536373839,694f1b1f
crc32_bzip2,30313233343536373839,96b0e4e0
crc32_fddi,30313233343536373839,9d14a594
crc32_ubi,30313233343536373839,597b3839
crc32_php,30313233343536373839,e0e4b096
crc32c,30313233343536373839,280c069e
crc64,30313233343536373839,469959388a5beffe
crc64_ecma,30313233343536373839,2a71ab4164c3bbe8
crc64_go-iso,30313233343536373839,b966f5c775a41001
crc64_xz,30313233343536373839,2765cf2c7f12731e
fcs16,30313233343536373839,3c16
In this example we are gathering hashes from all log4j*.jar files that are vulnerable to CVE-2021-44832 and store the hases in Linux style to log4j.hashes. We use the SHA3-256 hash function, because it is a modern, non-broken cryptographic hash function which minimizes hash collisions resp. false positives.
jacksum --header -a sha3-256 --style linux -O log4j.hashes --no-path .
Content of the file called log4j.hashes ...
#
# created by: Jacksum (https://jacksum.net, version: 3.4.0)
# invoked on JVM: OpenJDK 64-Bit Server VM (vendor: Eclipse Adoptium, version: 11.0.14.1+1)
# invoked on OS: Windows 10 (arch: amd64, version: 10.0)
# invoked on date: 2022-06-22T21:55:28.273+02:00
#
# invoked from: X:\log4j\CVE-2021-44228
# invocation args: --header -a sha3-256 --style linux -O log4j.hashes --no-path .
#__________________________________________________________________________________________
df6b2529d9c3de4ad32e5adc798faaf6165fbd2f701eda7897eea5cfe2791c51 *log4j-api-2.10.0.jar
848eb8989417cf96cabb5038913705cc95e8304e3c7df2f5394d5ec15d99ac1b *log4j-api-2.11.1.jar
d82d35aae99b11d7873127014043f992d62f56947f7898ca0b0f0f06ea2e10d7 *log4j-core-2.0-beta9.jar
d65893e3bc37718b47e722cb5aa01934b7a66668a4817c9cf436a216b5ff3d99 *log4j-core-2.0-rc1.jar
a6fa4ac90b50b07e19c9db597f23bf804145e5a84737e91e3a149b495d554b0c *log4j-core-2.0-rc2.jar
955da4ec2c54503cb9d126bb90174b9d4a8f65a60c03f6d637552b8bc2fef7a7 *log4j-core-2.0.1.jar
b2ef74c8ebb7ee6b3221624955f1ed20bf6c1e6d3f2683b67eb00dd5be47f5cb *log4j-core-2.0.2.jar
691c19abd32c46f193ed3287833c863caf247f2fe64341d2a5e562c0c3426587 *log4j-core-2.0.jar
80037efc5d633086779ca6cc7da536bb7749480b7e5a77c6feadcadc36df5382 *log4j-core-2.1.jar
858bd59969e1c64819c35bfb069ff1993d1b2d398c0f87f3fea8416aef2dea33 *log4j-core-2.11.0.jar
690f8ad7ee5adc76fe40675ecc7e53087ce247a3a1cd62dc9cf07a2757d5d00f *log4j-core-2.11.2.jar
27505ffbe23b56842e3a3d86f4693227fc3317900d18585ea380327aaf7350d3 *log4j-core-2.12.0.jar
367caa655a59472f6a3861480d9b99514433d8b1fd1953551f1ad08869750109 *log4j-core-2.12.1.jar
48ceffa2f5cb234c61e82ebaf57545ff8ec5533825b80dfad4d2a6a8906a6d50 *log4j-core-2.13.0.jar
5c7c616827030182d4c6fdaacd9a5d2fb404a3618092100d92a37f2bcd46c68f *log4j-core-2.13.1.jar
ca717afc2f1e9e9d44b2a00f3a5a6a88e6678d4fd9dbd78563cf9efb733e525a *log4j-core-2.13.2.jar
4239b4eba17707c6c79f01db81f9b7471ef9219f89fd1aff188b236eaf4c11c5 *log4j-core-2.13.3.jar
0b26d2565d086dbdfd174ba18bb6d90f68272917938110f8d51195d90d22f8fd *log4j-core-2.14.0.jar
f7f790e89c2fc92996c518e9f1705a7aadc9c21caecfd4ac8cb44574118a2ed3 *log4j-core-2.14.1.jar
574e817f7bded7f5fadaf1fb8ac2dad37bb316e023dcb6ae4dff884ab222e653 *log4j-core-2.2.jar
ce53977055fe2a2490b7a122ced30e007ca5cf1857f2b3fd80b3bbc6b18863b2 *log4j-core-2.3.jar
600bf903ca1fa3abe0040b47885e1e55d358068a16581f910d470be5969c94da *log4j-core-2.4.1.jar
0e0fa79d6281a70577b662b0ef276569a745796bf9ed8be5bce4b7875e568995 *log4j-core-2.4.jar
f2f51dba05c976cace911a0dd4a748051acfc1a52a5de7a4a663afa890c79c24 *log4j-core-2.5.jar
c0ed39397f308807bc53c7dd6958745dff16b90f044c2639ad98da78c85746aa *log4j-core-2.6.1.jar
8146d62443ed4b64dd0ebc91864a1a375f2e3123a83685f571de02ec9293573b *log4j-core-2.6.2.jar
48f064dbfc48bac0bcc3a2e1f4c9b72b2da62d82b0f248459a3c26a121db5d62 *log4j-core-2.6.jar
85b00d65e5bdc0373cfa48f710ab02a9527e6c4e232415ac204ea652b4032954 *log4j-core-2.7.jar
8c41f9773ba79a48716225a7ec560184cacfbc20d09012ea5187262d05e63b4f *log4j-core-2.8.1.jar
751fcac9bfb014e18c9c05bf5d070c1485cfe4c676eedd8281ab1b1564a90304 *log4j-core-2.8.2.jar
6dd7790aece8119e5b2ad6a489e9b622d10e9e24973d9fc3683f7dc464b5d60a *log4j-core-2.8.jar
62b4af8260d4a21c529674661e0e66c65707b17b09a97ec3ff6bdf237092b21b *log4j-core-2.9.0.jar
2eebdfdffdf1c62fc3cd6dba2626ee102f71416b409a40cfac5ccdf40ad1199f *log4j-core-2.9.1.jar
We take the log4j.hashes from above and search the entire server for those hashes. The log4j.hashes file has been stored in linux style so we specify that - although we don't need to, because the default parser also understands the Linux style format. Since we are only interested in the matches, we can rely on the default filter settings, but if you like you can specify the filter explicitly by setting --wanted-list-filter match. Since the files on that system have been stored on a SSD we will benefit from increasing the number of threads while reading files in parallel. This can be done by setting --threads-reading to a reasonable value.
jacksum --wanted-list log4j.hashes --style linux --threads-reading 8 /
standard output ...
MATCH \log4j\CVE-2021-44228\log4j-api-2.10.0.jar (log4j-api-2.10.0.jar)
MATCH \log4j\CVE-2021-44228\log4j-api-2.11.1.jar (log4j-api-2.11.1.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.0-beta9.jar (log4j-core-2.0-beta9.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.0-rc2.jar (log4j-core-2.0-rc2.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.0-rc1.jar (log4j-core-2.0-rc1.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.0.1.jar (log4j-core-2.0.1.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.0.jar (log4j-core-2.0.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.0.2.jar (log4j-core-2.0.2.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.1.jar (log4j-core-2.1.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.11.0.jar (log4j-core-2.11.0.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.12.0.jar (log4j-core-2.12.0.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.11.2.jar (log4j-core-2.11.2.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.12.1.jar (log4j-core-2.12.1.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.13.0.jar (log4j-core-2.13.0.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.13.1.jar (log4j-core-2.13.1.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.13.2.jar (log4j-core-2.13.2.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.13.3.jar (log4j-core-2.13.3.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.14.0.jar (log4j-core-2.14.0.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.2.jar (log4j-core-2.2.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.3.jar (log4j-core-2.3.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.4.1.jar (log4j-core-2.4.1.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.14.1.jar (log4j-core-2.14.1.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.4.jar (log4j-core-2.4.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.5.jar (log4j-core-2.5.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.6.1.jar (log4j-core-2.6.1.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.6.2.jar (log4j-core-2.6.2.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.6.jar (log4j-core-2.6.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.7.jar (log4j-core-2.7.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.8.1.jar (log4j-core-2.8.1.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.8.2.jar (log4j-core-2.8.2.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.8.jar (log4j-core-2.8.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.9.0.jar (log4j-core-2.9.0.jar)
MATCH \log4j\CVE-2021-44228\log4j-core-2.9.1.jar (log4j-core-2.9.1.jar)
Jacksum: total lines in check file: 42
Jacksum: improperly formatted lines in check file: 0
Jacksum: properly formatted lines in check file: 33
Jacksum: ignored lines (empty lines and comments): 9
Jacksum: correctness of check file: 100.00 %
Jacksum: files read successfully: 252299
Jacksum: files read with errors: 3
Jacksum: total bytes read: 117670015750
Jacksum: total bytes read (human readable): 109 GiB, 602 MiB, 892 KiB, 774 bytes
Jacksum: files matching wanted hashes: 33
Jacksum: files not matching wanted hashes: 252266
Jacksum: elapsed time: 8 min, 38 s, 215 ms
See also CVE-2021-44832: Find vulnerable .jar files using Jacksum
jacksum -a unknown:16 -q hex:050000 -E hex -e d893
Finds all algorithms with a digest width of 16 bits that produces the hex output d893 for the hex input 050000.
Result
Trying 13 algorithms with a width of 16 bits that are supported by Jacksum 3.0.0 ...
Trying 30 CRC algorithms with a width of 16 bits by testing against well known CRCs ...
crc:16,1021,FFFF,false,false,FFFF
--> CRC-16/GENIBUS
Trying all CRC algorithms with a width of 16 bits by brute force (be patient!) ...
crc:16,1021,FFFF,false,false,FFFF
crc:16,37D2,FFFF,true,false,FFFF
crc:16,3E2D,0000,true,false,FFFF
crc:16,4175,FFFF,true,false,FFFF
crc:16,4A5B,FFFF,true,true,0000
crc:16,5A41,FFFF,true,false,FFFF
crc:16,5C63,FFFF,true,true,0000
crc:16,6287,FFFF,true,true,0000
crc:16,649C,0000,false,true,FFFF
crc:16,6D55,FFFF,true,true,0000
crc:16,75AC,FFFF,true,false,FFFF
crc:16,7D64,FFFF,false,false,FFFF
crc:16,81A6,FFFF,true,false,FFFF
crc:16,B9F9,FFFF,true,true,0000
crc:16,C3D6,FFFF,false,false,FFFF
crc:16,D436,0000,true,false,FFFF
crc:16,D6D2,0000,false,true,FFFF
crc:16,DA9C,FFFF,true,false,FFFF
crc:16,E03E,FFFF,false,false,FFFF
crc:16,F701,FFFF,true,false,FFFF
Jacksum: algorithms tested: 1048620
Jacksum: algorithms found: 21
Jacksum: elapsed time: 6 s, 460 ms
Means Jacksum has tested more than one million algorithms in about 7 seconds and it found 21 matching algorithms. Each of those returns the same CRC value. Test with more input/output sequences and/or longer input sequences in order to find the right algorithm. The most likely algorithm is printed with a name if it is a well known CRC. In this example it has been identified as the CRC-16/GENIBUS.
Once you have identified the correct algorithm, you can calculate your own input data using the CRC definitions that have been found.
jacksum -a crc:16,1021,FFFF,false,false,FFFF -E hex -q txt:"Hello World"
jacksum --info
or
jacksum -a all --list