Absolute 0
(This is part 2. Part 1 is here.)
Mike Lindell’s video Absolute 9–0 is filled with lies.
While the flaws in his previous video required some research to uncover, the deceptions in this video are more obvious. Mike claims he hired a cybersecurity expert to verify the data. Mike lists, vaguely, the man’s credentials and experience. But this so-called expert lies repeatedly and gratuitously. Let’s examine 7 of his claims.
Lie 1: Hexdump as Encrypted Data
At 2:28, the so-called expert displays numbers running across the screen and calls it the “raw encrypted data” of network packets that were captured on election night. These are Mike’s famous pcaps!
Yet the format is clearly hex encoding, with the last byte of each line hidden by the end of the window. As Wikipedia explains:
“Hexadecimal numerals are widely used by computer system designers and programmers because they provide a human-friendly representation of binary-coded values. Each hexadecimal digit represents four bits (binary digits)… For example, an 8-bit byte can have values ranging from 00000000 to 11111111 in binary form, which can be conveniently represented as 00 to FF in hexadecimal.”
But could this be the hex encoding of an encrypted file? No, because the output of an encryption algorithm is a pseudo-random cipher text, and this output is not pseudo-random. To demonstrate this, let’s first look at a real cipher text.
Say I have a low entropy file called nonrandom.txt that contains the letter a 10 times in a row. (The letter a is 61 in hex.) Using the openssl command, I can encrypt nonrandom.txt with the AES-128-CBC algorithm and save it to a new file called encrypted.txt, using a single letter a as the encryption password. If I then use a program called od to look at the hex encoding of the encrypted file, I’ll find a high-entropy, pseudo-random output. In other words, even a file with obvious patterns won’t have obvious patterns when encrypted.
$ cat nonrandom.txt
aaaaaaaaaa
$ od -x nonrandom.txt
0000000 6161 6161 6161 6161 6161 000a
0000013
$ openssl aes-128-cbc -in nonrandom.txt -out encrypted.txt -iter 1
enter aes-128-cbc encryption password:
Verifying — enter aes-128-cbc encryption password:
$ od -x encrypted.txt
0000000 6153 746c 6465 5f5f 7d35 a5ee 437c 084d
0000020 2363 d3c5 9eee 003b aece d921 39af fd1a
0000040The above is what the hex encoding of an encrypted file looks like.
Look again at the so-called expert’s “raw encrypted data.”
Notice one pattern that occurs frequently: 27 2C 27. This is not the pseudo-random, high-entropy output of an encryption algorithm. Even without decoding this hex, you can tell it’s not encrypted.
But if it’s not encrypted, what does it mean?
If you use an Hex-to-ASCII chart, you’ll see 27 in hex is a single quote and 2C in hex is a comma. To find out what the whole screenshot means, save the first picture above, crop out the top and left side, and upload it to a website that does online OCR (optical character recognition), like this one. Then paste the hexadecimal output from the OCR site into a website that does Hex to ASCII conversions, like this one.
What is the result?
Lie 2: This is a packet capture file.
At around 3:30, Mike’s expert calls the scrolling hex a pcap file recorded on election night. But the so-called expert is lying: this is not a pcap file.
Keep in mind that as the hexadecimal scrolls, the window hides the last byte. Because the OCR conversion lacks every 16th byte, the decoded ASCII drops every 16th character. Even with that limitation, it’s unquestionably not a packet capture file. Instead, the file looks like a database file.
Here’s the decoded hex output (with names and addresses redacted):
I’ve converted many screenshots of these fake pcaps. Each one is a record of voters from PA. That sounds serious! Could someone have hacked the database and stolen the voter rolls? Certainly, but it’s far more likely that someone just purchased it directly. In PA, voter rolls are public. See 25 Pa.C.S. § 1404.
As the pa.gov explains on their PA Full Voter Export site:
As provided by 25 Pa.C.S. Section 1404(b)(1) (relating to Public Information Lists), as well as the SURE Regulations at 4 Pa. Code Section 184.14(b) (relating to Public Information Lists), the Department of State will provide the Full Voter Export List to requestors.
This version of the Public Information List is a full export of all voters in the county and contains the following fields: voter ID number, name, sex, date of birth, date registered, status (i.e., active or inactive), date status last changed, party, residential address, mailing address, polling place, date last voted, all districts in which the voter votes (i.e., congressional, legislative, school district, etc.), voter history, and date the voter’s record was last changed.
The cost of the Full Voter Export list is $20.00. Upon successful payment an email will be sent to the provided email address.
Here’s the form, if you want to request the PA voter roll for yourself.
The so-called expert paid $20 to get the voter roll from PA, converted it to hex, and then claimed it was a pcap. If he wanted a more convincing fake, he could have at least recorded his own traffic while he was downloading the file from the PA Department of State. That fake at least would have been a pcap.
Lie 3: You can’t fake a pcap.
At 4:10, the so-called expert says, “You can’t go back in time and fake a pcap.”
Here is a screenshot of Wireshark showing a packet capture I ran while sending a single ping request to Google. In the top row, you can see both the request and the response. The request is selected and, in the middle window, you can see that I highlighted the source IP address of my laptop, 192.168.37.206 (in hex, c0 a8 25 ce).
I saved this file as pingGoogle.pcap. Next I created a copy called fake.pcap, and then modified the file to switch my IP address to 1.1.1.1 in both the request and response. Moreover, I did this using sed, a common tool available on almost every version of Linux or Mac.
sed -Ei 's/\xc0\xa8\x25\xce/\x01\x01\x01\x01/g' fake.pcapThe screenshot below shows the fake pcap, which appears to show a ping from 1.1.1.1 (owned by CloudFlare) to 142.251.40.238 (owned by Google). Obviously, I didn’t record packets from CloudFlare to Google. Obviously, I don’t have a position within or between their networks from which I can record inter-network traffic. To create a more convincing forgery, I’d also want to recalculate the header checksums, but that’s easy to do. Python’s scapy library can automatically recalculate checksums after editing the source or destination IP in a pcap (as this example script does).
The point here is that pcaps can be faked. Easily faked.
Lie 4: Hash values for the pcaps prove they are authentic.
At 6:10, the so-called expert says:
There’s hash values which are unique to each item. Any change to that, it’ll change the hash. That’s how you verify images, or the pcap in this case. So when you’re looking at, you know, this file, you make sure it hasn’t been doctored or anything’s been done to it. Because when you do the work, it needs to match that original file.
This sounds reasonable but the argument’s nonsense. Because hashes aren’t included in IP headers, the so-called expert may be confusing checksums with cryptographic hashes. As the article linked to above explains, every IP packet includes checksums to verify the data was not corrupted in transmission. But non-corrupted data isn’t the same as accurate data.
A cryptographic hash is only valuable for verifying the authenticity of a file if the hash itself comes from a trusted authority. For example, let’s say I give you a pcap and say, “This pcap proves that CloudFlare is sending ICMP packets to Google. To prove it, here’s the SHA256 hash of the file.” So you download my fake pcap file and calculate its hash. It matches the hash I’ve given you! Does this prove CloudFlare is sending ICMP packets to Google? No. Because I calculated the hash of the file after I modified it.
$ sha256sum fake.pcap
dc48ae785492c44da0c8e7c266d70b530b19cbdd33e63f7b0d336195769a436b fake.pcapBecause you can fake pcaps and then calculate the hash before distributing them, the so-called expert’s argument is nonsense. It’s also nonsense because the scrolling screen of hex doesn’t actually contain, you know, an actual hash.
Lie 5: Translating pcaps takes a long time.
At 7:41, Mike says, “That’s what took so long. I believe it’s been a couple months now I’ve had yourself and many others validating and translating these CPACs. [sic]”
It doesn’t take months to “translate” pcap files. Like many other pcap tools, Wireshark instantly decodes headers at every network level as soon as you start a new capture or open a pcap file. The only reason it took months is because these con men have found a mark who’s gullible enough for a long-lasting con.
Lie 6: Those 20 pcaps contain.
Mike and his so-called expert claim he verified 20 pcaps and, at 9:45, he displays the chart below. Keep in mind that the scrolling hex output is just the voter roll of PA that anyone can buy for $20. It’s not a pcap. It’s not network traffic. It was never a record of traffic — on election night or any other night. Therefore his “translation” is all made up. He just created a spreadsheet and added random Chinese IP addresses into the chart. Yet despite faking a translation of his fake pcap, the so-called expert still didn’t avoid making mistakes.
Including latitude and longitude is a little strange since IP packets don’t contain that information. It resembles the sleight of hand used in the scrolling hex: “Oh look at all these very specific numbers; that proves it!” The so-called expert makes the bizarre claim that the latitude and longitude coordinates in his fake table are accurate within 400 yards (0.365km) of where the computer is located. Yet line 3 claims the IP 202.112.126.88 is located at 39.9696,116.319, which is Renmin University in Bejing; the whois information shows it belongs to Tsinghua University, a university also in Bejing but about 6km away. However, ignore these minor inconsistencies.
What does the latitude and longitude in the second table mean? It appears to show the exact locations of the target — the hacked U.S. election machine. Except that these locations are not only in China but also in the middle of nowhere. Look them up. Line 1 is in a desert; line 3 is in a forest; line 5 is also in a forest; line 6 appears to be farmland; line 7 is the same forest as line 3; line 8 might be a rock query; line 10 is in the mountains; line 11 is also in the mountains; lines 12 and 13 are on a deserted road that passes south of the mountains; lines 14 and 15 appear to be farmland; line 16 also appears to be farmland; line 17 is in the mountains; line 18 is the same as lines 14 and 15; lines 19 and 20 are also in a desert.
I realize all this information is fake, since there are no pcaps. But why include random geolocations in his fake chart? For one simple reason: most people aren’t going to check them and they lend credibility to the conclusion. They look real, definite, and convincing; but they are actually real, definite, and irrelevant. He’s not geolocating election devices in the U.S. that have been hacked; he’s geolocating random Chinese landscapes.
Lie 7: This is irrefutable.
Mike makes this claim but, well, clearly not.
