I'd like to redirect a tcpdump sniff to scapy.scapy.sendrecv.sniff.
Did you have an idea ?
I apologize, I have no network analysis experience, but I have a question that I hope isn't too taxing for someone who has knowledge of what scapy or other packet forging programs are capable of. A "fact-check" website is claiming that scapy or other tool could be used to forge the entire network traffic of hundreds of Internet connected voting machines in the 2020 Presidential Election. The author isn't talking about capturing the traffic, supposedly, the capturing of the election traffic as already been done. He is claiming that scapy or other tool could be used to forge an 'alternative' version of the 2020 election traffic. To me, that would seem utterly impossible, because even if scapy or other tool were theoretically capable, the labor required to achieve such a feat without producing absolutely absurd, flawed results would be insurmountable. I wouldn't argue that a small sample of, say, 20 votes could be forged believably, but millions of votes or potentially tens of millions? No way, with the limited knowledge I have about network traffic.
So, am I right that it is absurd to say that scapy or other program could believably be used to forge that scale and size of network traffic?
First, here's the most recent interview with the security specialist talking about the sample capture: t.ly/hEBd
Here is an earlier interview with, I think, the same security specialist: t.ly/gdI6
Here, t.ly/slPc beginning at timecode 01:36:05 through 01:49:45, is an interview with a different security specialist that goes into more detail. This is the first and oldest video created on the subject. Still, keep in mind, these videos were created for the general public, not network professionals, so its technical content is limited.
Finally, here t.ly/OqXo is the article from the fact-check site that is asserting that scapy or other tool could be used to 'forge' the network capture of the 20 votes that were changed. Fine. I don't argue that's not potentially possible on a limited number like that. But, to claim that millions of votes could be forged in a highly credible way by scapy or a different tool ... I find that very hard to believe.
>>> TLS(hex_bytes("160301003502000031030160BE")).show() ###[ TLS ]### type = handshake version = TLS 1.0 len = 53 [deciphered_len= 8] iv = b'' \msg \ |###[ Raw ]### | load = '\x02\x00\x001\x03\x01`\\xbe' mac = b'' pad = b'' padlen = None
Hi folks, I've sniffed a DHCP Discover pkt via Scapy, and seems like the 'chaddr' field is not being read properly. Wireshark shows it just fine ('10:39:e9:7f:d5:81')!
flags : FlagsField = <Flag 32768 (B)> ('<Flag 0 ()>') ciaddr : IPField = '0.0.0.0' ("'0.0.0.0'") yiaddr : IPField = '0.0.0.0' ("'0.0.0.0'") siaddr : IPField = '0.0.0.0' ("'0.0.0.0'") giaddr : IPField = '0.0.0.0' ("'0.0.0.0'") chaddr : Field = b'\x109\xe9\x7f\xd5\x81\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' ("b''")
Any thoughts why this is not showing the actual mac address here?
###[ BOOTP ]### op = BOOTREQUEST htype = 1 hlen = 6 hops = 0 xid = 3074830325 secs = 0 flags = B ciaddr = 0.0.0.0 yiaddr = 0.0.0.0 siaddr = 0.0.0.0 giaddr = 0.0.0.0 chaddr = b'4\xef\xb6\x7f\xd5\x81\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
/etc/iproute2/rt_tablesand add routes to these tables. If I do an
ip route show table all, my routes are present, but
conf.routedoes not see them.