LHAフォーマット

LHAが使うコンテナーフォーマットは、LArcのものの拡張である。

基本的には各ファイルごとに、次の構造になる。

[ヘッダー1][データ1][ヘッダー2][データ2]…[ヘッダーn][データn][00h]

ヘッダーは格納ファイルに常にあるが、データは無いことがある。LHA v2.14以降で対応した-lhd-(ディレクトリ名の格納)は、データサイズ0でありデータがない。

ヘッダーの最初の1バイトは基本ヘッダーそのものの長さとなっている。ここが00hとなると、それがファイル末端であることを表わす。

ヘッダーは、次のような構造をしている。

[基本ヘッダー][拡張ヘッダー1][拡張ヘッダー2]…[拡張ヘッダーn][0000h]

LHAのヘッダー形式はLEVEL 0/1/2の三種類がある。略してH0/H1/H2のように呼ばれる。LArcおよびLHarc(LHA 1.xx)はLHAでいうLEVEL 0に対応し、LEVEL 1/2はLEVEL 0の拡張である。

拡張ヘッダーはLEVEL 1/2で対応し、LEVEL 0には存在しない。

拡張ヘッダーの最初の2バイトは拡張ヘッダーそのものの長さとなっている。ここが0000hとなると、それが拡張ヘッダー末端であることを表わし、この後に(あれば)データが続く。

「基本ヘッダー」は、ファイルの基本的な情報を記録する領域である。タイムスタンプ、CRCなどはここにある。

「拡張ヘッダー」は、付加的な情報を格納するために使われる。この数も任意で、複数のヘッダーを持つことも可能。

なお、WORD以上の長さを持つパラメーターは、リトルエンディアンで値が格納される。

最も古い形式の基本ヘッダーで、LArc用に作られ使われた。LHarcもこの形式で、LHAであってもDOS版の自己解凍書庫はこのヘッダー形式である。

1バイト目が基本ヘッダーの長さで、最大255なので、実際の基本ヘッダー長の最大長は257バイトということになる。

ファイル名はパスも含む。パスのデリミター文字は、'\'か'/'である。ASCIIZではないので、末端にNULは無い。

ヘッダー全体の長さが最大257バイトであるため、逆算してファイル名・パス名の最大長は233バイトになる。

拡張データは通常使われないが、UNIX版LHaでは、ファイル属性、ファイル更新日時、UID/GID属性などOSに必要な情報を格納しているとされる。UNIX関係の情報は、LEVEL 1では正規の方法で格納可能になった。

LHA 2.1x〜2.5xで標準となっているもの。拡張ヘッダーが追加され、付加的な情報はそちらに回されている。

UNLHA32.DLLにはLEVEL 3のヘッダーがあることが知られているが、使われていない。

基本ヘッダーの仕様が若干異なるほか、拡張ヘッダーの仕様も変更されており、拡張ヘッダー長領域がDWORDに拡張されている。

LEVEL 3では、LEVEL 2に加え、次の拡張ヘッダーが利用できる。

• 3fh : コメントヘッダー

UNLHA32.DLL ver 2.39a以降で、Unicodeファイル名にも対応した。

ファイル名とディレクトリ名について、それぞれ拡張ヘッダーが用意されている。

Unicodeファイル名は、次のヘッダーに格納する。

Unicodeディレクトリ名は、次のヘッダーに格納する。

シフトJISで扱えない文字を含む場合はUnicodeファイル名として保存される。

この場合、従来のファイル名ヘッダー(01h)、ディレクトリ名ヘッダー(02h)は使用されないため、未対応のソフトウェアでは正しく扱えないアーカイブができてしまうことになる。

UNIXでは、UNIXのファイル属性等を保存する必要があり、そのための拡張ヘッダーが用意されている。

UNIX用の実装LHaで使われているが、下記のうち、グループ名ヘッダーとユーザー名ヘッダーは実際には使われていない。

パーミッション情報は、次のヘッダーに格納する。

UID/GID情報は、次のヘッダーに格納する。

グループ名は、次のヘッダーに格納できるが、使われていない。

ユーザー名は、次のヘッダーに格納できるが、使われていない。

最終更新日時は、次のヘッダーに格納する。

UNIXのシンボリックリンクは、ディレクトリ名と同様、-lhd-形式で格納される。

ディレクトリ名の格納と殆ど同じだが、ディレクトリ名を格納する所に「シンボリックリンクファイル名|リンク先」という形式で文字列が格納される。

計算に使われるCRCは、一般的な16ビットのCRC-16、多項式11000000000000101(x¹⁶+x¹⁵+x²+x⁰)である。

LEVEL 1以降の基本ヘッダーにある1バイトの領域に、OSの情報を書き込むことができる。公式なものと非公式なものがあるとされる。

• 公式なもの
  • 'M' : MS-DOS
  • 'U' : UNIX
  • 'm' : Mac OS
  • 'H' : Human68K
  • '2' : OS/2
  • 'C' : CP/M
  • '9' : OS9
  • 'K' : OS/68K
  • '3' : OS/386
  • 'F' : FLEX
  • 'R' : Runser
• 非公式なもの
  • 'W' : Windows NT
  • 'w' : Windows 95
  • 'T' : TownsOS
  • 'X' : XOSK
  • 00h : generic

Windowsでも、OS識別子はMS-DOSの'M'がそのまま使われている。

LHAに限ったことではないが、LHAの実装の多くにはセキュリティ面での脆弱性があり、特にバッファーオーバーフロー脆弱性を持つものが多い。

例えば、拡張ヘッダーID 0x01(ファイル名)や0x02(パス名)に長い名前が格納された場合、バッファーオーバーフローが発生する実装がある。

それだけではなく、ヘッダー処理自体でバッファーオーバーフローを発生させる恐れもある。

LHAの基本ヘッダーは最大でも257バイトであり、これ以上に伸びることはない。一方で拡張ヘッダーは理論上64Kiバイト程度まで存在できる(H2の場合)ものの、多くの実装(純正版LHA含む)では4Kiバイト程度しかバッファを確保していない。

通常の用途で拡張ヘッダーが4Kiバイトを超えることは無いが、悪意を持ってヘッダーを細工し、巨大な拡張ヘッダーを作ることは可能で、このためバッファーオーバーフローを誘発させることが可能となる。

こういった悪意あるLZHファイルは、殆どのウイルス対策ソフトでは検疫できない。LHAフォーマットに充分に対応していないからである。

UNLHA32.DLLの作者Miccoによると、脆弱性情報の公開については、ZIP、CAB、7-Zipでは進んでいるが、LHAでは後れをとっており更に今後も望むことができない、とする。このため、安全のためにLZH書庫は(特に企業では)利用を自粛し、ゲートウェイ形式で検疫をしている場合はLZH書庫自体の拒絶をするべきとした注意喚起を2010(平成22)年6月5日に発表した。

また、UNLHA32.DLLは、UNARJ32.DLL、LHMeltと共に開発を中止するとしている。