ExcelのAGGREGATE関数の2番目の引数セットに間違った引数の説明があることに気付いたことがありますか？実際、2番目の引数セットでは、2番目と1番目のセットの説明が混同されています。このバグはExcel 2010、2013で正確に再現されています。Microsoftがその主要製品のいずれかのインターフェイスについて不注意にならないため、なぜこのようなことが起こっているのかと思いまして。その結果、MS Officeローカリゼーションファイル形式の完全な分析が行われました。

額オプション

officeフォルダー内のファイルの内容による関数引数の説明の短い検索の後、ファイルc：\ Program Files \ Microsoft Office \ Office15 \ 1033 \ XLINTL32.DLLが見つかりました 。ここで、1033はローカライズ言語のLCIDです（ msdnの詳細）。

ざっと見たところから、原則として、探しているものが見つかったことが明らかになりました。ファイル内の両方のオプションのAGGREGATE関数の引数の説明は正しいものでした。 Excelが独自のローカライズファイルを誤って解析することが判明しました。その後、Excelローカリゼーションファイルパーサーを作成するか、少なくともMS Officeローカリゼーションファイルの形式を理解することが決定されました。

まず、引数と関数の説明のみのパーサーを作成することが決定されました。これは、上記のファイルをざっと見てみると、フォーマットが非常に単純であるように思えたためです。。

その結果、ファイルを少し思慮深く読んだ後、引数と関数を記述するためのそのようなスキームが明らかになりました：

すべての説明は、Excel用の何らかのネイティブ関数順序で記述されていますが、xls形式の仕様で説明されている関数順序とは一致しませんでした。
関数の各説明は、次の形式で記述されます。「！」+関数引数のカンマ区切りの説明+ [“！” +存在する場合は引数の2番目のセット] +” !!” +関数自体の説明+”！” +“で共有される引数の説明！」
すべての関数に説明があるわけではなく、次のようにファイルに書き込まれる完全に空の関数もあります。 -それだけです。

このスキームによると、パーサーはすぐに記述され、その作業に非常にうまく対処しましたが、いくつかの問題がありました。

一部の機能の説明の間、具体的には249から250の機能の説明の間、および504から505の間に、理解できないクラッカーがあり、再び通常の説明がありました。
一部の機能の説明は、選択したスキームに適合せず、それらのために松葉杖を作成する必要がありました。
どの説明がどの機能に属するかは明確ではありません。
さまざまなローカライズの関数記述のブロックの先頭のオフセットは異なっていたため、このオフセットを手で認識して、パーサーの辞書に入力する必要がありました。ここではどのような自動化について話せますか？
一部のローカライズでは、説明はUTF-8形式で、他のUTF-16では、一般的に説明の半分はUTF-8で、もう1つはUTF-16でした。

しかし、原則として、多くの汚いハッキングにより、ほとんどすべてのローカライズの機能の説明を引き出すことができました。

さらに深く

どの記述がどの機能に属するかという問題を解決することは残っています。これを行うために、MS Officeフォルダー内のファイルのコンテンツの検索を再び開始しましたが、今回のみ関数名を検索していました。そして幸運なことに、関数の説明が記載されたXLINTL32.DLLファイルの隣にXLLEX.DLLファイルがあり、関数の名前に似たものがありました。

彼らだけが何とかスペースなしで一列に歩いた。そして、英語の場合、このテキストを自分の手で別々の関数名に解析することが依然として可能であれば、アラビア語またはタイ語ではそれができませんでした。

原則として、ここでは、Excelのローカライズファイルの形式を既に理解するか、この問題に取り組んで就寝する時であることが明らかになりました。最初のものが選ばれました。

最初に、関数の説明と関数の名前の両方が、名前が「1」でタイプが「234」のリソースのdllファイルに格納されていることに気付きました。 XLLEX.DLLファイル（これは関数名が付いたもの）からのリソースダンプの思慮深い調査により、次の発見に至りました。次に、WinHEXと計算機を使用して、これらの領域をより深く研究することにしました。関数の名前を使用して、サイトの前にいる詐欺師のサイトを見てみましょう。

最初の2バイト：01 00-意味がまだわかりません。次の2バイトは56 02です-裏返すと0256になり、16進法から10進法に転送する場合は598になります。意味のあるテキストのブロックにある以下の関数名とまったく同じです。これはすでに喜ばしいことです。さらに調べると、次のバイトのペアは、交換される場合、増加するシーケンスに似ています。実際、これらのバイトは、krakozyabrブロックの終わりからの個々の関数の記述のオフセットです。実際、XLLEX.DLLファイルのスクリーンショットは、最初の関数がCOUNT-5バイト（0005h-0000h）、2番目-IF-2バイト（0007h-0005h）、3番目-ISNA-4バイト（000Bh-0007h）であることを示しています。

これはすべて非常に優れていますが、関数名の長さが指定されているkrakozyabrブロックの開始位置を決定する方法です。実際、各ローカライズでは、このブロックには独自のオフセットがあります。次に、XLLEX.DLLファイルからリソースダンプのヘッダーを掘り始めました。

最初の4バイトはリソースのサイズです。さらに、オフセット33h 34hにあるバイト（値-0256）は、ファイルに記録されている関数名の数とまったく同じであることに興味がありました。さらに、03hは17バイトごとに繰り返され、スクリーンショットで選択された領域の最後の4バイト-0E 6F 00 00は、リソースのサイズに等しい数=選択された領域のサイズ+ 4 + 4-1に等しくなります。データが存在するファイルの部分のサイズ。

これで、03hの繰り返しの間にあるすべてのバイトを書き出して、少しグループ化できます。

03	0F05	0000	9E1C0000	00000000
03	5602	0100	51150000	9E1C0000
03	0601	0200	A00A0000	EF310000
03	0404	0300	E6310000	8F3C0000
03	3100	0400	99000000	756E0000

これらのバイトが意味するさまざまなオプションを長時間検索した後、次のパターンが強調表示されました。

1バイト-ブロックのタイプ（タイプ02、03、04-通常の行はofficeファイルにあり、01-WordBasic関数テーブルのように見えます。全体の説明は、関数名と各関数の何らかのインデックスの形式になります）。
2バイト-ブロック内の要素の数。
4バイト-わかりません。私が見たすべてのファイルで、この値は常に0であり、予約されている場合があります。
2バイト-ブロックのシリアル番号。
4バイト-ブロックサイズ
4バイト-7Ahのファイルの場合、ブロック記述の末尾からのブロックのオフセット。

ブロックが始まる場所、サイズなどについてデータが記録されるプロット。ブロックマップを呼び出しました。用語を紹介するために、ファイルを3つのセクションに分割しました。ヘッダー、ブロックマップ、テキスト付きの実際のブロック（ブロックの説明とデータ自体で構成されています）。

エンコーディングを扱っています

基本的に、このデータはすでにXLLEX.DLLファイルの自動パーサーを作成し、すべての言語のすべての関数の名前と他の多くの情報を引き出すのに十分です。しかし、このプロセスには1つの問題がありました。ローカリゼーションのごく一部だけがUTF-8形式でデータを保存します。ほとんどのデータは、完全に理解できない形式で保存されます。各文字は、UTF-8でこの言語のテーブルを基準にしたオフセットで1バイトでエンコードされます。たとえば、キリル文字「C」と「H」はA1とA7として記述され、テーブルUTF8では番号D0A1とD0A7を持っていますが、同時に「p」はD0であるはずですが、C0と記述されています。

この問題を解決するために、私は最初にExcel自体が少なくともUTF-8でこのようなあいまいなエンコーディングから文字列を変換する方法を理解しようとしました。これを行うには、いくつかの言語のブロックの説明を比較する必要がありました。ロシア語のローカライズと英語を使用しました。

英語のローカライズのブロックの説明の始まり：

英語：0100 5602 0500 ...（上で説明したように、2番目の2バイトはブロック内の要素の数で、3番目の2バイトは最初の要素の長さです（COUNT関数は5バイトです）...）
ロシア語：0184 5602 0400 ...（2番目の2バイトは要素の数、3番目の2バイトは最初の要素の長さ（COUNT関数は4バイト）...）

ご覧のとおり、説明は最初の2バイトのみが異なります。さらに、ローカライズには、テキストが2バイトUnicode LEで記録されたものがあります。このようなファイルでは、説明は0000 5602 ...

これからいくつかの結論が導き出されました。ブロック記述の最初の2バイトはエンコードです。最初のバイトが0の場合、このブロックのテキストはUnicode LEで記述され、ここではすべてが単純です。エンコードの最初のバイトが01の場合、2番目のバイトを調べる必要があります。 2番目のバイト= 00の場合、テキストは単純なUTF-8エンコードでエンコードされます。ここでも、頭を悩ます必要はありません。しかし、2番目のバイトが0でない場合はどうでしょうか？

最初は、辞書をコンパイルしただけです。2番目のバイトの値は、UTF-8テーブルのオフセットです。これはすぐに私を退屈させ、私はパターンを探し始めました。 UTF-8テーブルのオフセットは、offset =（byte2-80h）* 4 + C0hのように定義できることがすぐに明らかになりました。唯一の問題は、エンコーディングのグループによっては、C0hを別の番号に変更する必要があることです。

その結果、テキスト変換関数は次のようになり始めました。

C＃コード

#region Convert int GetCharSize(int blockIndex) { if(block2Encoding[blockIndex][0] == 0) return 2; if(block2Encoding[blockIndex][0] == 1) return 1; if (block2Encoding[blockIndex][0] == 2) return 2; if (block2Encoding[blockIndex][0] == 3) return 1; return 1; } byte[] Convert(byte[] array, int blockIndex) { byte encodingByte1 = block2Encoding[blockIndex][0]; byte encodingByte2 = block2Encoding[blockIndex][1]; if(encodingByte1 == 0 || encodingByte1 == 2) return Convert0000(array); if(encodingByte2 < 0x80) return ConvertFromUTF8(array, 0x00, 0xC2); int d = encodingByte2 - 0x80; d *= 4; byte byte1; byte byte2; if(d < 0x20) { byte1 = 0; byte2 = (byte) (0xC0 + d); } else if(d < 0x40) { byte1 = 0xE0; byte2 = (byte) (0xA0 + (d - 0x20)); } else { d -= 0x40; byte1 = (byte) (0xE1 + d / 0x40); byte2 = (byte) (0x80 + d % 0x40); } return ConvertFromUTF8(array, byte1, byte2); } byte[] ConvertFromUTF8(byte[] array, byte byte1, byte byte2) { List<byte> result = new List<byte>(); foreach(byte b in array) { if(b <= 0xFF / 2) result.Add(b); else { if(byte1 != 0) result.Add(byte1); byte d = (byte) (byte2 + (b - 1) / 0xBF); result.Add(d); d = b; if(b >= 0xC0) { d = (byte) (b - 0xC0 + 0x80); } result.Add(d); } } return result.ToArray(); } byte[] Convert0000(byte[] array) { return Encoding.Convert(Encoding.Unicode, Encoding.UTF8, array); } #endregion

核心に到達する

このすべての後、XLLEX.DLLファイルからすべてのローカライズされたテキストを正確かつ正確に抽出することはすでに可能でしたが、この方法は関数と引数XLINTL32.DLLの説明を含むファイルには完全に不適切でした。ここでは、最初からほとんどすべてを始めなければなりませんでしたが、それはすでに簡単でした。

最初に、XLINTL32.DLLファイルで、XLLEX.DLLファイルのデータに既に馴染みがあり、似ているものを見つけようとしました。おなじみの画像は、オフセット0459hから始まりました。

つまり 04B1hからは、XLLEX.DLLファイルと同じブロックの説明がありましたが、このオフセットを超えると、すべてがどういうわけか理解できませんでした。また、リソースのすべてのテキストが、XLLEX.DLLファイルの分析に基づいて導出された規則に従っているわけではありません。

将来、2番目のタイプのブロックとして認識することを既に学んだブロックと、最初のタイプのブロックを呼び出す方法がまだわからないブロックが決定されました。これらは、XLINTL32.DLLファイルの2番目のタイプのブロックの上にあります。

最初のタイプのブロックのテキストは、2番目のタイプのブロックのマップの終わりのほぼ直後から始まりました。最初のタイプのブロックのマップがマップに含まれている場所、および最初のタイプのブロック内のテキストセパレーターの決定方法を見つけることは残ります。研究のために、このブロックが選択されました：

このような線は、「カット、コピー、および貼り付け」、「印刷」、「グラフ用」などで明確に表示されます。さらに、ゼロと増加する値の「特性」ラダーが16進コードで表示されます。このラダーの最初の2つの値-46hと6Eh-10進数40でのそれらの差テキストはUnicode LEで明示的に設定され、「切り取り、コピー、貼り付け」の長さは20 * 2 = 40になります。収束します。別の値のペアをチェックしてみましょう：78h-6Eh = 10/2 = 5-「印刷」の正確な長さ。オフセット07BE66hから意味のあるテキストの先頭まですべてのバイトを美しく書き換えます。

00 46000000

00 6E000000

00 78000000

...

FF E2020000

結果のステートメントの合計の長さは、07BEABh-07BE66h + 1 = 46h-既にあった場所です。最初のタイプのブロック内の要素の説明は次のようになります。1バイトは要素のタイプ、4バイトはこのブロックの先頭からの要素のオフセットです。後で判明したように、最初のタイプのブロックの要素のタイプは、00h（ユニコードのプレーンテキスト、0Ah-いくつかのあいまいなkrakozyabry、FFh-このブロックの最後の要素）です。

最後に、リソースヘッダーを処理し、すべてのブロックのオフセットがどのように決定されるかを調べます。

最初に、2番目のタイプのすべてのブロックの説明はオフセット0A67hで終わり、オフセット0459hで始まることを思い出したので、2番目のタイプのブロックの説明の長さは0A67h-0459h + 1 = 060Fhであり、0455hには4バイトの番号060Bhがあります：060Bh + 4 = 060Fh 。 455hには、2番目のタイプのブロック記述セクションの長さが記録されていることがわかります。

リソースの先頭からの最初のタイプのブロックの変位がどのように記述されるかを理解するために、最初のタイプの各ブロックについて、このブロックの始まりの変位とその長さの表をコンパイルすることが決定されました。

最初のタイプの最初のブロックは、2番目のタイプ-0A68hのブロックの記述が終わるところから始まります。

オフセット	長さ
0A68h	011Ah
0B82h	00CEh
0C50h	0148h

そして、リソースの先頭とオフセット0455hの間には、増加するシーケンスに非常に類似したバイトがありました。

01E8h（オフセット25h）から数値011Ah（オフセット21h）を減算してみましょう：01E8h-011Ah = CEh、2番目のブロックの長さ。楽しみ：01E8h（オフセット25h）から0330h（オフセット29h）を引く：0330h-01E8 = 0148h、および011Ah-最初のブロックの長さのように見えます。 1Dhオフセットから、最初のタイプのブロックのオフセットの記述があることがわかります。それらは、2番目のタイプのブロックの記述の終わりからブロックの始まりのオフセットの形式で記録されます（またはブロックの内容を含むセクションの始まり-それがより便利です）。 04hと1Dの間のバイトの種類を理解することは残っています。 1D（最初のタイプのブロックのオフセットの記述の始まり）と0455h（2番目のタイプのブロックの記述の長さが格納されるオフセット、つまり最初のタイプのブロックの記述の終わり）を引くと：0455h-1D = 0438h、ちょうどそのような数はオフセット19hにあります。 04hから19hまでの残りの21バイトにあるのは、私には謎です。はい、特に理解したくありませんでした。すべてのオフィスローカリゼーションファイルで、このオフセットは同じです。

Microsoft Officeローカリゼーションファイルを読み取るための私のプログラム： I. Diskへのリンク

UPD：2016年1月16日

最初のタイプのブロックは、ファイルの最後に書き込まれる追加の辞書でエンコードされることがあることが判明しました。どうやらこれはファイルサイズを減らすために行われた辞書には、1バイトで表される多くの文字を含めることができます。実際には、リンクはソースコードを更新しています。

短いファイル構造の仕様

4バイト-リソースサイズ

21バイト-名声ではない

4バイト-タイプ1のブロック数* 4 =タイプ1のブロックのマップを記述するバイト数

*最初のタイプのブロックマップの説明の始まり*

4バイト-ブロック記述の終わりからのタイプ1ブロックのオフセット。隣接する2つの値の違いは、タイプ1ブロックの長さです。

*最初のタイプのブロックマップの説明の終わり*

4バイト-タイプ2のブロックのマップを記述するバイト数=タイプ2のブロック数* 17バイト

* 2番目のタイプのブロックマップの説明の始まり*

1バイト-ブロックタイプ

2バイト-タイプ2のブロックの要素数

4バイト-わかりません。私の意見では、常に0であり、予約されている可能性があります。

2バイト-ブロック番号2

4バイト-2番目のタイプのブロック長

4バイト-ブロック記述の最後から2番目のタイプのブロックのオフセット

* 2番目のタイプのブロックマップの説明の終わり*

4バイト-タイプ2のブロックのデータ長

*最初のタイプのブロック*

1バイト-要素タイプ-FFの場合-この要素はこのブロックの最後、00がUnicodeのプレーンテキストの場合、0Aがxsの場合

4バイト-このブロックの先頭からの要素オフセット

次のアイテム

*最初のタイプのブロックの終わり*

* 2番目のタイプのブロック*

1バイト-エンコードの最初のバイト

1バイト-エンコードの2番目のバイト

2バイト-ブロック内の要素の数

* 2番目のタイプのブロックの要素のマップ*

2バイト-ブロック要素の先頭からの相対オフセット。 2番目の要素から始まります。オフセットがFFFFを超える場合、オフセットの後にさらに2バイトが追加されます= FFFFを取得する必要がある回数。

* 2番目のタイプのブロックの要素のマップの終わり*

* 2番目のタイプのブロックの終わり*

*********************

コーディングにより：

エンコードは次のように定義されます。

2番目のバイト== 0の場合、これは単純なUnicodeリトルエンディアンです。

2番目のバイト== 1の場合、要素はUTF8でエンコードされ、オフセットは最初のバイトで決定できます。

*********************

2番目のタイプのブロックは、さらにいくつかのタイプです

2、3、4-通常の行

1-WordBasicテーブルのように見えますが、最初にいくつかのインデックスのテーブルがあります（WordBasic関数のインデックスかもしれません）

面白いです

Excel関数の名前の中には、ドキュメントのどこにも記載されていないものがあり、数式で使用することはできません。名前が私のためにローカライズされている理由はまだ謎です。これらの機能の一部を次に示します。

GOTO（参照）;
HALT（cancel_close）;
ECHO（論理）;
WINDOWS（type_num、match_text）;
INPUT（message_text、type_num、title_text、default、x_pos、y_pos、help_ref）;
ADD.TOOLBAR（bar_name、tool_ref）。

使用方法を知っている人がいれば、コメントを書いてください。

PS

冬の長い休暇で、私はさらに退屈になり、Excelがフォントに基づいて行の高さを計算する方法を決定し始めました。 OllyDbgとIDAで数十時間を費やした後、ほぼ2,000行のC＃コードが生まれました。これにより、すべてのフォント、サイズ、およびパラメーターについて行の高さがExcelと100％一致します。さらに、Excel内部のいくつかの興味深い機能が明確になりましたが、このトピックはすでに別の記事のためのものです。

Microsoft Officeローカリゼーションファイル形式の解析

額オプション

さらに深く

エンコーディングを扱っています

核心に到達する

面白いです

PS

More articles: