12ブロックの分割IDAT構造(最後のLSBがわずかに小さい)( .PNG )のステガノグラフィ画像に出くわしました。いくつかのことを明確にする必要があるため、質問の真の要点に到達する前に、問題の構造について少し詳しく説明します。そうではないので、トピック外としてマークしないでください。問題自体に到達できるように、スクリプトの背後にある概念を説明する必要があります。それ自体にデータが埋め込まれていることは間違いありません。強化されたLSBを改変することでデータが隠蔽されたようです最後の最下位ビットを除く各ピクセルの上位ビットを除外する値。したがって、256 の値の範囲の 0 または 1 は目に見える色を与えないため、すべてのバイトは 0 または 1 になります。基本的に、0 は 0 のままで、1 は最大値、つまり 255 になります。私はこの画像をさまざまな方法で分析してきましたが、3 つの色のいずれかで 1 つの値が完全に欠落していること以外に奇妙な点は見当たりません。値 (RGB) と、色値の 1/3 での別の値の存在感の高まり。しかし、これらを調べてバイトを置き換えても何も得られず、この道を追求する価値があるかどうかさえ迷っています.
したがって、プロセスを逆にして拡張された LSB を「復元」するスクリプトをPython、PHP、またはC/C++で開発することを検討しています。
私はそれを24 ビットの .BMPに変換し、カイ 2 乗ステガナリシスから赤い曲線を追跡しました。ファイル内にステガノグラフィされたデータがあることは確かです。
まず、8 つを少し超える垂直ゾーンがあります。これは、8kB を少し超える隠しデータがあることを意味します。1 ピクセルを使用して 3 ビット (各 RGB カラー トーンの LSB に 1 つ) を隠すことができます。したがって、(98x225)x3 ビットを非表示にできます。キロバイト数を取得するには、8 と 1024 で割ります: ((98x225)x3)/(8x1024)。まあ、それは約8.1キロバイトになるはずです。しかし、ここではそうではありません。
ファイルの.JPG拡張子のAPPOおよびAPP1マーカーの分析も、いくつかのぎこちない出力を示します。
Start Offset: 0x00000000
*** Marker: SOI (xFFD8) ***
OFFSET: 0x00000000
*** Marker: APP0 (xFFE0) ***
OFFSET: 0x00000002
length = 16
identifier = [JFIF]
version = [1.1]
density = 96 x 96 DPI (dots per inch)
thumbnail = 0 x 0
*** Marker: APP1 (xFFE1) ***
OFFSET: 0x00000014
length = 58
Identifier = [Exif]
Identifier TIFF = x[4D 4D 00 2A 00 00 00 08 ]
Endian = Motorola (big)
TAG Mark x002A = x[002A]
EXIF IFD0 @ Absolute x[00000026]
Dir Length = x[0003]
[IFD0.x5110 ] =
[IFD0.x5111 ] = 0
[IFD0.x5112 ] = 0
Offset to Next IFD = [00000000]
*** Marker: DQT (xFFDB) ***
Define a Quantization Table.
OFFSET: 0x00000050
Table length = 67
----
Precision=8 bits
Destination ID=0 (Luminance)
DQT, Row #0: 2 1 1 2 3 5 6 7
DQT, Row #1: 1 1 2 2 3 7 7 7
DQT, Row #2: 2 2 2 3 5 7 8 7
DQT, Row #3: 2 2 3 3 6 10 10 7
DQT, Row #4: 2 3 4 7 8 13 12 9
DQT, Row #5: 3 4 7 8 10 12 14 11
DQT, Row #6: 6 8 9 10 12 15 14 12
DQT, Row #7: 9 11 11 12 13 12 12 12
Approx quality factor = 94.02 (scaling=11.97 variance=1.37)
暗号化アルゴリズムが適用されていないため、隠蔽に続くキーの実装はないとほぼ確信しています。私の考えは、LSB 値をシフトして元の値を返すスクリプトをコーディングするというものです。いくつかの構造解析、統計的攻撃、BPCS、
画像のヒストグラムは、異常なスパイクのある特定の色を示しています。非表示のデータを表示できるように最善を尽くしましたが、役に立ちませんでした。これらは、次のように RGB 値のヒストグラムです。
次に、複数のIDATチャンクがあります。しかし、私は各ピクセル位置でランダムな色の値を定義することで同様の画像をまとめました。これまでのところ、それらの内部もほとんど発見されていません。さらに興味深いのは、画像内でカラー値が繰り返される方法です。再利用される色の頻度が何らかの手がかりになるようです。しかし、私はまだその関係を完全には理解していません。さらに、アルファ チャネルで 255 の完全な値を持たないピクセルの列と行は 1 つだけです。X、Y、A、R、G、およびBも解釈しました画像内のすべてのピクセルの値を ASCII として表示しますが、読みやすいものは何もありません。LSB の平均の緑の曲線でさえ、何もわかりません。明らかな切れ目はありません。RGB からの青の値の奇妙な曲線を示す他のいくつかのヒストグラムを次に示します。
しかし、カイ二乗分析の出力である赤い曲線は、いくつかの違いを示しています。私たちには見えないものを見ることができます。統計的検出は私たちの目よりも敏感であり、それが私の最終的なポイントだったと思います. ただし、赤い曲線には一種の遅延もあります。非表示のデータがなくても、最大で開始し、しばらくの間そのままです。偽陽性に近いです。画像の LSB のように見え、ランダムに非常に近く、実際にはランダムではないと判断できるしきい値に達する前に、アルゴリズムは大きな母集団を必要とします (分析はピクセルの母集団の増加に対して行われることを思い出してください)。結局、赤い曲線が下がり始めます。非表示のデータでも同じような遅延が発生します。1 kb または 2 kb を非表示にしますが、この量のデータの直後に赤い曲線が下がらない. ここでは、それぞれ約 1.3 kb と 2.6 kb で少し待ちます。以下は、16 進エディターからのデータ型の表現です。
byte = 166
signed byte = -90
word = 40,358
signed word = -25,178
double word = 3,444,481,446
signed double word = -850,485,850
quad = 3,226,549,723,063,033,254
signed quad = 3,226,549,723,063,033,254
float = -216652384.
double = 5.51490063721e-093
word motorola = 42,653
double word motorola = 2,795,327,181
quad motorola = 12,005,838,827,773,085,484
青 (RGB) 値の動作を確認するための別のスペクトルを次に示します。
状況と私が追求しているプログラミングの問題を明確にするために、これらすべてを実行する必要があることに注意してください。これ自体が私の質問を話題から外さないものにするので、そのようにマークされなければうれしいです。ありがとうございました。