문맥
이것은 프로그래밍과 관련이 없기 때문에 잘못 요청된 StackOverflow 질문을 다시 게시한 것입니다.
OverTheWire에서 Bandit을 플레이하고 있는데레벨 13파일 확장자를 모르고 다양한 압축 파일 형식의 압축을 풀어야 합니다. 이를 위해 hexdump를 다음의 파일 서명과 비교했습니다.게리 케슬러의 웹사이트.
그러나 내가 알아차린 것은 16진수 서명이 거꾸로 나타난다는 것입니다. 예를 들어 다음 gz, tgz gzip아카이브 파일을 사용하세요.
0000000 8b1f 0808 5006 5eb4 0302 6164 6174 2e32
0000010 6962 006e 3d01 c202 42fd 685a 3139 5941
0000020 5326 8e59 1c4f 00c8 1e00 ff7f f9fb da7f
...
8b1f 0808Gary Kessler의 웹사이트에 표시된 내용과 비교하여 서명이 거꾸로 되어 있습니다.
1F 8B 08 .‹. GZ, TGZ GZIP archive file
VLT VLC Player Skin file
질문
서명이 거꾸로 되어 있는 이유는 무엇입니까? 1F 8B 08대 8b1f 0808. 발견된 첫 번째 파일은 아카이브 파일의 16진 덤프이며 , 서명과 완벽하게 일치하는 data.txt올바른 서명 1f8b 0808(을 사용하여 발견됨 )을 가지고 있습니다. head data.txt그러나 달리면 xxd -r data.txt | hexdump다시 한번 8b1f 0808.
내 StackOverflow 질문에 대한 의견은 이것이 빅/리틀 엔디아와 관련이 있음을 나타내는 것으로 보이며 그룹화를 의미하는 -g1플래그를 가리켰습니다.xxd
이것은 올바른 출력을 제공하지만 그룹화가 무엇인지, 어떻게 작동하는지 이해하지 못합니다.
답변1
그룹화는 xxd하나의 단위로 처리(및 표시)되는 바이트 수를 나타냅니다.
기본적으로 xxd입력은 빅엔디안 순서로 저장된 2바이트/16비트(4자리 16진수) 그룹으로 처리됩니다.
이는 입력에서 2바이트의 모든 그룹이 역순으로 표시되는 효과를 갖습니다(그러나 실제로는 빅엔디안 시스템의 경우 올바른 순서입니다).
즉, 입력의 처음 2바이트는 18 8B하나의 16비트 숫자가 되며 8B18, 이것이 바로 여러분이 보는 것과 같습니다.
xxd옵션을 사용하여 그룹화를 "1"로 변경하면 -g1입력의 모든 바이트는 단일 바이트 숫자(분명히 "엔디안"이 없음)로 해석되어 읽은 순서대로 표시됩니다. 입력.