동반된 정의를 모르더라도 Google Protobuf로 인코딩된 blob(버전 2 또는 3)을 구문 분석할 수 있는 간단한 프로그램입니다. 내용을 멋지고 컬러로 표현한 내용이 인쇄됩니다. 예:
보시다시피, 다음과 같은 일부 상위 수준 세부정보와 함께 필드 이름이 분명히 손실되었습니다.
그러나 protobuf-inspector는 대부분의 경우 메시지 구조를 정확하게 추측할 수 있습니다. 필드에 포함된 이진 데이터를 찾으면 먼저 이를 메시지로 구문 분석하려고 시도합니다. 실패하면 데이터가 문자열 또는 16진수 덤프로 표시됩니다. 특히 작은 덩어리에서는 실수를 할 수 있습니다.
이는 와이어에서 인코딩된 순서대로 필드를 표시하므로 리버스 엔지니어링 외에도 와이어 형식이나 파서 개발자에 익숙해지려는 사람들에게 유용할 수 있습니다.
pip로 설치할 수 있습니다:
pip install protobuf-inspector
그러면 protobuf_inspector
명령이 설치됩니다. 이를 실행하여 stdin에 protobuf blob을 공급합니다.
protobuf_inspector < my-protobuf-blob
Blob의 첫 번째(블라인드) 분석을 읽은 후 일반적으로 전체 protobuf 정의가 있고 파서가 더 이상 그럴 필요가 없는 지점에 도달할 때까지 protobuf-inspector가 blob을 더 잘 구문 분석할 수 있도록 일부 필드를 정의하기 시작합니다. 무엇이든 추측해 보세요.
여기에서 필드 정의에 대해 읽어보세요.
구문 분석 오류가 발견되면 해당 필드 내에서 구문 분석이 중지되지만 계층 구조 외부에서는 영향을 받지 않고 계속 진행됩니다. 적용 가능한 경우 해당 청크에서 구문 분석이 중지된 위치를 나타내는 hexdump와 함께 필드 내용이 이동하는 위치에 스택 추적이 인쇄됩니다.
따라서 uint32
를 지정했는데 더 큰 varint가 발견되면 다음과 같은 결과를 얻게 됩니다.
일부 필드에 포함된 메시지가 포함되어 있다고 지정했지만 거기에서 잘못된 데이터가 발견되면 다음과 같은 결과가 나타납니다.
하나 이상의 구문 분석 오류가 발생하면 main.py
0이 아닌 상태로 종료됩니다.
Blob에 접근할 때 시간을 절약하기 위해 사용할 수 있는 몇 가지 요령이 있습니다.
varint가 지그재그 인코딩을 사용하지 않는다고 확신하지만 여전히 signedness가 확실하지 않은 경우 varint
로 두십시오. 지그재그 인코딩을 사용하는 경우 64비트가 아니라 32비트인지 확실하지 않은 한 sint64
사용하십시오.
청크가 packed chunk
나 포함된 메시지로 잘못 인식되는 경우 또는 구문 분석된 메시지에 이상한 내용이 있어 원시 바이트를 확인하려는 경우 bytes
유형을 지정하세요. 반대로, 어떤 이유로든 포함된 메시지로 감지되지 않고 감지되어야 하는 경우 message
로 강제 실행하여 이유를 확인하세요.
더 나은 분석을 위해 청크의 원시 데이터를 파일로 추출하려는 경우 dump
유형을 지정하면 protobuf-inspector는 일치하는 blob을 찾을 때마다 dump.0
, dump.1
등을 생성합니다.
protobuf-inspector는 blob을 root
유형의 메시지로 구문 분석하지만 이는 단지 기본값일 뿐입니다. 정의된 메시지 유형이 많은 경우 유형 이름을 선택적 인수로 전달할 수 있으며 protobuf-inspector는 root
대신 이를 사용합니다.
protobuf_inspector request < my-protobuf-blob
간단한 예:
from protobuf_inspector . types import StandardParser
parser = StandardParser ()
with open ( 'my-blob' , 'rb' ) as fh :
output = parser . parse_message ( fh , "message" )
print ( output )
하지만 이 프로젝트는 처음에는 라이브러리로 사용하도록 설계되지 않았으므로 해당 API가 변경될 수 있습니다. 더 복잡한 예를 보려면 protobuf_inspector/__main__.py
참조하세요.