ステガノグラフィーの解析について
ステガノグラフィーの解析について 目次
●この解説について●ステガノグラフィーの基礎知識：色情報を構成するビットとバイト
●CTFにおけるステガノグラフィーおよび画像形式
●データ埋め込み用ツール リンク集
●「青い空を見上げればいつもそこに白い猫」を用いたデータ埋め込み方法
●参考：日本におけるステガノグラフィーの利用について
この解説について
この解説は、当ソフトウェア『うさみみハリケーン』に付属する汎用ファイルアナライザ「青い空を見上げればいつもそこに白い猫」が実装している、「ステガノグラフィー解析機能」の活用補助を目的として執筆しました。同機能は、特に情報セキュリティにおける、コンピュータセキュリティ技術を競う競技であるCTF(Capture The Flag)での使用を想定しています。また、同機能は、画像ステガノグラフィーの解析ツール「Stegsolve」の互換機能をベースとして、色々な機能拡張を行い、さらに「青い空を見上げればいつもそこに白い猫」に実装された、「文字コード別の文字列抽出」、「バイナリデータの視覚化表示」、「ファイル・データ抽出」および「YARAルールでスキャン」など各種機能との連携を図る形で実装しました。なお、上記ステガノグラフィー解析機能は、すでに画像ファイルへ埋め込まれた各種データの解析だけではなく、画像ファイルへの指定した各種データ(文字列や画像およびファイル等)の埋め込みにも対応しています。これにより同機能は、CTF関連に限らない、ステガノグラフィーがどのようなものかを実践的に学ぶ上でも有用といえます。
下記解説内の、CTFで実際に出題された問題を解析している参考画像は、「青い空を見上げればいつもそこに白い猫」の「ステガノグラフィー解析」機能や「ファイル・データ抽出」機能および「文字コード別文字列抽出」機能を使用しているものです。また、『うさみみハリケーン』および「青い空を見上げればいつもそこに白い猫」等の付属ソフト群をCTFで活用する例として、以下の解説を公開していますので、参考にされることをお勧めします。
・「PicoCTF 2018 Writeup うさみみハリケーンで解いてみた」
・「picoCTF 2019 Writeup うさみみハリケーンで解いてみた」
・「picoCTF 2021 Writeup うさみみハリケーンで解いてみた」
・「picoCTF 2022 Writeup うさみみハリケーンで解いてみた」
・「picoCTF 2023 Writeup うさみみハリケーンで解いてみた」
・「picoCTF 2024 Writeup うさみみハリケーンで解いてみた」
ステガノグラフィーの基礎知識：色情報を構成するビットとバイト
ビットとバイトおよびリトルエンディアン等については、当ヘルプの「基礎用語解説」を参照願います。私たちが普段ネットで目にするような、一般的な画像で使用される色情報は、赤・緑・青の三原色で構成されます。各色について、明るさ(輝度)を意味する0から255(16進数で 0xFF)の値を指定し、この三色を組み合わせることで、多くの色を表現できるようになります(256x256x256 = 16,777,216色)。この各色は8ビット(1バイト)で格納する形式、つまり三色で色情報24ビットとなる画像形式が一般的ですが、各色を5ビットで格納する画像形式などもあります。また、色情報24ビットに加えて、色透過情報(アルファチャンネルのアルファ値)を8ビットで格納し、全体の色情報が32ビットとなる画像形式もあります。色情報が24ビットならば、各色の明るさが最大すなわち全て値255ならば白色となり、全て値0ならば黒色となります。画像ビューアーなどで画像を表示する際には、画像を構成する一つ一つのピクセル(画素)それぞれに対して、RGB計3バイトといった色情報のバイナリデータが用意されることになります。
ちなみに、ビットマップといった画像ファイルにおいて、色情報を構成するバイナリデータは、赤・緑・青(RGB)とは逆順の青・緑・赤・アルファチャンネル(BGRA)の順番で格納されます。DWORDの値のリトルエンディアンと考えればわかりやすいでしょう。
たとえば、赤色の値が160(0xA0)ならば、2進数では10100000となります。ここで、最下位ビットのビット0を書き換えて、2進数で10100001にしても、人間が視覚で色の違いを認識することは困難です。つまり、色情報として、最下位ビットのビット0あるいはビット1は、書き換えても色の見た目にほとんど影響がないといえます。これにより、画像を構成する各ピクセル(画素)に対して、色情報のビット0やビット1に、任意のバイナリデータをビット単位に分解したものを埋め込んでも、画像としては見た目に変化がなく、データの隠ぺいが可能になります。このような任意のデータの隠ぺい技術を「ステガノグラフィー（steganography）」と呼びます。内容を隠したいデータを認識できる暗号化とは異なり、隠ぺいすなわちデータ自体の存在が隠される点がステガノグラフィーの特徴といえます。色情報が24ビットならば、1つのピクセルあたり3バイトとなるため、少なくとも3ビットのデータを埋め込み可能です。
人間の視覚における色への感度から、色の値はビット0からビット2まで3ビット分書き換えても見た目への影響は無いという考え方もあります。しかし、人間の色覚の色認識感度には大きな個人差があることを勘案すれば、ビット0だけあるいはビット0とビット1の書き換えが妥当と見られます。なお、CTFの問題としては、ビット0からビット3まで書き換えた画像が使用されたケースもあります。
＜参考＞赤色の値を1ビット変更した画像比較：色の値は2進数
＜参考＞CTF問題例：各ピクセルの赤色数値のビット0を抽出するとフラグ(CTFにおける答え)文字列が表示される
任意のバイナリデータのビットを埋め込む方法とは別に、埋め込んだビットで画像を表示させるデータ隠ぺい手法もあります。たとえば、画像ファイルの赤色数値のビット0が1であるピクセルだけを強調すると、全く別の画像や文字列画像あるいはQRコードが表示されるわけです。ちなみに、画像あるいはその他のバイナリデータから、ビット0といった特定ビットだけを抽出したものを「ビットプレーン」と呼びます。色情報の数値の書き換えから分かるように、最上位ビット(MSB:Most Significant Bit)であるビット7は画像への影響が最も大きく、最下位ビットであるビット0(LSB:Least Significant Bit)は画像への影響が最小となり、ビットプレーンにもその影響度が反映されます。なお、「MSB」や「LSB」は最上位や最下位のバイトの意味で使用されることもあります。
＜参考＞CTF問題例：各色ビット0にフラグ文字列画像が隠されている(ビットのローテートを使ってビット0強調分と元画像の両方を表示しています)
＜参考＞各ビットの画像への影響度比較：左から元画像、画像の赤色ビット0抽出、同ビット1、(ビット2～ビット5省略)、同ビット6、同ビット7
元画像配布元：写真素材ぱくたそ（www.pakutaso.com）
各色のビット0などに任意のバイナリデータのビットを埋め込んだならば、埋め込み先ビットのビットプレーンには、埋め込み該当部分が均一となり、斑点や模様といった元画像の影響は全く無いという特徴が現れます。これにより、各色のビット0からビット3までデータが埋め込まれたようなケースでも、特定ビットへのデータ埋め込みの有無をおおむね視認可能です。さらに、データを埋め込まれた均一に見える部分とその後の部分に、分かりやすい境界線が見えることもあります。
＜参考＞各色ビット0とビット1へのバイナリデータ埋め込み例：左から元画像、画像の赤色ビット0抽出、同ビット1、同ビット2
上記で解説したデータの埋め込み手法は、各ピクセルの色情報のバイナリデータを使用しているため、画像のトリミングや縮小・拡大などが行われると、色情報が変化し、埋め込んだビットを取り出すことはできなくなります。画像の縮小などが行われても埋め込んだデータを維持可能な、 DCT(Discrete Cosine Transform)変換という画像処理技術を用いた、8x8ピクセルを一つの単位として1ビットを埋め込む方法はあります。しかしこの「周波数領域変換法」などと呼ばれる方法では、上記の1ピクセルに3ビット埋め込む方法の192分の1しかデータを埋め込むことができません。なお、ビットマップからJPEGあるいはGIFへといった画像形式の変換は、画像の縦横サイズがそのままでも色情報が変化して、埋め込んだバイナリデータを取り出せなくなることがあります。
●ステガナリシスおよび犯罪との関連性
上記のようなステガノグラフィーで隠ぺいされたデータの有無を検出する技術は、「ステガナリシス(steganalysis)」と呼ばれます。画像の色情報やDCT係数のヒストグラムあるいはベイズ判定などを用いた検出方法があるものの、ステガノグラフィーにはすでに数多くの手法があり、さらに改良された新たな手法の研究が進んでいるといった理由により、確実な検出は難しいといえます。現実の問題として、特に国際犯罪でやり取りされるデータの画像への隠ぺいは、ほとんどが露見することはないと推測されます。
ステガノグラフィーの犯罪への転用例にマルウェアがあります。おおまかな実行フローの一例としては、まず、無害に見える画像に悪意のあるプログラムコードやモジュール、あるいはスクリプトを隠ぺいします。次に、OSやソフトウェアの脆弱性を突いた攻撃でこの画像を秘密裏にダウンロードしてから、隠ぺいしていたプログラムコード等を画像から抽出・復号し、実行させます。 基本的に、画像に隠ぺいされた悪意のあるプログラムコード等の検出は困難です。同様に、窃取した情報を画像に隠ぺいしてから、送信・アップロードする過程での検出も容易ではないといえます。さらに、このような画像に隠ぺいされたデータは、独自の暗号化あるいは圧縮を施してから隠ぺいされていると考えるのが自然です。マルウェアがステガノグラフィーの技術を用いるのは、隠ぺいされたデータの検出難易度の高さが大きな理由ですが、送信処理などマルウェアとしての活動を行う以上、セキュリティソフトでマルウェアの存在を検出不可能という訳ではありません。ちなみに、ステガノグラフィーの技術を用いるマルウェアは、「Stegware」と呼ばれることがあります。
デジタルデータの著作権保護を目的として、画像等に用いられる不可視型の「電子透かし」は、ステガノグラフィーの応用といえます。電子透かしはトリミングや回転といった画像等の編集加工への高い耐性が求められるため、不可視型の電子透かしを付加する商用ソフトでは、上記の周波数領域変換法をさらに改良したような独自の手法を用いています。
CTFにおけるステガノグラフィーおよび画像形式
ステガノグラフィーは、隠したいデータを任意のファイルに埋め込んでその存在を認識不能にするデータ隠ぺい技術です。しかしCTFにおける問題のジャンル分けでは、画像等のファイルに隠したいデータを単純結合したような、ヘキサエディタ（バイナリエディタ）などを使えば隠されたデータが簡単に認識可能な隠ぺい手法であっても、ステガノグラフィーの問題として分類されます。CTFの問題にも用いられる、一般的な画像形式にはBMPやPNG、JPEG、TIFF及びGIFといった色々な形式があります。各画像形式の特徴および、ヘッダ情報など基本的な構造については、一度は「PICS」などの資料を参照されることをお勧めします。なお、「青い空を見上げればいつもそこに白い猫」では、ファイルのオープン時にファイル形式の判別を行い、その判別結果を表示します。●画像形式の特性を利用する問題
CTFにおいて、バイナリデータ埋め込み型のステガノグラフィーには、色情報を保持可能なPNG形式が用いられることが多いといえます。PNG形式は基本となるビットマップ画像の色情報を損なうことのない、可逆的なデータ圧縮により画像ファイルのサイズを低減させることが可能な画像形式です。また、PNG形式の画像ファイルは、「チャンク」と呼ばれる各種画像情報や画像データあるいは文字列など色々なデータを格納するブロックで構成されており、各チャンクには格納データのCRCの値が付属し改ざんをチェックできるという特徴もあります。
PNG画像のバイナリデータ埋め込み以外では、ヘッダ内の画像縦サイズを書き換えるとフラグ表示、文字列チャンクのうちCRCエラー分がフラグ格納、画像データのチャンクを順番入れ替えでフラグ表示、「zTXt」チャンクにzlib展開しないと読めないフラグ文字列を格納、表示が異常な画像データ部分のチャンクを抽出してzlib展開でフラグ格納ファイル取得といったケースがありました。さらに、画像ビューアーでは表示されない、フラグに繋がる任意のバイナリデータを格納した独自チャンクが含まれているPNG画像も過去に出題されています。特殊なチャンクの解析には、PNGファイルの解析ツール「TweakPNG」などが使用可能です。なお、「青い空を見上げればいつもそこに白い猫」の「ファイル・データ抽出」機能では、一般的な方式で圧縮されたzlibデータの検出と展開に対応しています。ただし、IDATチャンクに格納されるzlibデータを展開して得られるのは、色情報を操作するフィルターの情報が付加された画像データであり、正しい色情報のみのバイナリデータではありません。加えて、画像データが多数のIDATチャンクに分割されているケースもあります。そのため、PNG画像ファイルから正しい色情報のみのバイナリデータを抽出するならば、「青い空を見上げればいつもそこに白い猫」のステガノグラフィー解析機能で「ビット抽出」ダイアログを開き、[ビット抽出前バイト列の保存]ボタンで対処してください。zlib展開が必要で、画像データが複数IDATチャンクに分割されている場合ならば、「TweakPNG」でIDATチャンクを一つに結合すれば、たいてい適切なzlib展開が可能になります。IDATチャンクでは、本来の画像データであるzlibデータの後に、任意のバイナリデータが併せて格納されるケースも想定されます。
JPEG画像の場合は、画像データの終端以降にZIPファイルやフラグ文字列データを結合するといったケースが少なくありません。JPEG形式の画像ファイルは「セグメント」というデータブロックで構成されますが、サムネイル画像あるいはExifデータ(を格納したセグメント)の中にフラグ文字列が隠されることもあります。もしExifデータにGPS情報が含まれているならば、フラグのヒントとなりえます。JPEG画像のExifデータは、Windowsではエクスプローラ上で右クリックから「プロパティ」で確認可能です。「青い空を見上げればいつもそこに白い猫」のメイン画面で[エクスプローラのメニュー表示]ボタンも使用できます。また、『うさみみハリケーン』同梱の簡易エクスプローラー「Portable Explorer」で、選択ファイルの各種メタデータである「拡張プロパティ」としてExifデータを取得することも可能です。なお、Exifデータは仕様として任意のバイナリデータ(バイト列)も格納可能なことに留意してください。画像や動画等のファイルに含まれるExifデータといった、各種メタデータを取得・表示するツール「ExifTool」もあります。
JPEG画像ファイルに他の各種ファイルが結合されていないか確認するには、「青い空を見上げればいつもそこに白い猫」の「ファイル・データ抽出」機能で内包ファイルを検索するアプローチが有用です。また、結合された画像ファイルの一括抽出ならば、「スペシャルねこまんま５７号」が実装している、「指定ファイルから画像等の各種データ抽出機能」で対処可能です(メニュー「ファイル」→「ファイルを指定してデータ抽出」)。なお、「青い空を見上げればいつもそこに白い猫」のステガノグラフィー解析機能では、画像フォーマット情報の取得時に、画像データの後方に単純結合された各種画像ファイルや各種圧縮ファイル、PCAPファイルおよびASCII文字列などを認識し、その情報を表示します(メインダイアログの「ビット抽出」ボタンでフォーマット情報を表示)。ちなみに、Linux用の、指定ファイルに含まれる画像等の各種データ検出を行うツールには「Binwalk」、同様に各種データの抽出を行うツールには「Foremost」などがあります。
GIF画像では、アニメーションGIF形式で、n番目のフレームでフラグが表示されるケースがあります。また、同様にTIFF画像でもマルチフレームを用いた問題が出題されるケースが想定されます。「青い空を見上げればいつもそこに白い猫」のステガノグラフィー解析機能では、アニメーションGIFやマルチフレームTIFF画像の各フレームごとの表示に対応しています。ちなみに、アイコン(ICO)形式ファイルにも複数の画像データ(PNG含む)を格納可能です。PNG画像にもマルチフレームを疑似的に実現してアニメーション表示を行うAPNGという仕様がありますが、これは非公式の拡張仕様でありWindows等で正式対応されていないことから、現状CTFの問題としてはほとんど使われていません。マルチフレームと類似構造の画像形式として、レイヤー画像を格納する画像編集ソフト独自の画像形式があります。たとえば「Photoshop」用のPSD形式や、「GIMP」用のXCF形式があり、どちらもCTFに使用されたことがあります。GIF画像関連の特殊な問題として、アニメーションGIFでは、各フレームごとに表示遅延時間を100分の1秒単位で指定できるため、この数値群からフラグを導く問題も出題されています。各フレームの表示遅延時間の値は、GIFファイル中のバイナリデータ「21F904??」に続く2バイトに格納されています。なお、「青い空を見上げればいつもそこに白い猫」のステガノグラフィー解析機能では、フォーマット解析時に、各フレームごとの表示遅延時間の変化を検出して表示します。また、全フレーム分の表示遅延時間のリストをテキストファイルとして出力可能です。
日本人を対象としたCTFならば、MAG形式といった日本人が開発した画像形式が用いられる可能性も考慮してください。MAG形式画像対応の画像ビューアーは「Susie」など日本人製作のものが複数あります。さらに、かつて日本においては、PCゲーム(主にアダルトゲーム)で使用される独自形式画像の圧縮アルゴリズム等解析が一つの解析ジャンルとして確立されていたことから、独自形式画像の展開(表示)を求められる問題が出題されても不思議ではないでしょう。独自形式画像の解析の隆盛は、数多く公開された特定PCゲーム画像用「Susie」プラグインにその名残を見ることができます。なお、このようなCTFにおいては、フラグ文字列あるいはフラグ文字列を導き出すのに必要なパスワード等が、日本語となるケースも想定されます。そのため、文字コードがShift-JIS/Unicode(UTF-16)/UTF-8などの、日本語文字列の抽出や表示に対応していないツールの使用時には注意が必要です。加えて、日本には日本語キーボードの配列を文字変換表に見立てた、例えばひらがな「ちとしは」をアルファベット「ASDF」に変換する、いわゆる「みかか変換」という、「単一換字式暗号」に分類される簡易暗号化手法があることに留意してください。海外のCTF出題例（特定言語用文字と英数字の単一換字式暗号）を参考にした、ひらがなの、あいうえお順、いろは順あるいはUnicode順に対して、ABC順のアルファベットを割り当てる簡易暗号化もありえます。
CTFの問題としては、現在では一般的に使用されない、特殊な画像形式といえるPPM形式(Portable pixmap)が用いられるケースもあります。PPM形式は、ヘッダがASCIIの文字列形式となっており、その後にASCII文字列あるいはバイナリデータで24ビット画像の色情報データを指定します。色情報をASCII文字列で指定する「P3」形式ならば、その画像ファイルは下記例のようなASCII文字列で構成されます。この文字列からなるテキストファイルの拡張子を「ppm」にすれば、「XnView」などの画像ビューアで画像として表示します。 以下の例では、最初の「P3」が形式の指定、3が横サイズ、2が縦サイズ、255が輝度の最大値を意味し、これらの要素でヘッダが構成されます。ヘッダの後は各ピクセルの色情報をRGB3バイト分で指定した内容が続きます(ピクセル順は左から右、上から下)。値の区切りには改行や半角スペースなどが使用可能です。改行には実行環境によってバイナリデータ「0D0A」(CR+LF)や「0A」(LF)が使用されますが、「XnView」などWindows用の画像ビューアならば、どちらの改行形式でもPPM画像表示には問題ありません。最初の形式指定が「P6」ならば、色情報データはASCII文字列ではなくバイナリデータでの指定となり、ヘッダの後にはRGB3バイト単位のバイト列が続きます。PPM形式での色情報の並びはRGBの順であり、ビットマップのようなBGRの順ではありません。ちなみに、PPM形式には、ほとんど同じ仕様である、黒白2色画像のPBM形式(P1,P4)とグレースケール画像のPGM形式(P2,P5)があります。
＜参考＞PPM形式ファイルの例
P3 #comment 3 2 255 80 80 80 255 255 255 0 0 0 255 0 0 0 255 0 0 0 255CTFの出題例としては、P3形式かつヘッダを削除したケースがありました。また、P6形式からヘッダを除去したものに相当する、ピクセルの色情報のバイト列だけで構成されるバイナリファイルが出されたケースもあります。P3形式のテキストファイルと推測されるならば、テキストエディタでファイル先頭にヘッダを追加し、さらに拡張子を「ppm」に変更してから、「XnView」などのPPM形式対応画像ビューアで表示可能か試すことになります。基本的に、色情報のデータから画像の縦横サイズは判明せず、かつ縦横サイズ指定が不適切ならば画像ビューアでも表示に失敗するため、ヘッダ内の縦横サイズを変更しながら表示可能か試していくことになります。色情報のみのバイナリファイルと推測されるならば、まず、「青い空を見上げればいつもそこに白い猫」の「バイナリデータ視覚化表示」機能で、表示カラーパターンを「RGB配列(24bit)」あるいは「RGB配列(32bit)」に指定し、バイナリデータをそのまま画像として表示してみます。この際、表示幅すなわち横サイズを動的に変更して表示することもできます。ただし、同カラーパターンは画像の横サイズが2048までを想定しており、また、色情報の格納順序により赤色と青色の値が逆になることもあります。「バイナリデータ視覚化表示」機能で対象ファイルが画像データであることが確認できたら、ファイルの拡張子を「data」に変更し、画像編集ソフト「GIMP」で開くと、色情報の詳細や縦横サイズ等を指定してから画像データとして表示可能です。他のアプローチとして、ヘキサエディタを使って、バイナリデータの先頭にP6形式のヘッダを追加するというやり方もあります。推定画像サイズが400x200ならば、先頭追加バイナリデータとしては、「50 36 0D 0A 34 30 30 0D 0A 32 30 30 0D 0A 32 35 35 0D 0A」となります。ちなみに、「青い空を見上げればいつもそこに白い猫」のステガノグラフィー解析機能では、「ビット抽出」機能により、読み込んだ各種画像ファイルのピクセルの色情報だけを、RGB/BGR順といった条件を指定してバイナリファイルとして保存することができます(ビット抽出前バイト列の保存)。
PPMファイルのようなテキストベースの画像と類似する、テキストファイルから図形を出力する方法として挙げられるのは、SVGファイル、gnuplot用スクリプトあるいはアスキーアートなどです。これらは皆CTFの問題に使用されたことがあります。
CTFに使われた、上記以外の画像形式には、WebP形式画像ファイルやアニメーションカーソルのANIファイルなどがあります。基本的に、見慣れない画像形式のファイルが与えられたならば、画像編集ソフトで画像形式変換やフレーム抽出を行い、BMPやPNG形式画像にすれば対処可能です。
上記の画像解析結果として、たいていはビットの抽出や強調でフラグが表示されるのですが、画像から抽出されたバイナリデータが2進文字列だったり、画像の色情報のビット0を強調すると2色で表示される2進ビットパターン(白ピクセル＝1、黒ピクセル＝0など)あるいはQRコードということもあります。この場合は、16進数への進数変換とBase64デコードあるいは、ASCII文字列やモールス符号文字列への変換などでフラグを取得できるケースが多いといえます。「010000110100000101010100」のような2進文字列をASCII文字列に変換するといった、各種コンバータやデコーダおよびQRリーダーは、ネット上に「CyberChef」といったWebツールとして多々公開されています。2進/16進/10進文字列のASCII文字列への変換や、同文字列を数値とみなしての算術演算・論理演算・左ビットシフト（2n倍）および、Base64とROT13のデコードならば、同梱の多倍長整数に対応した各種演算ソフト「UMECappend」(要.NET Framework 4.5 以上)でも可能です。日本で開催されるCTFの問題では、2次元コードとしてはQRコードを使用するのが一般的ですが、海外のCTFでは他の2次元コードである、「MaxiCode」や「DataMatrix」が使用されることもあります。 なお、CTF関連に限らず、Webツール使用時に入力した文字列やアップロードした画像等は、Webツールのサイト運営者が二次利用する可能性に留意してください。
＜参考リンク＞
・TweakPNG
・pngcheck
・ExifTool ／ ・ExifToolGUI(ExifToolのWindows用フロントエンド) ／ ExifToolGUI配布ページ
・CyberChef
●画像形式に依存しない問題
なお、いずれの画像形式にせよ、ネット上でオリジナルの画像が入手可能であり、そのオリジナルとの相違点抽出でフラグあるいはヒントが得られるケースもあります。上述のアプローチがうまくいかないならば類似画像検索を試してみてください。また、画像形式に関係のない他のアプローチとして、問題画像を画像編集ソフトで開いてから、塗りつぶし機能を使って一部を塗りつぶすことでフラグ文字列が浮かび上がるという可能性もありえます。画像の表示内容に一見異常がない場合は、ヘッダ内にある画像の縦サイズや横サイズを適切に書き換えて増加させると、フラグが表示されるケースもあります。さらに、画像が壊れているように表示されるならば、本来色情報が格納されているバイト列そのものを、任意のバイナリデータ(単純文字列、実行ファイル、プログラムコード、画像ファイル、音声ファイル、アーカイブファイル、PCAPファイル、Base64/Base58/Base32/BinHex/2進/ISH文字列等)に置き換えている可能性が高いと判断してよいでしょう。問題の画像が画像編集ソフト等で表示不能ならば、問題画像ファイルのヘッダを部分的に書き換えている、あるいは一部削除しているとみられるため、問題画像のヘッダを「へきさにゃん」などのヘキサエディタで復元して画像(フラグ)が表示できるようになるか試してみてください。
＜参考＞ビットマップ、PNG、JPEG、GIFおよびTIFFファイルのファイルヘッダ表示例
・ビットマップ(BMP) 42 4D B6 00 12 00 00 00 00 00 36 00 00 00 28 00 BMｶ 6 ( ・PNG 89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 臼NG IHDR ・JPEG FF D8 FF E0 00 10 4A 46 49 46 00 01 01 01 00 01 ﾘ・ JFIF ・GIF 47 49 46 38 39 61 F4 01 F4 01 F7 FF 00 47 4E 54 GIF89a・・・ GNT ・TIFF(4D4D002Aで始まる形式もあり) 49 49 2A 00 4C 57 07 00 80 00 E0 40 08 24 15 FF II* LW 漾 $
関連して、ビット抽出で取得、あるいは画像ファイルに単純結合されたZIPファイルなどでも、ファイルヘッダが書き換えられていたり、ヘッダ以降が暗号化されているケースがありました。この種のケースでは、ビット抽出に失敗した、あるいはZIPファイルが壊れているという「思い込み」が問題解決の妨げになります。
ただし、過去のCTFにおいて、問題を解く過程で抽出されるZIPファイルが、おそらく出題者の意図しない、本当に壊れたZIPファイルとなっていたことはあります。このケースでは、圧縮・解凍ソフト「Explzh」でZIPファイルの修復を行うと、含まれているファイル全てを認識および解凍することができました。
上で述べたような、画像のヘッダを復元したり、ヘッダ内にある画像の縦サイズあるいは横サイズを修正するアプローチとは逆に、画像を壊す、つまり画像データ格納箇所の1～数バイトを適当な値で書き換えて変化を見るという、特殊なアプローチが有効なケースもあります。
＜参考リンク＞
・類似画像検索
●画像合成
もし、問題画像が2枚セットならば、たいてい画像合成でフラグを得ることが可能です。問題としては、色情報の値に対するXOR演算での合成が想定解としてよく用いられます。GIF画像やTIFF画像などでマルチフレーム画像の場合も、フレームと次のフレームでXOR演算を行うとフラグが表示される可能性があります。また、問題画像が、2つの同形式画像ファイルを単純結合したものという可能性も考慮してください。この場合、ファイル終端を意味する「正常な」バイト列だけでの判断では、単純結合を見逃しかねません。なお、複数画像の単純結合ならば、「青い空を見上げればいつもそこに白い猫」の「ファイル・データ抽出」機能あるいは、「スペシャルねこまんま５７号」が実装している、「指定ファイルから画像等の各種データ抽出機能」(メニュー「ファイル」→「ファイルを指定してデータ抽出」)で対処可能です。画像2枚の単純結合ではなく、1枚の画像の上半分と下半分での合成処理でフラグが表示されるケースや、1枚の画像でアルファチャンネルビット0と緑色ビット0の抽出画像をXOR合成処理でフラグが表示されるケースもありました。
画像合成の問題は、1回の合成処理でフラグを得られることが多いのですが、2回以上の合成処理がフラグ取得に必要となるケースもあります。実際の出題例では、まず画像1と画像2のXOR演算結果を別途画像3として保存し、さらに画像1と保存した画像3との乗算でフラグにつながるQRコードが得られました。必要な2回の合成方法はXOR演算と乗算およびその順序に限らず、減算からXOR演算というケースもありました。このような問題では、1回目の合成処理でフラグの断片らしきものが表示されたかどうかに関わらず画像として保存し、その保存画像を用いて2回目の合成処理を試行します。ただし、1回目の合成処理で「相違箇所を抽出」により、フラグがおおむね判読可能になるケースも想定されます。
基本的に、CTFで問題として用いられるのは色情報のビット数が同じ画像のペアですが、片方の画像は色情報のビット数を変更することで、ピクセルの色情報の値に対するXOR演算などではフラグが得られないようにしている問題もありました。このようなケースは、片方の画像の色情報を画像編集ソフトで変更し、両方の画像とも24ビット以上に揃えることで対処可能です。また、色情報のビット数つまり色情報のバイト列に依存しない、ピクセル表示色をベースとした相違点の抽出や演算処理でも対処できます。「青い空を見上げればいつもそこに白い猫」のステガノグラフィー解析機能の「画像合成」ダイアログでは、色情報が24ビット未満の画像は内部的に24ビット化を行い、適切な合成処理が行えるようにしています。色情報のビット数を含む画像のフォーマット情報は、同機能の「ビット抽出」ダイアログで表示可能です。ちなみに、このような色情報のビット数が操作されているケースでは、たいてい、2枚の画像に明らかなファイルサイズの違いが見られます。
問題が多数の縦横同サイズ画像ファイルで構成され、各画像の同じ位置にあるピクセルを比較して一番明るいピクセルの色情報を抽出する「比較明合成」か、一番暗いピクセルの色情報を抽出する「比較暗合成」によりフラグが得られるケースは、画像ファイル群に対する比較明合成・比較暗合成対応の画像編集ソフトあるいは、後述するプログラミングによる独自処理で対処します。この、「多数の縦横同サイズ画像ファイル」は、アニメーションGIFの各フレームという形をとることもあります。
画像の合成問題では、片方の画像がヘッダを削除された、ピクセルの色情報のバイト列だけで構成されるバイナリファイルとなっていることもあります。この場合は、BMP画像のヘッダを作成してから合成するか、後述のプログラミングによる独自処理で合成します。
この種の画像合成問題に用いられるデータ隠ぺい技術は、「視覚復号型秘密分散法」と呼ばれます。これは、複数の画像に分散された画像データ(文字列画像を含む)を、重ね合わせた画像から目視で復号する暗号技術です。分散された画像のうち、閾値以上の枚数を重ね合わせないと復号できません。なお、目視での復号には、2枚の画像を重ね合わせない、ステレオグラムの立体視を要するケースもあります。
＜参考＞CTF問題例：2つの画像を合成するとフラグ文字列が表示される
●ファイルの中の画像を抽出
CTFにおいては、パケットダンプファイルやPDFファイルに含まれる画像ファイルといった、特定形式ファイルから画像ファイルを適切に抽出することを求める問題も出題されることがあります。このような問題では、最終抽出対象ファイルをツールで簡単には抽出できない、複雑な入れ子構造となっているケースも見られます。
たとえば、JPEGファイルに含まれるサムネイル画像は画像ビューアで表示可能ですが、サムネイル画像に含まれるサムネイル画像は抽出処理を行わないと見ることはできません。CTFでは「サムネイル画像のサムネイル画像」でフラグが表示されるケースがあります。通常サムネイル画像自体もJPEG画像なので、下記の例のように、入れ子になっているJPEG画像バイナリデータから、対になる(間にFFD8やFFD9が入らない)「FF D8 から FF D9」のバイト列を切り出していくとサムネイル画像の抽出が可能です。サムネイル画像の表示のみが目的ならば、バイト列「FF D8」の出現順に、それより前の全バイナリデータを削除していくというやり方もあります。このような、ファイルの一部を切り出しあるいは削除するアプローチでは、「へきさにゃん」などのヘキサエディタが役立ちます。
(例)JPEGファイル内のバイト列：FFD8...{FFD8...[FFD8...FFD9]...FFD9}...FFD9
{ }：サムネイル画像
[ ]：サムネイル画像のサムネイル画像(通常画像ビューアでは表示されない)
他の画像形式では、PNG画像の独自チャンクにPNG画像のバイナリデータを格納するケースが想定されます。PNG画像の各ピクセル色情報の特定ビットを抽出するとPNG画像となり、そのPNG画像から同様に色情報の特定ビットを抽出すると新たなPNG画像になる、ステガノグラフィーの技術を用いた入れ子構造の問題は、過去に出題例があります。
入れ子構造が可能な他の例としては、EXEファイルといった実行ファイルのリソースが挙げられます。実行ファイルのリソースには、一般的なリソースのアイコンやダイアログ情報およびマニフェストなどに加え、任意のバイナリデータも格納することができます。そのため、実行ファイルAのリソースに実行ファイルBを格納し、Bのリソースには実行ファイルCを格納しておき、実行ファイルCのリソースに隠したい画像等のデータを格納しておくといった手法も可能です。リソースとしてのビットマップ画像(RT_BITMAP)は、BMPファイルとは構造が異なるため、一般的なファイル抽出ツールでは対処できません。
実行ファイルのリソースに関しては、.NETアプリケーションの実行ファイルに含まれる、特殊なリソース「アセンブリ埋め込みリソース」に留意してください。.NETアプリケーションではない、C++言語等で開発された一般的なPEエディタやリソースエディタでは、通常のリソースとは異なるこの特殊なリソースを認識できないためです。ただし現在では、このアセンブリ埋め込みリソースの画像ファイル等表示に対応した、.NETアプリケーションであるリソースビューアや逆コンパイラがあります。当ソフトウェア『うさみみハリケーン』では、同梱のリソース文字列ビューア『ResStrView_DotNET35.exe/ResStrView_DotNET40.exe』で、.NETアプリケーションに限定されない実行ファイルの各種リソース解析・内容表示と、.NETアプリケーションの実行ファイルに含まれる、アセンブリ埋め込みリソースの画像等表示に対応しています。ちなみに、ResStrView_DotNET??.exeで自分自身の実行ファイルをオープンすると、アセンブリ埋め込みリソースであるBMPファイルの確認と表示が可能です。
ヘキサエディタなどを用いない汎用的なアプローチとしての、特定ファイルからの画像ファイルの抽出は、「青い空を見上げればいつもそこに白い猫」の「ファイル・データ抽出」機能あるいは、「スペシャルねこまんま５７号」が実装している、「指定ファイルから画像等の各種データ抽出機能」(メニュー「ファイル」→「ファイルを指定してデータ抽出」)で一括処理可能です。画像ファイル等の後にZIPファイルやRARファイルといった各種圧縮ファイルが結合されている場合ならば、「7-Zip」などの圧縮・解凍ソフトで当該画像ファイルを開くと、結合されたZIPファイル等を認識し直接解凍可能なため、ヘキサエディタなどを用いた目視と手作業でZIPファイル等を切り出さなくても済みます。また、7-Zipは、PE形式の自己解凍ファイルやELF形式のインストーラーといった実行ファイル型の圧縮ファイルに加え、SquashFSといった圧縮ファイルシステムにも対応しています。
ちなみにCTFでは、上記の入れ子構造と同種の問題として、「何重にもエンコードされた文字列」や「何重にも圧縮されたファイル」などが出されることもあります。基本的に、このような問題には自動化するプログラムやスクリプトを組んで対処します。Windows上で通常使用されない圧縮形式のファイルならば、7-ZipあるいはExplzhで解凍できる可能性があります。マルウェアでの使用例があるaPLibライブラリによる圧縮もありえます。
上記のような入れ子構造ではなく、種類が異なる複数のファイルを単純結合しているパターンもあります。この場合も、「青い空を見上げればいつもそこに白い猫」の「ファイル・データ抽出」機能あるいは、「スペシャルねこまんま５７号」が実装している、「指定ファイルから画像等の各種データ抽出機能」などで対処します。また、既知ファイル形式のヘッダ出現順に、それより前の全バイナリデータを削除していくというやり方で、結合されたファイルそれぞれを対応ツールで処理すなわち表示や解凍などが可能と見られます。
＜参考＞CTF問題例：ELF実行ファイルと単純結合されたJPEG画像ファイル両方に分割済みフラグ文字列が含まれる
＜参考リンク＞
・7-Zip
●独自の画像処理が必要な問題
CTFにおいては、ピクセルのX座標が奇数や、画像データ先頭からのオフセットが素数、あるいは赤色の輝度が閾値以上といった、特殊な条件を満たすバイトにだけLSBにデータを埋め込むといったケースも想定されます。また、各ピクセルの青色の値から赤色の値を減算すると文字コードASCIIの表示可能文字(0x20から0x7E)でフラグ文字列になる、あるいは隣接する2ピクセルの色情報の数値差が1かゼロでビット列を構成するといった、色情報の値の演算が必要な問題もありました。このような問題にも柔軟に対処できるように、自分が扱える開発言語を使って、画像ファイルを読み込んでから、各ピクセルの色情報の値に対し任意の演算処理や抽出処理ができるようになっておくことが望ましいといえます。Visual C++/C#やPythonなどでは、画像のピクセル操作を簡単に行える仕組みが用意されています(Visual C++ならCImage、PythonならPILなど)。
＜参考＞Visual C++ での画像処理例(各色の値をXORでビット反転)
CImage img;
if(SUCCEEDED(img.Load(FilePath)) )
{
unsigned char * pCol = 0;
long w = img.GetWidth();
long h = img.GetHeight();
int bits = img.GetBPP();
for(long y = 0; y < h; y++)
{
for(long x = 0; x < w; x++)
{
pCol = (unsigned char *)img.GetPixelAddress(x, y);
pCol[0] = pCol[0] ^ 0xFF; //B
pCol[1] = pCol[1] ^ 0xFF; //G
pCol[2] = pCol[2] ^ 0xFF; //R
}
}
img.Save(NewFileName);
}
他の画像処理が求められるまれなケースとして、画像の高速フーリエ変換(FFT)や、JPEGファイルでのYCbCr色空間とRGB色空間の変換、パレットの編集または抽出、PNG画像のインターレース各段階を表示、あるいはヒストグラム閾値設定がフラグ表示に必要なケースもありました。このようなケースには、その都度対処可能な画像編集ソフトやライブラリを探してみるというアプローチで十分と考えられます。画像処理ツール群「ImageMagick」が役立つこともあるでしょう。基本的に、問題が単一画像かつ、画像上に「読めそうで読めないフラグ文字列」がすでに見えている場合は、画像編集ソフトの各種フィルタ適用でフラグが読解できる可能性があります。なお、エッジ抽出などのフィルタは、フィルタ名が同じであっても各画像編集ソフトでの適用結果に差異があり、特定の画像編集ソフトではフィルタ適用でフラグが読めるようになるが、別の画像編集ソフトでは同名フィルタ適用でもフラグが読めないケースも生じています。そのため、GIMPやPhotoshopおよび使い慣れた画像編集ソフトといった、複数の画像編集ソフトを用意しておくと良いでしょう。ちなみに、エッジ抽出のアルゴリズムは「ラプラシアン」や「ソーベル」など複数あり、さらに各アルゴリズムで使用する係数も複数パターンをとりうることが、各画像編集ソフトでのフィルタ適用結果に差異を生じさせています。CTFでは、エッジ抽出(ラプラシアン)フィルタ適用が想定解だが、1回適用ではフラグが一部読めず、その適用後画像へさらに1回適用することでフラグ全文字が読解可能になる問題もありました。
●その他の特殊な問題
過去にはステレオグラム(シングル・イメージ・ステレオグラム)を用いた、フラグ文字列が立体的に浮かび上がる画像が問題に用いられたこともありますが、これは容易に立体視が可能であり、特に解析が必要というものではありませんでした。なお、ステレオグラムの解析については、ネット上でWebツール（Stereogram Solver/Magic Eye Solver）や、画像編集ソフトあるいはプログラミングによるアプローチ例が公開されています。
問題画像に用いられる可能性という面では、色情報で構成されるプログラミング言語である「Piet」あるいは類似の独自プログラミング言語の使用がありえます。しかし、これらのプログラミング言語はもはやステガノグラフィーの範疇とは言い難いため、「このようなものもある」という認識で十分でしょう。なお、Pietなどのいわゆる「難解プログラミング言語」で、CTFでの使用例があるものとしては、Pietの他に、「Brainfuck」、「Ook!」および「Malbolge」などがあります。これらの、ソースコードを部分的に解釈しながら実行していくインタプリタ（Interpreter）が、Webツールとして公開されています。もし、取得されたテキスト内に出現する文字列の種類が少ない場合は、難解プログラミング言語やその亜種ではなく、モールス符号を変換したものという可能性があります。CTF出題例としては、モールス符号の「トン、ツー、スペース」がそれぞれ文字列「nya、meow、purr」に変換されているケースがありました。
CTFでの他のジャンルとの関連性から、「Stegosploit」という、スクリプトやプログラムコードが埋め込まれた画像ファイルを用いて脆弱性を攻撃する手法が、形を変えてCTFの問題に応用されることも予想されます。マルウェアの解析で実際に行われる、「画像から悪意のあるコードを抽出し復号する処理の解析」を模した問題も想定されます。
＜参考リンク＞
・Piet(色情報で構成されるプログラミング言語)
・Piet仕様解説
・Stegosploit解説
●汎用的なアプローチの利用
上記ではステガノグラフィーの解析としてのアプローチや考え方について述べています。しかし、実際には、プログラム解析における基本的かつ汎用的なアプローチである、「バイナリデータから文字列抽出」や「バイナリデータの視覚化表示」および「ファイル・データ抽出」で、フラグそのもの、あるいはフラグのヒントが得られることもあります。「青い空を見上げればいつもそこに白い猫」では、このような汎用的なアプローチにも対応しており、ステガノグラフィーの解析に役立つと見られます。ちなみに日本では、視覚化されたバイナリデータから、目視で解析の手がかりとなる特定データあるいはパターン等を探るアプローチのことを、「目Grep」と呼びます。
＜参考＞CTF問題例：PNG画像ファイルから文字列抽出でフラグ文字列が見つかる（本来は文字列チャンクの解析を求める問題と見られる）
●ステガノグラフィー解析自動化ツール
現在では、複数のステガノグラフィー解析アプローチを一括実行する、Webツール「Aperi'Solve」が公開されています。このようなステガノグラフィー解析自動化ツールは、全く手掛かりのない状況でのアプローチや、時間制限があるCTFでのアプローチなどに有用とみられます。なお、ステガノグラフィー解析の初心者の方は、この自動化されたアプローチでフラグを取得できた場合には、学習面で意味をなすために、「なぜフラグを取得できたのか」を自分なりに説明できるよう考えてみることをお勧めします。
＜参考リンク＞
・Aperi'Solve
●ステガノグラフィー解析ツール対策
CTFの問題作成者によっては、「Stegsolve」のようなステガノグラフィー解析ツールでは簡単には解析できないよう対策を施してくるケースがあります。これには、既存のツールに頼らないプログラミングでの自力解決を求めるという、出題者の意図も窺えます。対策の具体例としては、Stegsolveの仕様上の制約を利用するケースが挙げられます。Stegsolveでは、問題画像からビットを抽出してバイト列を構成する際に、必ずバイトのMSBからビットを充填していくという仕様となっています。そこで、抽出したビットをバイトのLSBから充填しないとフラグ等が得られないようにした問題が、すでに複数のCTFで出題されています。また、StegsolveはTIFF画像に対応していないため、問題画像がTIFF画像ならば解析はもちろん単独表示やマルチフレーム表示もできません。Stegsolveは色情報が24ビット未満の画像を自動的に24ビット化して表示することから、24ビット化すると画像上のフラグが解析困難になる、パレットを用いた8ビット画像が問題に出されたケースもあります。同様に「zsteg」解析対策例として、赤色の複数ビットにデータが埋め込まれ、ビット抽出順をLSBからにしないとフラグ等が得られないといったケースも想定されます。
＜参考＞Aperi'Solve（zsteg）解析対策画像の作成時設定例および解析時設定例
他の解析対策としては、解析かく乱用のダミーデータの使用が挙げられます。これは、ビットを抽出して画像表示により、明らかに赤緑青の各色ビット0にデータが埋め込まれていると分かるものの、実は青色ビット0に埋め込まれたデータはダミーで、赤と緑のビット0だけでビット抽出を行いバイト列を構築しないと、フラグが得られないといったケースです。他の解析かく乱とみられる例には、ビット抽出により得られたPNGファイルが、先頭から終端までのバイトの並びを逆転したものとなっており、一見ビット抽出に失敗したように見えるケースがありました。
＜参考リンク＞
・Stegsolve (要Java)
●補足：プログラム解析におけるステガノグラフィー解析の有用性
ステガノグラフィーの解析には、画像ファイルにおけるフォーマット、色情報を構成するバイナリデータ(RGBAバイト列)や、バイナリデータ内のビットとバイト、LSBとMSBなど、プログラム解析の基礎事項に繋がる要素が含まれています。そのため、ステガノグラフィーの解析を通してこれらの要素を理解することが、特にプログラム解析初心者の方にとって、プログラム解析の基礎事項のより深い理解に役立つとみられます。ステガノグラフィーの解析ならば、バイナリデータにおけるビットを画像形式で視覚的に認識できるという、解析アプローチとしての分かりやすさも特筆すべき点といえます。
CTFにおけるステガノグラフィーの解析は、プログラム解析の基本でもあるビット・バイト・バイナリデータ・ファイル形式等の理解と操作、そして若干の情報収集と考察および発想の力を問われるものが多く、極端に奇をてらった問題が出されることは少ないといえます。CTFでの大量得点が見込まれる分野ではありませんが、1度はステガノグラフィーの解析をしっかり学ばれることをお勧めします。
●補足：画像以外のステガノグラフィーについて
CTFでのステガノグラフィーの問題はほとんどが画像ファイルを用いたものですが、まれに音声ファイルが使用されることもあります。この場合は、オーディオ編集ソフト「Audacity」等でスペクトログラムを見れば、フラグ文字列やビットパターンあるいはモールス符号文字列などを読み取れるケースが多いといえます。また、CTFの問題に使用されたことがある、WAVファイルといった音声から画像に変換する方式としては、「Slow Scan television （SSTV、低速度走査テレビジョン）」もあります。この方式専用の復号用ソフトウェアが、ネット上で複数公開されています。音声から数字に変換する方式ならば、「DTMF」（トーン信号）が使用可能であり、フラグ文字列のバイト列を2進数や10進数の多倍長整数として表現できます。なお、WAVファイルに対して、波形データの値のLSBを抽出してバイト列を構築するステガノグラフィー手法があり、この手法を用いて実行ファイルを抽出・復号するマルウェアも存在することから、CTFの問題にこの手法が採用されるケースも想定されます。
画像ではなく動画ファイルが問題に用いられたならば、動画編集ソフトで各フレームをチェックしていくことになります。各フレームの差分にもヒントがないか注意してください。また、MP4ファイルならば、データ格納構造（ボックスのレイアウト）を書き換えて、任意のファイルを埋め込んでいる可能性も考慮してください。
3DCGを用いた問題の出題例はごく少数です。これは、問題のファイルを開くにはWindows用「3D ビューアー」あるいは専用の3DCGソフトウェアが必要となるうえ、3Dモデルの移動や視点変更などその3DCGソフトウェアの操作方法を問う問題に帰結しかねないためと推測されます。なお、日本においては、「MikuMikuDance」（MMD）という無償の扱いやすい3DCGソフトウェアが普及しており、日本や海外のユーザーにより膨大な数の人型3Dモデル、モーション、その他3Dモデルおよびエフェクト等が無償で公開されているという特殊事情があります。人型3Dモデルを用いることにより、たとえばフラグ文字列を、人文字、ジェスチャー、手旗信号、モールス符号打鍵モーション、回光通信機操作モーション、「踊る人形」、さらには、聴覚障害への理解促進を兼ねた、手話または手話で使う指文字および、発声モーション（要読唇）といった、色々な方法で表現可能です。
可読文字列に不可視な文字列等のデータを埋め込むステガノグラフィー手法としては、難読化シェル芸で知られるkanata氏による「異体字セレクタを利用したステガノグラフィ」や、「ゼロ幅文字」（Zero-Width Characters）を用いる方法など複数挙げられ、これらの手法もCTFの問題に採用される可能性があります。
CTFは情報セキュリティと高い関連性があります。そのため、（特に過去1年以内に発見された）マルウェアで使用された独特なデータ隠ぺい方法が、そのままCTFの問題に採用されるという可能性を考慮してください。このようなCTF出題例の一つとして、NTFSファイル・システムの代替データ・ストリーム（ADS）を用いたケースが挙げられます。
＜参考リンク＞
・Audacity
・Sonic Visualiser
・MP3Stego
・DeepSound
・tcsteg3.py
データ埋め込み用ツール リンク集
CTFにおいては、以下のようなデータ埋め込み用ツールが、一切のヒントなしで使用されることもあります。データ取り出し時にパスワードを求められたならば、画像の表示内容の名前、CTF名、会場名、問題名、画像ファイル名あるいは「123456」など、ありがちなパスワードを試していくことになります。また、このようなパスワードでは、空文字列が設定されている可能性も考慮してください。さらに、「Steghide」適用時に設定されたパスワードならば、「Stegseek」や「StegCracker」などの、パスワード解析ツールを使うアプローチもあります。・Steghide
・Steghide オンライン版(実行ファイル版と機能差あり)
・OpenStego
・Pythonを利用した画像に文字データを隠ぺいするライブラリ (日本製、要Python)
・Stepic (要Python)
・cloacked-pixel (要Python)
・wbStego (画像・テキスト・PDF等へのデータ隠ぺい)
・SilentEye
・Steganography Software F5 (要Java)
・Digital Invisible Ink Toolkit (要Java)
・Invoke-PSImage (RGB色情報のBit0からBit3にデータ埋め込み、マルウェアでの使用例あり)
・Stegseek
・StegCracker
もし、このようなデータ埋め込み用ツールを個人的な各種データ隠ぺいに用いる場合は、不測の事態に備えて、同ツールの配布ファイルと動作環境（仮想PC）のバックアップを用意しておくことを強くお勧めします。
「青い空を見上げればいつもそこに白い猫」を用いたデータ埋め込み方法
「青い空を見上げればいつもそこに白い猫」のステガノグラフィー解析機能は、ステガノグラフィーの技術を用いる、画像への各種データ埋め込みにも対応しています。ただし、このデータ埋め込み処理では、埋め込むデータは生データのままであり圧縮や暗号化等を施さないことから、解析耐性は低いといえます。そのため、「青い空を見上げればいつもそこに白い猫」による画像への各種データ埋め込み時には、必要に応じて、事前に埋め込むデータを複数に分割（秘密分散）、暗号化あるいは、長いパスワード付きのZIPファイルに圧縮といった解析対策を施してください。●色情報のビット書き換えを用いた文字列・ファイル埋め込み方法
「青い空を見上げればいつもそこに白い猫」のステガノグラフィー解析機能を用いた、画像への文字列やファイルの埋め込みならば、「ビット抽出」画面を表示して行います。ビット抽出の設定をそのままビット埋め込みの設定として使用します。「ビット抽出」画面で、埋め込み対象ビットと埋め込み形式等を指定し、さらに画面最下部で埋め込む文字列あるいはファイルパスを入力して、「複製画像を保存」ボタンです。文字列の埋め込み時には、選択された文字コードで入力文字列をバイナリデータ化してから埋め込みます。元画像の表示サイズや埋め込み対象ビットの選択によっては、埋め込む文字列やファイルの全データを埋め込むことができないケースもあり、その場合は埋め込み対象ビットを増やす等の対処が必要になります。
●画像合成を用いた画像埋め込み方法
「青い空を見上げればいつもそこに白い猫」のステガノグラフィー解析機能で画像合成処理を行って、元画像に別の画像を埋め込むことが可能です。例えば、画像の色情報として、元画像のビット1からビット7と、埋め込み用画像のビット0を合成するわけです。「画像合成」画面を表示し元画像と埋め込み用画像を指定してから、「色合成方法」に「画像2のLSB(Bit0)を埋め込み」あるいは「画像2のBit1を埋め込み」を選択して、表示された合成結果画像を保存します。
画像埋め込み例：元画像(Bit1～Bit7)＋埋め込み用画像(Bit0)＝埋め込み済み画像
＋ 
＝ 
参考：日本におけるステガノグラフィーの利用について
1990年代の日本においては、特に有償のソフトウェアやPCゲームの違法コピーを配布するために、ステガノグラフィーあるいはその他のデータ隠ぺい方法が広く用いられていました。一例として、RARファイルなど元バイナリファイルを多数のファイルに分割し、あらかじめ用意された大量の画像ファイルに結合することで、画像ファイルとして表示可能だが実は違法コピーの分割バイナリデータが含まれているファイル群を作成し、それをWeb上にアップロードして露見しにくい違法コピー配布を実現していました。アップロード先に使われたのは、無料のWebサイト作成サービスで作成したWebサイト群や、匿名ユーザーで利用可能だった某国立大のFTPサーバーなどでした。当時日本では、上記のようなデータ隠ぺいとデータ抽出・復元を行う、いわゆる「偽装ツール」が多々公開されており、その中には画像ファイルの色情報のビットを書き換える、ステガノグラフィーの技術を採用したものもありました。これらの偽装ツールはそれぞれ独自のデータ隠ぺい方法を採用していたことから、数多くの偽装ツールに対応した、データ抽出・復元機能を持つツール「RarUty」や「Melt it!」が当時人気を博しました。このように、日本におけるデジタルデータの隠ぺい方法は、アンダーグラウンドでの需要と相まって、独自の発展を遂げました。しかし、2000年代に入り「Winny」などP2P方式のファイル共有ソフトの台頭、それからWeb上のアップローダーあるいはダークウェブへ移行という時代の流れの中で、各種違法コピーの配布やその他の不法行為のために、上記偽装ツールが使用されることはなくなりました。現在では、ほとんどの偽装ツールは公式サイトが閉鎖し、入手が困難なものも少なくありません。ただし、ダークウェブなどの匿名性の不完全さや近年の逮捕事例等を勘案すると、現在の日本における、犯罪に関連する各種データの隠ぺいと配布には、ステガノグラフィーの技術を用いる新しいツールが使用されることもあると考えられます。このようなツールのソースコードは、現在ではネット上で容易に入手可能であり、誰でもカスタマイズを加えた新しいデータ隠ぺいツールを製作することができます。なお、現実に犯罪組織や国際テロリストによって隠ぺいされるデータは、上述の違法コピーに限らず、国家や企業の機密情報、悪意のあるプログラムコードやスクリプトなど多種多様なものが該当します。
CTFにおける、「Steganography」や「Misc」分野の問題には、かつての偽装ツールが使用していたデータ隠ぺい方法と同じ方法を用いているものも散見されます。これらのデータ隠ぺい方法は、少しだけ形を変えて現在でも各種犯罪に使用されうるものであり、CTFのステガノグラフィー関連等の問題は、決して単なるパズルではなく、情報セキュリティの世界にリアルな接点を持つものといえます。