scapy의 수출 리눅스 조리 모드 캡처

Question

다음

간단한 exmaple 인 와이어 샤크에서 열리지 않는다 .3 및 scapy 2.2.0.

참고 : wireshark를 사용하여 smaple.pcap 파일을 직접 열 수 있습니다.

scapy 생성 pcap 파일을 wireshark에서 열려면 어떻게해야합니까?

편집 : wireshark 캡쳐 샘플에서 다른 pcap 파일을 시도해 보았습니다. 문제가 내 패킷에있는 것 같습니다.

###[ cooked linux ]### 
    pkttype = unicast 
    lladdrtype= 0x1 
    lladdrlen = 6 
    src  = '\x00\x04\xed\xcb\x9b0' 
    proto  = 0x800 
###[ IP ]### 
    version = 4L 
    ihl  = 5L 
    tos  = 0xb8 
    len  = 165 
    id  = 47433 
    flags  = 
    frag  = 0L 
    ttl  = 49 
    proto  = udp 
    chksum = 0x50c9 
    src  = 22.31.32.55 
    dst  = 192.168.1.102 
    \options \ 
###[ UDP ]### 
     sport  = 4566 
     dport  = 4566 
     len  = 145 
     chksum = 0x0 
###[ Raw ]### 
      load  = 'H\x84\x80\x80\x80\x80\x80\x8c\x80\x80\x86\x81\x8b\x82\x80\x82\x81\x98\xb1\xb9\xb2\xae\xb1\xb6\xb8\xae\xb1\xae\xb2\xb5\xad\xb0\xb1\xb2\xb2\xb6\xb6\xb5\xb7\xb4\xb9\xb4\xad\x81\xca\x82\x89\xb9\xb9\xb5\xb0\xb6\xb1\xb0\xb3\xb3\xa6\x81\x80\xa7\x81\x80\xa8\x82\x80\x80\x84\x89\xb9\xb9\xb5\xb0\xb6\xb1\xb0\xb3\xb3\x8a\x82\xe5\xee\x86\x88\xe3\xe3\xec\xe9\xe5\xee\xf4\xb2\x89\x84\x80\x80\x81\x80\xb8\x89\x80\x80\x80\x80\x80\x80\x80\x81\x80\x88\x84\x80\x80\x81\x80\xb7\x89\x80\x80\x80\x80\x80\x80\x80\x81\x80\x8c\x82\x80\x82\x9f\x84\x9e\xa7 \xe2\xb6\x80' 

참고 : 여기에 (또한 작동하지 않습니다) 첫 번째 패킷은 검사가 정확하지 않을 수 있도록 IP 주소를 변경했습니다.

Answer 1

나는 문제가 될 것으로 보인다 무슨 생각이 있지만 다음과 같은 방식으로 해결할 수 있습니다

wireshark(pkt for pkt in pkts) # don't supply a list but rather a generator 

이것은 또한 다음과 같은 메시지를 출력합니다

WARNING: PcapWriter: unknown LL type for generator. Using type 1 (Ethernet)

분명히, wireshark 함수는 Linux cooked-mode capture을 잘 처리하지 못합니다. 우리가 정말 레이어 2 프레임에 대해 걱정하지 않는 경우에, 우리는 또한 더미 이더넷 레이어를 만들어이 문제를 회피 할 수

Please remember that Wireshark works with Layer 2 packets (usually called "frames"). So we had to add an Ether() header to our ICMP packets. Passing just IP packets (layer 3) to Wireshark will give strange results.

:이 이상한 상황은 scapy's wiki에서 다음 발췌 함께 할 수있는 뭔가가있을

pkts = [Ether(src=pkt[0].src)/pkt[1:] for pkt in pkts] 

---

편집 - 추가 연구 및 scapy의 소스 코드를 분석에 따라, 나는 발전기 객체를 전달하면이 문제를 해결할 것으로 보인다 이유를 알아 냈어.

wireshark 함수는 패킷을 포함하는 임시 파일을 만들고 Wireshark를 해당 파일과 함께 시작합니다. 링크 유형은 다음의 방식으로 추출되고 그 파일의 헤더에 지정된다 :

if self.linktype == None: 
    if type(pkt) is list or type(pkt) is tuple or isinstance(pkt,BasePacketList): 
     pkt = pkt[0] 
    try: 
     self.linktype = conf.l2types[pkt.__class__] 
    except KeyError: 
     warning("PcapWriter: unknown LL type for %s. Using type 1 (Ethernet)" % pkt.__class__.__name__) 
     self.linktype = 1 

발전기 객체를 전달하는 제 if 문 False 평가 (분명 버그) 및 예외는 pkt.__class__은 conf.l2types[pkt.__class__]이므로 <type 'generator'>이므로 액세스하려고 시도 할 때 발생합니다. 따라서 try-except 코드 블록의 except 절이 실행되고 링크 유형이 1로 지정됩니다.실제리스트를 전달할 때

그러나, 제 if 문 True 평가와리스트의 첫 번째 패킷이 추출되고있다 액세스 conf.l2types으로 사용된다 : 상기 pkts[0].__class__가 scapy.layers.l2.CookedLinux이다

In [2]: conf.l2types 
Out[2]: 
    0x1 <- Dot3     (802.3) 
    0x1 <-> Ether    (Ethernet) 
    0xc -> IP     (IP) 
    0x17 -> Ether    (Ethernet) 
    0x1f <-> IPv6     (IPv6) 
    0x65 <-> IP     (IP) 
    0x69 <-> Dot11    (802.11) 
    0x71 -> CookedLinux   (cooked linux) 
    0x77 <-> PrismHeader   (Prism header) 
    0x7f <-> RadioTap    (RadioTap dummy) 
    0x90 <-> CookedLinux   (cooked linux) 
    0xc0 <-> PPI     (Per-Packet Information header (partial)) 
0x304 -> Ether    (Ethernet) 
0x321 -> Dot11    (802.11) 
0x322 -> PrismHeader   (Prism header) 
0x323 -> RadioTap    (RadioTap dummy) 

때문에 링크 유형이 0x71 (다른 버그 인 것처럼 보임)보다 0x90으로 설정되어있어 Wireshark가 파일을 구문 분석하지 못합니다.

def wireshark(*args, **kwargs): 
    """Run wireshark on a list of packets""" 
    f = scapy.all.get_temp_file() 
    scapy.all.wrpcap(f, *args, **kwargs) 
    subprocess.Popen([scapy.all.conf.prog.wireshark, "-r", f]) 

wireshark(pkts, linktype=0x71) 

---

편집 :

---

따라서, 나는 가장 좋은 방법은 명시 적으로 링크 유형을 지정하는 사용자를 허용하는 미묘한 변화, 모방 scapy의 wireshark 기능이 될 것이라고 생각 - 이제 링크 유형 매핑 문제가 secdev의 reported and fixed임을 알게되었습니다. 그러나 아직까지는 python-scapy에 도달하지 않았습니다. 또한 PcapWriter에 생성기 개체를 잘못 처리하면 a new issue을 생성했습니다.

Answer 2

(libpcap: IrDA capture has a packet with an invalid sll_protocol field)

리눅스의 IrDA는 리눅스 조리 모드 헤더 같은 을 사용하지만 동일 하 :

• Linux cooked-mode header를, (113)의 링크 계층 헤더 유형; 프로그램이 144이 아닌 113을 선택하는 원인을 모르겠어요 144

의 링크 계층 헤더 유형

Linux IrDA header

; 입력 파일이 Linux 조리 된 캡처 파일이 아닌 Linux IrDA 파일입니까?