☰

コンテクスト

tag-icon • tag-icon linux compression archiving xxd
コンテクスト

コンテクスト

これは、プログラミングとは関係がないため、誤って尋ねられた StackOverflow の質問の再投稿です。

私はOverTheWireでBanditをプレイしていますが、レベル13ファイルの拡張子を知らなくても、さまざまな圧縮ファイルを解凍する必要があります。これを行うために、私は16進ダンプとファイルシグネチャを比較してきました。ゲイリー・ケスラーのウェブサイト。

しかし、私が気づいたのは、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 0808ゲイリー・ケスラーのウェブサイトに示されているものと比較すると、署名が逆になっています。

1F 8B 08        .‹. GZ, TGZ         GZIP archive file
                        VLT         VLC Player Skin file

質問

なぜ署名が逆になっているのですか? 1F 8B 08vs. 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が 1 つの 16 ビット数値になり8B18、それがまさに表示されることになります。

xxdオプションを使用してグループ化を「1」に変更すると-g1、入力からのすべてのバイトは 1 バイトの数値 (明らかに「エンディアン性」はありません) として解釈され、入力から読み取られた順序で表示されます。

関連情報