LabyREnthセキュリティ コンテスト: 脅威種目の解答

  • 1,309
    people reacted
  • 0
  • 7 min. read

By , and

Category: Events, Unit 42

Tags: , ,

概要

今回このブログシリーズでは、LabyREnth、Unit 42セキュリティ コンテストの課題の解答を明らかにします。週に1種目ずつ解答を公開しますが、今回は脅威種目です。

脅威1課題: 希望の泉にようこそ

課題作成者: Jeff White @noottrak

この課題では、www.dopefish.comへの30のHTTP GETリクエストを含むPCAPが提供されました。各リクエストの内部は同じURLです。このURLは、以下の画像と、“Not everything is as it seems…”とデコードされるbase64の反転された文字列をポイントしています。

実際のGETリクエストを調べると、URL構造が興味深く、URLには複数のURL間で変化しないいくつかのセクションがあります。そのため、先に進み、さらに分析するためにそれらをすべて抽出します。

以下のコマンドを使用して、各URLを抽出します。

tcpdump -r dopefish_labyrinth.pcap -A |grep “GET /” |grep -o “/.*” |sort –u

URLの全般的な分析結果は以下のとおりです。

/M[a-zA-Z]{3}.php?=owVXdTMzc[a-zA-Z0-9]{109}&L4bry1nth_[0-9]{3,5}?NxM[a-zA-Z0-9]{134}-[0-9]{4,5}%26%71%77port%3D27500

URLをオンライン構文解析ツールにドロップすると、ファイルに指定されているクエリ文字列が、最初の“?”より後の文字列全体であることが示されます。URL内の他の変数であるかのように見えるため、奇妙に感じます。

さらに分析すると、URLは現在“?”として形式化されておらず、“=”が予約された文字であることがわかります。間に変数を入れずに、互いに隣合わせに配置すると、URLの残りは無効になります。

“=”で始まるクエリ文字列と、同じ記号で始まる反転されたbase64文字列に関する上記のヒントから判断して、反転された文字列のbase64デコードを試みます。それは動作しますが、出力はまったく役に立ちません。

URLを詳しく調べた後、文字の中にはっきりとした決まったパターンがあることに気付きました。しかし、“NxM”は引き続き、約18文字ごとにそれ自体が繰り返されています。さらに重要となるのは、最初の長い文字列と、URLの“&L4bry1nth_[0-9]{3,5}?”セクションの直後の長い文字列に見られるNxMパターンです。これを削除し、2つの長い文字列をつなげて、それを反転し、さらにbase64デコードを行うと、非常に有効な結果が得られます。

“317WW317WW317WW317WW317WW317WW317WW317WW317WW317WW317WW317
W317WW317WW317WW317WW317WW317WW317WW317WW317WW317WW317WW317
W317WW317WW317WW317WW317WW317WW317WW317WW317WW317WW317WW317
W317WW317WW”

続けて、前出の行に基づき、それをforループの中でラップし、二等分の一方のみを解析して、それらを反転し、結果を出力します。

for i in $(tcpdump -r dopefish_labyrinth.pcap -A |grep “GET /” |grep -o “/.*” |sort -u |cut -d”=” -f2 |cut -d”-” -f1 |sed -e ‘s/&L4bry1nth_.*?//g’); do echo “=$i” |rev |base64 -D ; done

出力の中に非常に明確なパターンがあります。最後に行う手順は、行にもう1つコマンドを追加し、“317”を取り除くことです。結果は、URLの“NxM”でした。

for i in $(tcpdump -r dopefish_labyrinth.pcap -A |grep “GET /” |grep -o “/.*” |sort -u |cut -d”=” -f2 |cut -d”-” -f1 |sed -e ‘s/&L4bry1nth_.*?//g’); do echo “=$i” |rev |base64 -D ; done |sed -e ‘s/317//g’

キーは、PAN{th3D0p3fshl1v3s}です。

脅威2課題: 私たちは皆、名誉とともにこの世を去る

課題作成者: Micah Yates @m1kachu_

ヒントは、この素晴らしいWebコミックを参考にすることです。

課題に着手するため、jareth1.gifという名前のファイルが用意されています。

サムネイルでは、それは有効なgifのように見えますが、そうでしょうか。

ファイルを開くと、活発に動きます。

16進エディタでgifを開くと、ヘッダーは通常のgifヘッダーのように見えます。

下へスクロールすると、このファイルには標準gifトレーラーの0x3Bが欠落しています(詳しくは、有効なgifの内容をご覧ください)。

末尾の16進数値は、標準gifトレーラーではありません。

このgifにはデータが付加されています。

そこで、この情報をどのように使えばよいのでしょうか。改ざんされた画像ファイルでやってみたい1つのトリックは、Googleを介して画像の逆引きをすることです。jareth1.gifファイルをgoogle画像検索にアップロードすると、以下の結果を取得します。

見た目が似ている画像をいくつかクリックしていくと、このgifが見つかります。同様に動き、jareth1.gifと同じ次元ですが、サイズが異なります。

2つのgifを比較すると、元のgifはオフセット0x3436Dで終わっており、有効なトレーラーの0x3Bが含まれています。シェルコードやマルウェアの作成者の中には、それを単一または複数バイトの16進数値でXOR演算処理して、データを隠したがるものもいます。0xAAバイトがファイルの末尾で繰り返されているように見え、通常は一部のデータにはnullが含まれるため、ファイル全体を0xAAでXOR演算処理します。

ここで、残ったデータのヘッダーを見てみましょう。

ヘッダーに基づくと、非表示のデータは7zipアーカイブのようです。このXOR演算処理されたデータを別のファイルに保存します。

使用したいトリックの1つは、ヘッダーが正しくない位置にあるときにファイルを解凍するための7zipの機能です。コマンド ラインを使用するか、ここを右クリックして、7zip -> Extract(抽出)をクリックするだけです。

そのファイルを解凍すると、“file”とだけ名付けられた別のファイルが取得されます。

ヘッダーを見ると、これはhtmlファイルであることがわかります。

そのファイル名をfile.htmlに変更し、ブラウザで開くと、このようなDavid BowieのASCIIアートが出現します。

今度は何でしょうか。難読化されたJavaスクリプトはありません。一見したところhtmlの不可解な混乱に過ぎません。他の一部のデータを挟むようにA7 A0のパターンが繰り返されているようにも見えます。

16進数に見えるデータのセクションを16進エディタにドロップしてみます。

何もASCIIとして表示されません。それを2バイトの0xA7A0でXOR演算処理して、その下にデータがあるかどうかを確認します。

引き続き何も動作しませんが、それがASCIIテキストである可能性が見えてきます。

それを元に戻し、元の単一バイトの0xAAを使用して再度試みます。

はるかに良くなりました。テキストが表示されます。

標準の有効なGIFファイルを見つけるためYARAルールを記述します。

以下のテンプレートを使用します。

  1. $header内の各“**”ペアを適切な6バイトで置き換えます。
  2. $trailer内の各“*”を適切な正規表現で置き換えます。
  3. 条件内の“*”を適切な数字で置き換えます。

gifの内容についてこの記事を読んだ後に、次の点を確認します。

  1. ヘッダーは一目瞭然です。
  2. ここでは、3Bの後に続くデータがないことを確認するための正規表現形式が必要です。
  3. もちろん、ヘッダーはファイルの先頭の0位置に配置されている必要があります。

上記のルールを送信すると、結果としてキーが得られます。PAN{848Y_wIsh3D_4w4y}

脅威3課題: マトリョーシカは私には及ばない

課題作成者: Josh Grunzweig @jgrunzweig

この課題では、Pythonスクリプトが提供されています。スクリプトを実行した場合に、唯一受け取る出力は以下のとおりです。

python h0ggle.py
You fell into a pit and died… of dysentery.

スクリプトから判断すると、データをbase64デコードして、復号化してから、それをexec()関数に渡しているようです。データはかなりサイズが大きく、100万文字を超えています。それは、暗号化のためにCrypto.CipherスイートのAESを使用しています。デバッガを使用してステップを順次見ていくと、実行されたデータの各BLOBにデータの新しいBLOBと同じコードが含まれるように、この反復プロセスが連続していることがわかります。

このロジックの方向に従うと、このプロセスをすぐにスクリプト化できます。各復号化されたセクションを新しいファイルに書き込み、それを再実行するために必要なヘッダーを含めるなど諸々の手順を経て、最後に到達します。

最初に、次のデータを使用してheader.txtを作成します。

#!/usr/bin/env python

from Crypto.Cipher import AES as tiywynstbg
import base64 as ufjliotyds
import itertools as abtwsjxzys
from itertools import cycle, izip
def gasfewfesafds(message, key):
return ”.join(chr(ord(c)^ord(k)) for c,k in abtwsjxzys.izip(message, abtwsjxzys.cycle(key)))

次に、Pythonの暗黒の深部を通り抜け、どこに導かれるか確認するための、気の利いた1センテンスを考えます。

cp h0ggle.py h0ggle_1.py; for i in $(seq 1 50); do sed -e ‘s/exec(/print(/g’ h0ggle_$i.py > temp; mv temp h0ggle_$i.py; python h0ggle_$i.py > temp; cat header.txt temp > h0ggle_$((i+1)).py; done

実行すると、ファイルh0ggle_28.pyで構文エラーが発生し、赤痢のエラー メッセージが表示されます。

File “h0ggle_28.py”, line 8
You fell into a pit and died… of dysentery.
^

h0ggle_27.pyから判断すると、安全に川を横切る方法がわかります。

Key = PAN{all_dir3ctionz_l3ad_n0wh3r3}

脅威4課題: 同じ、だけど違う

課題作成者: Micah Yates @m1kachu_

ヒントは、前出のｙaraの課題、「脅威2課題: 私たちは皆、名誉とともにこの世を去る」を参照することです。

課題に着手するため、6個のWord文書が用意されています。

それらをすべて開きます。

ファイルが開き、似たようなWord文書が表示されます。

これらのすべてのファイルでfileコマンドを実行すると、以下の結果となります。

3673c9d7a5b2f978d3a34001d360ac485f22ed6fa868c8304eb99273a6efb268.doc: Microsoft Word 2007+
668bed5ed5d5effb3be659e8dab55c63369985064f7ee80f9365e75b34f6283d.doc: Microsoft Word 2007+
7717bd124dd0c0881afd6b327ff41b420bff77d3c5ae338a31cce5cfdcb3b5d0.doc: data
87f146c41082d7ba885f9433e0223b346f3032f7364bf18675b924a017994779.doc: Microsoft Word 2007+
afc502de73482404cc344301c207f27c7da7b31641cd2192b3bba40f3ab6964e.doc: Composite Document File V2 Document, Little Endian, Os: Windows, Version 6.1, Code page: 1252, Author: Micah Yates, Template: Normal.dotm, Last Saved By: Micah Yates, Revision Number: 2, Name of Creating Application: Microsoft Office Word, Create Time/Date: Wed Jul 13 17:19:00 2016, Last Saved Time/Date: Wed Jul 13 17:19:00 2016, Number of Pages: 1, Number of Words: 146, Number of Characters: 837, Security: 0
d48a2f4922bca81ce8fff8c18d788f41d2034c7999ca1ed03965d914dc06a9df.doc: Rich Text Format data, version 1, unknown character set

すべてが同じファイル形式ではありませんが、すべてに同じ基本コンテンツが含まれています。.doc、.docx、.rtf、.mhtm、.dot、.docmの各ファイルがありますが、中身は同じプレーンテキストです。拡張子を.docに変更するだけで、Wordはそれらを標準のWord .docとして試行し、開くことができます。

RTF (d48a2f4922bca81ce8fff8c18d788f41d2034c7999ca1ed03965d914dc06a9df.doc)を16進エディタで開いてみます。辿っていくのはかなり簡単です。ヘッダーは正常に見えるため、ファイルの下部へスクロールしてみます。

何か変でしょうか。WikipediaでRTFファイル形式、特に、コードの構文について調べてみましょう。

わかりましたか。

そのセクションのTL;DRは、RTFデータを波かっこ“{}”で囲む必要があることを示しています。このRTFファイルには、明らかにそれに付加されたデータがあります。

ヒントを思い出してください。“同じ、だけど違う”。この課題は脅威2課題と同様に見えます。正規に見えるファイルに付加された不明なデータがあります。

繰り返されていると思われるデータに的を絞ってみましょう。付加されたデータは、base64符号化に似ていますが、ちょっとはっきりしません。この付加されたデータ内には、繰り返されている、48バイト長の3つのデータ シーケンスがあります。

それらのうち2つは異なります。さらに、それらのうち1つは明らかに有効なBase64ではありません(WikipediaのBase64の定義を参照してください)。

Base64符号化データ内に4つの繰り返される文字のシーケンスがある場合、その基となるデータは通常、何らかのパターンで繰り返されています。たとえば、AAAAAAAAAのBase64符号化は、QUFBQUFBQUFBです。

これらの2つの異なるシーケンスが同じデータを隠しているが、データ位置によって異なる方法で符号化していると仮定してみます。それが真なら、どちらのシーケンスも単一バイトの操作によって覆い隠されています。その操作をどのように見つけ出せばよいのでしょうか。ブルート フォースです。

2つのシーケンスに対して単一バイトの操作を実行するサイズの小さいスクリプトを記述し、その後、それをテストして、それらが有効なBase64文字であるかどうか確認してみましょう。つまり、これは、シーケンス内の各バイトに対して1バイトのXOR演算処理を実行し、それらにBase64文字とのASCII互換性があるかどうかを確認します。

上記の2つのシーケンスを8バイトのデータ シーケンスに切り詰めます。

これらの短くしたシーケンスに対してスクリプトを実行します。4つのXOR演算処理の候補が返されます。

有効なBase64文字をデコードするXOR演算処理の値として4つの候補が得られました。

まず、0x26を使用して付加されたデータのXOR演算処理を実行します。以下の結果となります。

かなり見込みがあります。“-“文字のみで“+”文字がない点を除き、ほぼすべての文字がBase64標準です。

これは、それが“+”の代わりに“-“を用いた代替の符号化文字列を使用している可能性を示唆しています。アルファベット“ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-/”を試してデコードしてみると、見込みのあるデータにはなりません。

一部の悪意のあるBase64符号化は、代替のアルファベットを使用します。ときには、それらは単純で、アルファベットの位置を変えるだけの場合もあります。上記のアルファベットの位置を回転させるための別のブルート フォース スクリプトを記述してテストし、それが有効なASCIIテキストであるか確認します。

スクリプトで実行したことは、0x26でXOR演算処理されたデータを入力し、代替のBase64アルファベットを定義して、その後、ループごとに1文字ずつアルファベット全体を回転させることで、そのアルファベットのすべてのバリエーションを通じてループさせるということです。その後、各出力をチェックし、それが有効なASCIIであるかどうかを確認後、出力しました。上記のコードの実行によって、以下が返されました。

ここに、符号化されたデータと手掛かりがあります。デコードするアルファベットは26文字分回転しているようです。

見てください。繰り返される文字の3行は、すべて同じ長さです。“{ ** ** ** ** ** ** ** ** ** ** ** ** }”

要約すると、ブルート フォース アプローチで単一バイトによるXOR演算処理を行い、その後、26文字分左に回転する代替のbase64アルファベットに対してブルート フォース アプローチを採りました。

他の文書に戻り、符号化されたデータの2つのバリエーションを見つけ、次のようなYARAルールを記述します。

上記のルールを送信すると、結果としてキーが得られます。PAN{7H1r7EEn-hOuR_71me_l1M17}

脅威5課題: Hello Confetti!

課題作成者: Anthony Kasza @anthonykasza

提供された“hello.pcap”ファイルをWiresharkで開き、pcap内のプロトコル階層を調べると、UDPトラフィックのみが示されます。Wiresharkは、大半のパケットはデータであるが、いくつかのパケットは不正な形式のリアルタイム トランスポート制御パケットであると認識しています。

WiresharkでUDPのやり取りを観察すると、pcap内で生じているのは単一の“接続”のみです。接続は、127.0.0.1上のポート9090と53321の間です。上記のプロトコルの不整合とトレース ファイル内の単一の接続を考え合わせると、使用されているプロトコルが非標準であるという結論に至ります。

トレース内の最初のパケットには、データ“hello :)”に続き0x0aが含まれています。これは長さが8234でない唯一のパケットで、ポート53321からポート9090に送信されました。2番目のパケットには、bzipファイルのファイル ヘッダー(マジック ナンバー)である“BZh”で始まるデータが含まれています。最初の“hello”パケットを無視すると、bzipアーカイブをトレース ファイルから抽出できます。bzipアーカイブを解凍すると、2番目のpcapトレースが明らかになります。

前と同様の手法を使って、pcap内の複数のFTP over IPv6接続を観察できます。FTP接続の1つを辿ると、一連のリクエストとレスポンスが明らかになります。すべてのストリームがよく似ています。

  • 匿名FTPログインが行われる
  • 一連のchange directoryコマンドが/this/is/going/to/be/so/much/fun/に対して発行される
  • ファイルのサイズ リクエストの結果、61052とレスポンスされる
  • ファイルの指定されたバイト オフセットに対するRESTリクエスト
  • その後、TCP接続がリセットされる

この一連のコマンドは、FTP範囲リクエストを示唆しています。

FTP範囲リクエストを介して転送されたファイルのバイトを再組み立てすると、tarballになります。tarball内には、3番目のpcapトレース ファイルが含まれます。

ここでも、pcap内のプロトコルとやり取りを観察すると、2つのエンドポイント間の複数のHTTP接続が明らかになります。接続内のHTTPレスポンス コードを観察すると、参加者は唯一の“206 Partial Content”コードに気付いたかもしれません。これらのコードは、HTTP範囲リクエストに応答するために使用されます。“Range”ヘッダーも、トレース ファイル内で発行されたすべてのリクエストに含まれています。

FTP範囲リクエストと同様に、HTTP範囲リクエストを使用して、リソースの特定のバイト範囲を要求できます。バイト範囲を再組み立てすると、4番目の最終のパケット トレース ファイルが明らかになります。

このトレース ファイルの中身は、ホストとGoogle間の単一のTLSセッションです。TLS交換の“Client Hello”メッセージの要求されたSNI名の中に、追加のサーバ名(www.google.comを除く)が存在します。これは、クライアントがwww.google.com以外のHTTPホスト名を受け入れることを示しているため、参加者に対する重大な警告となります。これらのSNIエントリもASCII文字ではありません。それも警告となります。

追加のSNIエントリの16進数表記は次のとおりです。

1.      61707f4a

2.      6801117501561d11

3.      7811795450435511680144117d585a54116172706162110b75

4.      4c

以前の課題で“PAN{ FLAG }”形式をとることがわかっています。最初のSNIエントリの最初の値0x61を0x50 (“P”の16進数)でXOR演算処理すると、キーとして0x31が明らかになります。これが残りの文字のXOR演算処理に使用されます。そうすることで、この課題のキーを生成します。

PAN{Y0 D0g, I Heard Y0u Like PCAPS :D}

この課題では、標準ネットワーク プロトコルと、これらのプロトコルをアプリケーション層でデータをフラグメント化するためにどのように使用(悪用)できるかについての参加者の知識をテストしました。また、それはかなり長く高難度の課題のため、参加者の忍耐力もテストしました。この課題を解決するために使用されたツールには、Wireshark、一般のコマンド ライン ユーティリティ、Bro、およびPythonのdpktモジュールが含まれます。

脅威6課題: 1つしか存在し得ない

課題作成者: Micah Yates @m1kachu_

ヒントは、課題YARAルールで必須だった唯一の文字列を参照することです。

directions.txtファイルで次の指示が与えられています。

そこで、含まれているアーカイブを解凍し、それに含まれるファイルを調べてみましょう。

上記の条件に基づくと、ルールはこの48個のファイル セットに限定する必要があるようです。ヘッダー、パディングなどのPEファイルで共通の繰り返される要素は除外されます。そこで、バイナリ内のデータと機能を調べます。

この問題への私のアプローチでは、アーカイブ内の2つの最小のファイルを比較し、どのコードが並んでいるか確認します(有料版のIDA-Proを所有している場合は、無料のプラグインBinDiffを使用できます)。2つの最小のファイルを比較します。

  • fc2751ff381d75154c76da7a42211509f7cc3fd4b50956e36e53b4f7653534d5
  • e96de8414e0e438184d2352be17d1f31f2f309fe5f4c7c167dd4375fa28f96b0

比較したファイルを基本ブロック数によってソートしてみると、バイナリ内の最長の関数が見つかります。

bindiffによるとそれらは完全に同じようです。見込みはありそうです。

両方のファイルをIDAのHex View内のsub_10001000で開くと、それらが実際に同一であることがわかります。

この16進数をyaraルールに変換したいため、これらのファイルをbashで開いて、それらをテキストに変換します。その後、一致する16進数の先頭とその後のほぼすべてに対してgrep (あいまい検索)を実行します。

これによって、類似の16進バイトをすべて含む適切なテキスト ファイルが取得されます。

48の一意の行があります。正しい方向に進んでいるようです。次の手順では、それらの52個のワイルドカードの位置を見つけ出すためのpythonスクリプトを記述します。

このスクリプトは、1行ずつチェックし、その後1文字ずつチェックして、16進テキストが一致するかどうかを確認し、一致しない場合は、それを“?”に置き換えます。52番目の“?”が出現した後、ルールを中断し、そのルールを出力します。

最後は、48の全サンプルをキャッチするyaraルールです。

上記のルールを送信すると、結果としてキーが得られます。PAN{8oogI3_WonD3rL4nd}

おまけ:

3つのyara課題すべてのキーを組み合わせると、映画「ラビリンス」についての俳句になります。

脅威7課題: ボーグのドローン ネットワークが侵害されていた

課題作成者: Jeff White @noottrak

この課題では、Windows PE “drone.exe”が用意されています。それを実行すると、ボーグ キューブと、明確な暗号化について説明した若干のテキストで迎えられます。

テキストによると、URL (https://www.youtube.com/watch?v=AyenRCJ_4Ww – the Borg montra!)とキー“borgdata”は、ハッシュ
“374316062B033D0A3E6A746B46560377367A3328393720611641435A
400C0C0B7E6E69E392C2C394E5B5B1717061B0A”を形成するために暗号化されているようです。その後、エラーが発生し、別のハッシュが表示され、プログラムが終了します。

プログラムの文字列を見ると、すぐに多数の文字列が目に付きます。Googleでちょっと検索してみると、このPEはPyInstallerを使用して作成されたようです。

__main__

__file__

%s returned %d

pyi-windows-manifest-filename

Cannot allocate memory for ARCHIVE_STATUS

_MEIPASS2

Cannot open self %s or archive %s

PATH

Failed to get executable path.

GetModuleFileNameW: %s

Failed to convert executable path to UTF-8.

Py_DontWriteBytecodeFlag

Cannot GetProcAddress for Py_DontWriteBytecodeFlag

Py_FileSystemDefaultEncoding

Cannot GetProcAddress for Py_FileSystemDefaultEncoding

Py_FrozenFlag

Cannot GetProcAddress for Py_FrozenFlag

Py_IgnoreEnvironmentFlag

PyInstallerは、“Pythonプログラムをスタンドアロンの実行可能ファイルにパッケージ化するプログラム”です。これで、何を取り扱うのかがわかりました。この課題に取り組むための最も迅速な方法は、Pythonスクリプトをラップしている9MBのPEをリバース エンジニアリングすることでなく、Pythonスクリプトを抽出することだと判断しました。

さらにGoogleで検索し、SourceforgeでPyInstaller Extractorを見つけ、それをバイナリに対して実行してみると、すぐにトレースバックが表示されます。

Traceback (most recent call last):
File “pyinstxtractor11.py”, line 115, in <module>
fd=open(name,’wb’)
IOError: [Errno 2] No such file or directory: ”

トレースバックとそれが発生したコードのセクションを分析すると、ファイルを開く際に問題があるようです。

また、プログラムが開始される前にドロップされたいくつかの興味深いファイルがありました。それらは後から役立つ可能性があります。

この仮定をテストするため、‘name’フィールドを出力し、ディスクに書き込まれた確認済みのファイル名が出力されるのを検証できるように、スクリプトを変更します。

そこで、ファイルが空の場合にファイル名を“broke”とするように指定したtry/except内で単にそのアクションをラップします。

それを再度実行します。今度は、多数のファイルがディスクに書き込まれました。

“broke”ファイルを見ると、それが実際にはプログラムのスクリプトであることがわかります。

スクリプトでは多くのことが進行中で、興味深い主なものとして、調査中にすぐに目に付くものがいくつかあります。

最初に、暗号化関数を調べ、それを復号化します。main()関数にブレークポイントを設定し、コードの追跡を開始し、それが何を実行しているかを把握します。

  • ファイル“borgstruct.cfg”のロードを試みます。それは失敗すると、ディクショナリをそのファイルとしてディスクに書き込みます。
  • ディクショナリ‘key’[1]が1に等しいかどうかチェックします。等しい場合は、ディクショナリのさまざまな場所から1つの文字列が浮かび上がります。このURLには、前述のYoutubeビデオが含まれています。
  • 別の変数を“borgdata”に設定します。

暗号化ルーチンAABBBC(URL,”borgdata”,25)を呼び出します。

  • URLが8で割り切れるかどうかチェックし、割り切れない場合は“@”を埋め込みます。
  • 各変数を1つのリストに分け、URLをキー“borgdata”によってXoR演算処理します。

  • 最初の8個の序数のセットがあります。それらを反転させ、このセットを次のXoR演算処理のキーとして使用します。URLの全長に対してこれを繰り返し続行します。

これは旧式の暗号化ブロック チェーンです。暗号化された各暗号化テキストが次のブロックの暗号化キーとして使用されます。

  • 最後まで処理を続行すると、最終的な序数のリストの順序が逆になります。その後、それを16進数に変換します。

暗号化テキストがわかり、今度はキーを導出する方法がわかったため、復号ツールを作成するための十分なパズルのピースが揃いました。スクリプトからコードをコピーし、難読化を解除することで、逆復号化関数を作成できます。

既知のプレーン テキストと初期のキーを使用してコードを実行すると、drone.exe実行可能ファイルを最初に実行したときに表示されたものと同じ暗号化テキストが、既知のYouTube URLとともに表示されます。

これで、返り値を取得して、それを復号化で使用し、何が得られるか確認できます。

ハッシュ“405E520E4A0E6F3401584E0A4E121E00322C24793B7E6C3304594B0E
41131B032C686707A3E2A2B484553174C0E064724696363753C372F5B40550117061B0A” becomes “???????twitter.com/borgcommlink/status/755587712267104257@@@@@@”です。

そのTwitterアドレスを閲覧すると、さらに別のハッシュで迎えられます。

このハッシュは、別の優れたスター トレックYoutubeビデオに対する復号化用です。

スクリプトを振り返ってみると、スクリプトはポートTCP/2600のpanborgdrone.comにハッシュを送信し、サーバの応答結果に基づいて、シャットダウンするか、または“FLAG REQUEST”と呼ばれる新しい“関数”を使用して設定を更新します。これは期待できそうです。

スクリプトを編集して、Borg Headからハッシュを送信してみましょう。

今度はわずかに異なるエラー メッセージを受け取り、最初に実行したときのようなハッシュはありません。“HIVE|MIND|HASH”の代わりに、“HIVE|ERROR|DATA|874”と示されます。再度Scapyコマンドを確認すると、TCPウィンドウ サイズは、設定ディクショナリから呼び出された変数“scalar_array”によって設定されています。

ウィンドウ サイズを34に設定すると、サーバからの応答に変化が見られます。

2.0設定を見ると、このキーと値はすぐにわかります。

botを新しい設定で再度実行すると、新しいURL (おそらくこれまで作成された中でベストなスター トレック ビデオ)と新しいハッシュを生成するためのXoRキーとして“borgcube”がロードされます。新しいハッシュを送信コマンドに挿入すると、エラー“HIVE|ERROR|CMD|2E”が表示されます。これは、以前に受け取った“ERROR|DATA”メッセージとは異なります。

ウィンドウ サイズを874に変更してもメッセージには変化はありませんでした。ただし、Borg Headのツイートの残りを見ているうちに、ミームとボーグ同士の会話の中にこのちょっとした宝物を見つけました。

このメッセージの背景は、さまざまなコマンド(CMD)とそれぞれのウィンドウ サイズを示す表が入力されたスプレッドシートです。値874が“DRONE CHECKIN”に、値34が“DRONE UPDATE”に、そして、値824が“FLAG REQUEST”に対応していることを確認できます。

最後にもう一度、新しいウィンドウ サイズでスクリプトを更新すると、キーが得られます。

スター トレック ファンのためのスター ウォーズ荒らし…

PAN{m4yTh3f0rc3beWIThyOu}