손상된 PCAP 파일 복구는 맹목적인 변환이 아닌 증거로 시작됩니다

손상된 PCAP 파일은 최악의 순간에 조사를 중단할 수 있습니다. 캡처는 고객 현장, 연구실 재현 또는 생산 사고의 유일한 증거일 수 있습니다. 도구가 파일 열기를 거부하면 가장 빠른 충동은 이를 변환하거나 다듬거나 다른 파서를 통해 실행하는 것입니다.

그것은 효과가 있습니다. 또한 무엇이 잘못되었는지 설명하는 단서를 파괴할 수도 있습니다. 수리는 증거에서부터 시작되어야 합니다.

실패 경계 식별

파일을 변경하기 전에 어디서 실패하는지 확인하십시오.

• 전역 헤더를 읽을 수 없습니다
• 링크 유형이 예상치 못한 것입니다
• 패킷 헤더가 불완전합니다
• 캡처된 길이가 남은 파일 크기를 초과합니다.
• 원본 길이와 캡처된 길이가 일치하지 않습니다.
• 타임스탬프 필드가 잘못된 것 같습니다
• 패킷 데이터가 잘립니다.
• 마지막 유효한 패킷 뒤에 후행 바이트가 남아 있습니다.

각각의 실패는 다른 수리 전략을 의미합니다. 잘못된 전역 헤더는 잘린 마지막 패킷과 다릅니다. 잘못된 링크 유형은 체크섬 오프로드 혼란과 동일하지 않습니다.

원본 캡처 보존

원본 캡처를 덮어쓰지 마십시오. 복구 워크플로에서는 새 파일을 생성하고 변경된 내용을 기록해야 합니다. 원본 파일이 지원 사례, 법적 검토 또는 공급업체 에스컬레이션의 증거인 경우 원본 바이트가 중요합니다.

체계적인 작업 흐름은 다음을 유지합니다.

• 원본 파일 해시
• 파서 실패 위치
• 실패 전 유효한 패킷 수
• 바이트가 잘리거나 다시 쓰여졌습니다.
• 영향을 받는 패킷 인덱스
• 출력 파일 해시
• 편집이 안전한 이유를 설명하는 메모

이것은 관료주의가 아닙니다. 이것이 엔지니어가 캡처의 신뢰성을 떨어뜨리는 것을 방지하는 방법입니다.

일반적인 부패 패턴

많은 PCAP 손상 사례는 간단합니다.

• 쓰기 도중 캡처 프로세스가 중단되었습니다.
• 작성자가 파일을 닫기 전에 파일이 복사되었습니다.
• 디스크 공간이 부족해졌습니다
• 도구가 잘못된 패킷 길이를 썼습니다
• 잘못된 파일 형식의 이름이 .pcap으로 변경되었습니다.
• 링크 계층 기대치가 페이로드와 일치하지 않습니다

수리는 패턴과 일치해야 합니다. 최종 패킷만 불완전한 경우 최종 부분 레코드를 트리밍하면 유용한 접두사를 복구할 수 있습니다. 파일 전체에서 패킷 길이가 일치하지 않는 경우 다시 쓰기 전에 캡처에 대한 심층적인 검증이 필요할 수 있습니다.

수리를 정규화로 취급하지 마십시오

수리란 유효한 증거를 가능한 한 많이 보존하는 것을 의미합니다. 정규화란 데이터를 원하는 형태로 다시 쓰는 것을 의미합니다. 그것들은 다른 직업입니다.

예를 들어 타임스탬프 변경, 체크섬 재계산 또는 링크 계층 헤더 다시 쓰기는 나중에 유용할 수 있지만 이러한 작업을 첫 번째 복구 단계에 혼합해서는 안 됩니다. 먼저 신뢰할 수 있는 것을 회복하십시오. 그런 다음 통제된 수술이 적절한지 결정하십시오.

PCAP 수술이 적합한 곳

PCAP Surgery는 신중한 수집 증거 검토 및 통제된 재작성 워크플로우를 위해 제작되었습니다. 이는 광범위한 패킷 플레이어가 되거나 모든 분석 도구를 대체하려는 것이 아닙니다. 그 역할은 엔지니어가 캡처 메타데이터를 검사하고, 파일이 실패한 위치를 식별하고, 증거가 작업을 지원하는 경우에만 편집 내용을 적용하도록 돕는 것입니다.

손상된 파일의 경우 중요한 출력은 다음과 같습니다.

• 파일의 어떤 부분이 유효한지
• 구문 분석이 실패하는 경우
• 어떤 수리 조치가 적용되었는지
• 영향을 받은 패킷 또는 바이트
• 결과 파일을 다운스트림 도구로 열 수 있는지 여부

그것이 "컨버터를 가동했습니다"와 "수리를 설명할 수 있습니다"의 차이입니다.