Analysis of the Japanese P2P software "Share"

1. Introduction

I think many of you know about the P2P file exchange system called Share that spread rapidly in about two years, and now constitutes a huge P2P network (second to Winny). Previously, we detected Winny network traffic with the vulnerability scanner "Retina" (http://www.scs.co.jp/eeye/), but I have gotten requests from throughout Japan wanting an implementation that detects Share as well. To do this, we will first analyze Share.

If we analyze the Share anyway, to analyze in detail the protocol and encryption algorithm, which is used, and if Utere hands something to information leakage problems in the Share network has become a major social problem in Japan currently (hereinafter, the "Share" and = "Share EX2") and I think, we began to analyze the Share EX2 after the turn of the year. There Kai this, the implementation of the Share detection of Retina, and prototyping to enumerate its whereabouts and file of Share within the network "Share network visualization system" was completed. I think this time, detection algorithm of Share that implements the Retina, and, you want to talk about implementation with the detailed mechanism of the Share network visualization system. In addition, there may be a mistake because there was no sufficient materials during analysis. I think if you have folded the person who found the error if, and if you can let me know.

Screenshot 1. At the interface of the web interface Share network visualization system screen, you can enter a particular hash file or part of the file name to display a list of nodes that have a copy of the corresponding file. Further, it is possible to also display the list of files owned by a specified node (IP address).

2. P2P and Share

P2P network is made up by a set of nodes that act as both clients as well as servers. Unlike a typical client-server model, each computer must play in equal role to participate in the network. As with Winny, Share is a P2P system for file exchanging, and a pure P2P system where there are no central servers, meaning that all processing happens P2P.

For this reason, the Share application, there is a property that accepts a communication active from an unspecified number. Share the application protocol is implemented, you can connect to any node Share, communication is performed in accordance with the Share protocol. Therefore, you can if you create an application that implements the required Share protocol, it is determined over a network Share to whether or not running on the target system. Also, if acquiring a list of the other nodes that node holds, and that it will repeatedly connected in sequence to those nodes, it will be possible to enumerate all nodes substantially Share network in principle . Furthermore, by collecting together key information indicating the location of the file, information of the node that is in possession of the specified file, that is, can be enumerated the IP address that holds the complete cache of the specified file .

In order to implement these systems, the reverse-engineering of the Share protocol is required. Share accomplishes encrypted communication by combining several cryptographic methods, so in order to implement the protocol, one needs to know in detail how to use the cryptographic algorithms.

3. Share Protocol Overview

The Share protocol is TCP-based, and listens for connections on any port that you set to (Listen). The user publishes onto the web a special encoding of the IP address and port number of their own "node information", prompting the connection of others. Nodes are present Share network already accepts the connection, it provides a node other information in connection source. For this reason, the network will continue to spread rapidly. Then, transfer and search of files is done on this network.

I think you know that there is many, but packets Share will be encrypted. For this reason, it is not possible by, for example, to capture the packet, you can get an overview of the protocol easily, and you can review the information that is exchanged. The Share, (hash algorithm, uses the SHA-1 and CRC-32) It is a combination of RC6 and 1024-bit RSA public key encryption. For public-key cryptography is based on basically, unlike the Winny, you can not intercept with (sniff), to understand the information in the file that you are exchanging traffic flowing through the network. I can say for the key pair is also generated randomly each time when the system starts, the risk of personal identification also relatively small for the user. In this way, I can say encryption algorithm is being used and implemented properly.

However, by analyzing the information transmitted prior to the public key, it is possible to identify the communication Share of network traffic. Therefore, technically, you can choose to block only effectively communicate Share.

For Share network visualization system, for visualization system like Winny, may be communication with the other node to become a party to the last node, you do not need the analysis of network traffic. For this reason, a detailed traffic analysis is not required.

It is intended to prevent eavesdropping by a third party only, packet encryption Share does not purport to be a complete conscious (enumeration of files and key node in the network) and network analysis interruption of communication.

4. First Stage - Hello Packet

For convenience, I will "client", "server", the Share nodes that will connect the node Share on the side that receives the connection later.

First, when you connect to a TCP port that the client configuration of server, the server returns a packet with a specific pattern. It will be referred to as "Hello Packet" for convenience this. If you conduct a port scan on the target host, we TCP connection to open all ports, Share if running on the target host, then the client will be able to receive this Hello packet. By taking advantage of this mechanism, it becomes possible to active discovery Share behavior host. In addition, it is also possible to detect or communicate Share in packet monitoring, or to cut off the communication of Share in the gateway.

However, including this Hello packet, encryption is given a packet of all, it is not possible to determine as it is. However, since the encryption key in the Hello packet is one that is uniquely generated from the port number can be easily decoded. Below, I shows the key generation procedure, the encryption algorithm.

4-1. Key Generation Procedure

Before it is sent by send () socket function, sending packets are encrypted with RC6 method always eventually. The RC6 encryption routine, enter the original data and RC6 key. I will continue to encrypt the original data while repeating an XOR operation and bit rotation. The encryption key is the same as the decryption key.

The length of the buffer that holds the RC6 key is 256 bytes, it will be generated in accordance with the procedure of the key set of RC6. Generation procedure depends on the stage, but in the first stage, and it is with the following procedure.

(1) Generate a 20 byte SHA-1 hash of the port number (WORD value = 2 bytes) of the target node
(2) Based on the 20-byte hash obtained and generate the key in accordance with the procedure RC6 keyset

In other words, it is that RC6 key that is uniquely determined port number of the target node from (WORD value = 2 bytes) in the first stage. It is useful to get the SHA-1 hash from the port number, and use the Cryptography Functions Microsoft CSP of (Cryptographic Service Provider). Share also calculates a hash using the Cryptography Functions.

CryptCreateHash(hProv, CALG_SHA1, 0, 0, &hHash;);
CryptHashData(hHash, (UCHAR *)&wPort;, 2, 0);
memset(pHashData,0,sizeof(HashData));
dwLenHash=0x14;
CryptGetHashParam(hHash,HP_HASHVAL,pHashData,&dwLenHash;,0);

In Figure 1, I will show how to calculate the RC6 key from the 20 byte SHA-1 hash. K is the key, and H is the 20-byte hash value. Please note that both are DWORD arrays. The default system key is 0 for the first 32 bytes, and the rest of the RC6 magic table is hard-coded starting from 0x00132CB4 in the Share executable.

Figure 1. The first stage for RC6 key generation procedure 63 51 e1 b7 1c cb 18 56 d5 44 50 f4 8e be 87 92
47 38 bf 30 00 b2 f6 ce b9 2b 2e 6d 72 a5 65 0b
2b 1f 9d a9 e4 98 d4 47 9d 12 0c e6 56 8c 43 84
0f 06 7b 22 c8 7f b2 c0 81 f9 e9 5e 3a 73 21 fd
f3 ec 58 9b ac 66 90 39 65 e0 c7 d7 1e 5a ff 75
d7 d3 36 14 90 4d 6e b2 49 c7 a5 50 02 41 dd ee
bb ba 14 8d 74 34 4c 2b 2d ae 83 c9 e6 27 bb 67
9f a1 f2 05 58 1b 2a a4 11 95 61 42 ca 0e 99 e0
83 88 d0 7e 3c 02 08 1d f5 7b 3f bb ae f5 76 59
67 6f ae f7 20 e9 e5 95 d9 62 1d 34 92 dc 54 d2
4b 56 8c 70 04 d0 c3 0e bd 49 fb ac 76 c3 32 4b
2f 3d 6a e9 e8 b6 a1 87 a1 30 d9 25 5a aa 10 c4
13 24 48 62 cc 9d 7f 00 85 17 b7 9e 3e 91 ee 3c
28 19 4b 00 cc 2b 4b 00 7c 46 4b 00 00 00 00 00 Table 1. RC6 Magic Table

4-2. Decryption and Encryption

To encrypt the Hello packet using the key obtained in ,4-1, Share are sent to the client. Cryptographic algorithms are utilized RC6 and as described above. Some operations since common are used in the encryption and decryption, first I shows the calculation procedure.

Figure 2. Common Arithmetic Unit

Input is a key K of type DWORD array, DWORD output value v is determined uniquely by its contents. In addition, T in the figure is a special buffer of type DWORD.

Then, I show each encryption, the procedure of decoding. D is the input data, K is key, R shows the output data. In addition, please note that here, D, K, R because it is UCHAR type sequence, respectively.

Figure 3. Encryption Procedure
Figure 4. Decryption Procedure

4-3. I decodes the Hello Packet

Hello packet is 4 bytes. Client connects to the server, first I will receive the 4 bytes. The D and the data and passes it to the Decode function. Now, Hello packet is decoded and output in R. Hello packets are as follows.

02 00 00 00

It is not known what these bytes may or are you meaning, which is not a value that changes depending on the situation, it is the 32-bit immediate value that is hard-coded in the text section. Therefore, when decoding the above scheme packets 4 bytes that connects to all TCP ports of interest, sent, can be determined Share whether running on the target 32 (2 While the false positives with a probability of one minute of power ...).

If you want to detect communication of Share in the gateway and packet monitoring, you can create a key based on the source port of the TCP packet obtained, to detect if you decode the above method.

4-4. Change of Decryption Key

Decryption key changes every time you decode the packet. The decryption key, and I will change in the following rules.

(1) 最後の受信したパケットの最後16バイト(復号前の生データ)をNewKeyにセットし、n = 16 とする。16バイトに満たない場合は、読み込んだデータの全てをNewKeyにセットし、そのサイズを n とする。 (2) 復号キーの 16 バイト目から16バイト分を左に nバイト左にシフトする。 (3) 復号キーの 16 + (16 - n) バイト目から、NewKeyを n バイト分コピーする。
(1) Was set in the NewKey (raw data before decoding) 16-byte last packet received last, and the n = 16. If you are less than 16 bytes, set to NewKey all of the data that is read, it is n its size. (2) I shifted to n bytes left to the left 16 bytes from 16th byte of the decryption key. (3) 16 + of the decryption key - from (16 n) byte, I n bytes copy NewKey.

I shows an example in Figure 5.

Figure 5. Example of Change in Decryption Key

4-5. Reciept of Server Public Key

Following the Hello packet, the server sends the data length and its own public key. Data length is 0x84 fixed, but it is sent as a WORD value of 2 bytes in Hello packets immediately. Decrypts by changing the decryption key using the procedures described in 4-4 for 2-byte reception Following the Hello packet. As a result, WORD value, such as the following can be obtained.

84 00 = 0x0084

Then, receives the data of 0x84 bytes, and then decoded by the same procedure. Server public key is the public key of 1024-bit RSA as described above, but there is no key header to the public key sent. Because it is not available in the Microsoft CSP in this state, you will need to add the appropriate header. Header of 1024-bit RSA public key is as follows.

06 02 00 00 00 a4 00 00 52 53 41 31 00 04 00 00

この16バイトは、Microsoft CSP で定義される公開鍵ブロブです。

06 : PUBLICKEYSTRUC構造体のbTypeパラメータ。0x06は、公開鍵ブロブである事を示します。
02 : PUBLICKEYSTRUC構造体のbVersionパラメータ。ブロブフォーマットのバージョン。
00 00 : PUBLICKEYSTRUC構造体の予約フィールド(2バイト)
00 a4 00 00 : PUBLICKEYSTRUC構造体のaiKeyAlgパラメータ。CALG_RSA_KEYX(RSA公開鍵)である事を示します。
52 53 41 31 : RSAPUBKEY構造体のmagicパラメータ。RSA1。
00 04 : RSAPUBKEY構造体のbitlen パラメータ。0x0400 = 1024ビットである事を示します。


サーバーから受け取った公開鍵にヘッダを付与した後、CryptImportKey() APIを利用してMicrosoft CSPに公開鍵をインポートしておきます。

CryptImportKey(hProv, ServerRSAKey, 0x94, 0, 0, &hKey);

5. 第2ステージ - クライアント暗号化キーの送信

公開鍵を受け取ったら、今度はクライアントが自らの暗号化キーを送信します。この暗号化キーは、今まで利用してきたポート番号ベースの暗号化キーではなく、以降のデータ交換で利用するための第2ステージ用暗号化キーです。以降、これを「第2暗号化キー」と呼ぶ事にします。

ここで送信される第2暗号化キーは、暗号化、および復号ルーチンに入力されるRC6キーではなく、その元となっている、4-1で解説した20バイト長の暗号化キーです。この20バイト長の暗号化キーがあれば、サーバー側でも同様のRC6キーを作成できますので、これで十分という訳です。サーバーHelloの復号では、2バイトのポート番号から20バイトのSHA-1ハッシュを得て、それを4-1で示した手法でRC6キーを生成しましたが、ここでは20バイト長の第2暗号化キーはランダムに決定されます。

クライアントは、20バイトの第2暗号化キーを生成(ランダムでも固定値でも良い)した後、サーバー公開鍵で、CryptEncrypt() APIを利用してこのキーを暗号化します。その際、暗号化されたデータのサイズは0x80バイトとなります。この0x80バイトをサーバーに送信します。

第2暗号化キーを送信する前に、そのデータ長(0x0080)を送信する必要があります。データ長はWORD値であり、従って2バイトとなります。このデータ長も暗号化する必要がありますが、この暗号化に利用される暗号化キーは、サーバーのポート番号から生成されたものをそのまま、つまり、暗号化によるキーの変化がまだないものを利用する必要があります。

サイズを送った後は、暗号化キー変化の規則に従って暗号化キーを変更し、暗号化された0x80バイトの第2暗号化キーを送信します。

以降サーバーは、クライアントから送信されたこの第2暗号化キーでデータを暗号化し、送信します。

クライアントも、以降継続して送信するデータは、第2暗号化キーで暗号化する必要があります。生成された第2暗号化キーは20バイトですので、実際にパケットを暗号化するには、同様にRC6キーを得る必要があります。図6にその手順を示します。

図6.　第2暗号化キー生成アルゴリズム
R は出力されるRC6キー、K は入力される20バイト長の暗号化キーを示します。システムデフォルトキーは、Shareイメージの先頭0x00132CB4からハードコードされているRC6マジックテーブルです。

6. 自ノード情報

クライアントは、次に自ノード情報を送信します。自ノード情報には、Shareアプリケーションのバージョン、最大送信速度、最大受信速度、ポート番号、起動時刻等が含まれます。以下に、自ノード情報のダンプイメージの一例を示します。パラメータ名がワイド文字列で入っていますので、一部を除いて比較的フィールドの意味は把握しやすいのではないかと思います。

00 00 00 00 09 00 53 00 69 00 67 00 6e 00 61 00 ......S.i.g.n.a.
74 00 75 00 72 00 65 00 04 00 43 41 54 00 0a 00 t.u.r.e...CAT...
56 00 65 00 72 00 73 00 69 00 6f 00 6e 00 4e 00 V.e.r.s.i.o.n.N.
75 00 6d 00 04 00 63 00 00 00 0a 00 56 00 65 00 u.m...c.....V.e.
72 00 73 00 69 00 6f 00 6e 00 53 00 74 00 72 00 r.s.i.o.n.S.t.r.
08 00 45 58 32 00 00 00 00 00 08 00 56 00 65 00 ..EX2.......V.e.
72 00 49 00 6d 00 61 00 67 00 65 00 c4 00 63 00 r.I.m.a.g.e.ﾄ.c.
00 00 45 00 58 00 32 00 00 00 00 00 00 00 00 00 ..E.X.2.........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 5a 3e 5a 9a db bc 1b 30 75 6e 3c f1 40 ad ..Z>Z.ﾛｼ.0un<.@ｭ
80 d4 b1 65 31 4a d3 2f 6c bb bc c7 7f 70 d3 57 .ﾔｱe1Jﾓ/lｻｼﾇ.pﾓW
2c 20 c2 e8 e7 15 50 fa 19 25 a2 de 73 f9 89 5b ,, ﾂ...P..%｢ﾞs..[
74 b0 52 18 6e 94 91 ab bf fa 17 48 82 00 43 26 tｰR.n..ｫｿ..H..C&
86 b5 14 c4 85 32 06 98 9b db ab 49 83 66 41 da .ｵ.ﾄ.2...ﾛｫI.fAﾚ
42 6c fd 0b f2 95 3e e4 81 1d 31 ff c0 ac 94 a8 Bl....>...1.ﾀｬ.ｨ
0e 26 a1 fd bc 5f eb e6 f1 fd 91 8e 1e 21 90 a9 .&｡.ｼ_.......!.ｩ
fc c0 87 15 92 44 63 50 87 f3 2e eb 72 e0 97 c5 .ﾀ...DcP....r..ﾅ
1f 38 05 00 53 00 70 00 65 00 65 00 64 00 04 00 .8..S.p.e.e.d...
00 f4 01 00 06 00 53 00 70 00 65 00 65 00 64 00 ......S.p.e.e.d.
32 00 04 00 00 f4 01 00 09 00 44 00 6f 00 77 00 2.........D.o.w.
6e 00 53 00 70 00 65 00 65 00 64 00 04 00 00 00 n.S.p.e.e.d.....
00 00 07 00 55 00 70 00 53 00 70 00 65 00 65 00 ....U.p.S.p.e.e.
64 00 04 00 00 00 00 00 0a 00 4d 00 69 00 6e 00 d.........M.i.n.
56 00 65 00 72 00 73 00 69 00 6f 00 6e 00 04 00 V.e.r.s.i.o.n...
60 00 00 00 09 00 4c 00 6f 00 63 00 61 00 6c 00 `.....L.o.c.a.l.
41 00 64 00 64 00 72 00 06 00 00 00 00 00 5c 11 A.d.d.r.......\.
08 00 42 00 6f 00 6f 00 74 00 54 00 69 00 6d 00 ..B.o.o.t.T.i.m.
65 00 08 00 38 3d 1e 58 8d 31 c7 01 03 00 4c 00 e...8=.X.1ﾇ...L.
44 00 50 00 14 00 43 10 e3 dc e9 6b 30 7d 17 c6 D.P...C..ﾜ.k0}.ﾆ
d5 c5 0a 2c 95 ff da d1 df b3 08 00 49 00 6e 00 ﾕﾅ.,..ﾚﾑﾟｳ..I.n.
66 00 6f 00 46 00 6c 00 61 00 67 00 04 00 01 00 f.o.F.l.a.g.....
00 00 07 00 44 00 62 00 67 00 49 00 6e 00 66 00 ....D.b.g.I.n.f.
6f 00 58 00 00 00 00 00 00 00 00 00 00 00 00 00 o.X.............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 8c 9c f8 02 00 00 00 00 10 27 00 00 .............'..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
2c 24 01 00 00 00 00 00 00 79 09 00 04 00 54 00 ,$.......y....T.
69 00 6d 00 65 00 08 00 a2 7e 9b 84 8d 31 c7 01 i.m.e...｢~...1ﾇ.
0a 00 52 00 65 00 6d 00 6f 00 74 00 65 00 41 00 ..R.e.m.o.t.e.A.
64 00 64 00 72 00 06 00 c0 a8 00 03 5c 11 07 00 d.d.r...ﾀｨ..\...
43 00 6f 00 6d 00 6d 00 61 00 6e 00 64 00 04 00 C.o.m.m.a.n.d...
00 00 00 00 0c 00 50 00 6f 00 72 00 74 00 43 00 ......P.o.r.t.C.
68 00 65 00 63 00 6b 00 53 00 69 00 67 00 10 00 h.e.c.k.S.i.g...
0e fe 47 8b f7 7f 3f 22 3f 2a c3 d0 c4 b7 e1 9f ..G...?"?*ﾃﾐﾄｷ..
09 00 50 00 6f 00 72 00 74 00 43 00 68 00 65 00 ..P.o.r.t.C.h.e.
63 00 6b 00 04 00 01 00 00 00                   c.k.......

なお、この自ノード情報には、Shareアプリケーションのコードイメージハッシュ値が入っています。サーバーは、この自ノード情報に含まれるハッシュ値が、自身のコードイメージハッシュ値と異なる場合、接続を切ってしまいます。これは、クラック版のShareアプリケーションを、既存のShareネットワークに参加できなくさせる事が目的であると思われます。余談ですが、Shareは定期的に自身のコードイメージハッシュをチェックしていますので、イメージを改造したりint3ブレイクポインタを設置するなどすると、チェックルーチンに引っかかり、アプリケーションが強制終了します。これも、クラック、解析対策が目的と思われます。

この自ノード情報の先頭4バイトは、自ノード情報自身のCRC32ハッシュ値となっています。CRC32ハッシュ値は、図7に示すようなアルゴリズムで計算します。YはUCHAR型配列の自ノード情報のバイト列、XはShareイメージの先頭0x00130590からハードコードされている固定値(CRCテーブル)です。

図6.　自ノード情報ハッシュ計算アルゴリズム

この自ノード情報を送信する前に、自ノード情報のサイズをWORD値で送信する必要があります。上記で示した自ノード情報の例ですと0x0306バイトですので、"06 03"を送信する必要があります。このデータは、第2暗号化キーを使って暗号化します。その後、暗号化キー変化の規則に従って第2暗号化キーを変更し、自ノード情報を暗号化して送信します。

7. クラスタ情報と開始要求の送信

次に、クライアントは自身のクラスタ情報を送信します。クラスタ情報は、以下のようなフォーマットで作成します。

フィールド名 バイト数 値 サイズ 1バイト クラスタデータの合計バイト数(nバイト) / 2の値 クラスタデータ nバイト クラスタ名(ワイドキャラクタ)。複数指定する場合は、NULLの後に次のクラスタ名を指定 ターミネータ 4バイト 61 00 00 00

各項目はそれぞれ個別に暗号化します(暗号化キー変化規則の影響を受けます)。

次に、サーバーが、キー情報などを含む各種情報を送信するモードに移行させるコマンド(以降、開始要求とします)を送信します。開始要求は、"ff 05 06"の3バイトです。これを暗号化して送信する事で、サーバーはさまざまな情報をクライアントに送信してくるようになります。

8. サーバー自ノード情報とクラスタ情報の受け取り

サーバーから送信される自ノード情報を受け取ります。自ノード情報は、6で示したクライアントの自ノード情報と同じデータ構造です。サーバーの最大送信速度、最大受信速度、起動時刻等などが分かります。サーバーの自ノード情報を受け取る前に、クライアントと同様、WORD値のサイズ情報を受け取ります。なお、ここで利用する暗号化キーは第2暗号化キーですが、送信で変化した第2暗号化キーではなく、初めに5で計算された第2暗号化キーである事に注意してください。基本的に、受信も送信も第2暗号化キーを使いますが、受信用と送信用はお互いのキー変化の影響を受けないようにするため、別々のものを用意します。

サーバー自ノード情報の受け取りが終わったら、次はクラスタ情報を受け取りますが、その前に、クラスタ情報が送られて来るまで待機する必要があります。一バイトづつ読み込んで復号し、0x01 を受け取るまで繰り返します。

0x01が来れば、以降、クラスタ情報を得る事ができます。同様に、先頭2バイトがWORD値のサイズ情報になっていますので、まずは2バイトを読み込み、復号してクラスタデータのサイズを取得してください。クラスタデータのフォーマットは、7で示したものと同様です。

9. コマンド

コマンドを処理する前に、コマンド送信開始が来るまで待機します。一バイトづつ読み込んで復号し、"01 05 06"が来るまで待機します。以降、コマンド処理ループに入ります。

コマンドループでは、まず、一バイト受信して復号し、コマンド番号を取得します。キー拡散やノーマルクエリ、ハッシュクエリといった合計9個のコマンドがあり、後に続くペイロードのサイズは、コマンドの種類、あるいはコマンド番号の後に続くサイズフィールドの値によって変化します。以下に、各コマンドのサイズ情報を示します。

(1) コマンド番号 0 8バイト : サイズフィールド nバイト : データフィールド。長さnは、サイズフィールドの先頭2バイト目から合計2バイトのWORD値。 (2) コマンド番号 2、3、4 9バイト : サイズフィールド r*6バイト : ノード情報フィールド。rはノードの個数。サイズフィールドの先頭から合計2バイトのWORD値。 各ノード情報の先頭4バイトはIPアドレス、次の2バイトはポート番号。 nバイト : データフィールド。nは、サイズフィールドの先頭5バイト目から合計2バイトのWORD値。 (3) コマンド番号 5、6、7、8 ペイロード無し

10. キー拡散コマンド

Shareネットワーク可視化システムを作成する上で最も重要なコマンドは、ファイルの所在やファイル名といった情報を処理するキー拡散コマンド(コマンド番号0)です。ファイルの所在はノード情報そのものですので、これでノードも収集する事が可能です。

キー拡散コマンドは、前述したように、先頭8バイトのサイズフィールドと任意長のデータフィールドから構成されています。データフィールドは圧縮されていますので、適切に展開する必要があります。展開すべきデータは、データフィールドの先頭から4バイト目以降です。

展開アルゴリズムの実装はやや大きいため、今回は実装の解説を省略します。Shareプロセスの仮想アドレス空間のアドレス0x004C6618に展開ルーチンがあります。出力バッファのサイズをスタックにPUSHし、ecxに出力バッファのアドレス、eaxに入力データのアドレス、edxに入力データのサイズを指定してこの展開ルーチンを呼ぶと展開されます。Shareのイメージをロードして呼び出すと手軽に実現できます(その際は、セクションやインポートテーブルを適切に構成してください)。

以下に、展開されたキー情報のダンプ例を示します。

0 1 2 3 4 5 6 7 8 9 A B C D E F
----------------------------------------------------------------------
0000 BC F6 26 37 58 3C C7 01 00 00 00 00 00 00 00 00 ..&7X<..........
0010 DB A6 B4 62 11 22 01 00 00 00 C4 85 37 2A 0E 34 ...bF.......7*.4
0020 F9 30 F5 94 C1 FD E1 BF B4 15 EE EC 19 74 9D 2E .0...........t..
0030 87 40 30 F7 0A EB C1 92 3F 38 1E 64 E7 C0 E6 A1 .@0.....?8.d....
0040 BE 21 70 8A 7F 22 E3 3E EF E8 B7 41 36 90 52 FF .!p..".>...A6.R.
0050 95 A3 2F 56 CE 23 E3 F0 08 92 79 00 75 00 6A 00 ../V.#....y.u.j.
0060 69 00 75 00 6B 00 61 00 69 00 00 00 00 00 00 00 i.u.k.a.i.......
0070 00 00 00 00 00 00 00 00 00 00 26 F9 0C 4A 29 17 ..........&..J).
0080 B4 AF 1E EC 85 8F 51 2B 01 AA 56 BF 07 33 01 00 ......Q+..V..3..
0090 01 00 EF 15 0A 9C 99 CC 7B 25 84 03 A9 0E 39 EA ........{%....9.
0100 DA EB E0 19 1A 06 29 D8 6A 57 56 1B 57 AE F6 40 ......).jWV.W..@
0110 0F 4E 24 CD 3B 39 2D 29 5A 3D B9 1E E6 3F E8 C2 .N$.;9-)Z=...?..
0120 6F 27 FD 74 41 3C F3 D5 EE BA 11 93 2C 51 2F 13 o'.tA<......,Q/.
0130 34 B6 A8 22 48 62 C7 BE D8 9C 78 CF 7F 21 0C DD 4.."Hb....x..!..
0140 CF B4 43 D3 DE 07 82 02 E8 5B A0 76 AB 79 0C BC ..C......[.v.y..
0150 E7 5A 2F E4 B4 5B A7 21 B7 61 61 1D 00 00 00 00 .Z/..[.!.aa.....
0160 00 00 0C 74 00 65 00 73 00 74 00 66 00 69 00 6C ...t.e.s.t.f.i.l
0170 00 65 00 2E 00 74 00 78 00 74 00 .e...t.x.t. ※ 上記ダンプに示されるIPアドレスやポート番号は実データではありません

先頭8バイト(BC F6 26 37 58 3C C7 01)は時刻、0x10バイト目から4バイト(DB A6 B4 62)はIPアドレス、次いで2バイト(11 22)はポート番号となっています。また、0x5Aバイト目からは、基本設定で指定したニックネームがワイド文字列で入っている事が確認できます。そしてペイロードの最後の方には、ファイル名(testfile.txt)、および、ファイルのハッシュ値(82 02 E8 5B A0 76 AB 79 0C BC E7 5A 2F E4 B4 5B A7 21 B7 61)を確認できます。WideCharToMultiByte() APIにてCP_ACPを指定する事で、SHIFT-JISに変更することができます。

11. Shareネットワーク可視化システムのフレーム

上記手順で、一つのShareノードから、他ノード情報を含むキー情報を取得できるようになりました。

そこで、まずは一つのShareノードに接続し、そのノードが持っている他ノード情報を取得します。そして、得られたノードに対し、マルチスレッドで更に上記手順を実行します。これで更に多くのノードを集められます。この手順を繰り返す事で、最終的にShareネットワークのほぼ全てのノードをクロールし、キー情報を収集していく事ができます。

クロールする際、得られたキー情報やノード情報はファイルに追記します。ノード情報は、新しく見つかったものを優先的に探索するようにすれば、より効率的にクロールする事ができます。また、一度接続に失敗しても、何度かリトライするような仕組みを入れておくと効率が更に上がります。上記手順を実装すれば、10万程度のノードを数時間でクロールする事ができます。

12. さいごに

WinnyやShareのネットワークはここ数年で大規模に発達し、同時に、システムのデータ管理能力の問題点が大きく浮き彫りになりました。P2Pネットワーク内で感染拡大する「暴露ウイルス」が蔓延し、多くの情報流出事件が発生。追跡や削除が困難になるという事態が多発し、大きな社会問題となりました。

この情報流出問題は、大規模組織のみならず、多くの個人までも巻き込んだ非常に深刻な事態に発展しています。インターネットは非常に便利な反面、様々なリスクを孕んだシステムである事を私たちは常に認識する必要がありますが、近年はそのリスクがあまりに高いのではと思います。一旦情報流出が発生すると、取れる対応策は極めて限定的なものとなり、特に個人レベルでの対処は限りなく不可能に近くなります。

Shareネットワーク可視化システムは、これら情報流出の問題に対して一つの抑止力になるのではと考えています。今後は各関係団体と協力し、これら問題に対処すべく適切に運用を進めて行きたいと思います。