CTFステガノグラフィの課題を克服しようとしています。運が悪ければファイル内の隠しデータを再表示するために、さまざまな方法を試しました。画像にJPEGsnoopを使用し、次の出力を取得しました。
*** Decoding SCAN Data ***
OFFSET: 0x0000026F
Scan Decode Mode: Full IDCT (AC + DC)
Scan Data encountered marker 0xFFD9 @ 0x0001DF10.0
*** NOTE: YCC Clipped. MCU=( 15, 10) YCC=( 256, 132, 130) Y Overflow @ Offset 0x0001DF0F.3
*** NOTE: YCC Clipped. MCU=( 15, 10) YCC=( 256, 123, 121) Y Overflow @ Offset 0x0001DF0F.3
*** NOTE: YCC Clipped. MCU=( 16, 10) YCC=( 256, 131, 126) Y Overflow @ Offset 0x0001DF0F.3
*** NOTE: YCC Clipped. MCU=( 16, 10) YCC=( 258, 127, 127) Y Overflow @ Offset 0x0001DF0F.3
*** NOTE: YCC Clipped. MCU=( 16, 10) YCC=( 256, 126, 126) Y Overflow @ Offset 0x0001DF0F.3
*** NOTE: YCC Clipped. MCU=( 16, 10) YCC=( 256, 129, 122) Y Overflow @ Offset 0x0001DF0F.3
*** NOTE: YCC Clipped. MCU=( 16, 10) YCC=( 258, 129, 124) Y Overflow @ Offset 0x0001DF0F.3
*** NOTE: YCC Clipped. MCU=( 16, 10) YCC=( 258, 126, 129) Y Overflow @ Offset 0x0001DF0F.3
*** NOTE: YCC Clipped. MCU=( 17, 10) YCC=( 256, 120, 137) Y Overflow @ Offset 0x0001DF0F.3
*** NOTE: YCC Clipped. MCU=( 17, 10) YCC=( 258, 124, 126) Y Overflow @ Offset 0x0001DF0F.3
Only reported first 10 instances of this message...
Compression stats:
Compression Ratio: 31.12:1
Bits per pixel: 0.77:1
これらのメモは非表示のデータセグメントを示すことができますか?
画像は適切に形成されています。ダブルFFD9はありません。ファイルはFFD9で終わり、データの終わりとFFD9の間にギャップはありません。私はpythonを使用して「オーバーシュート」ルーマ(Y)値を見つけようとしました:
#!/usr/bin/python
from PIL import Image
def main():
im = Image.open("l0v3m3.jpg")
im = im.convert("YCbCr")
y, cb, cr = im.split()
seq = y.getdata()
for x in seq:
if x > 255:
print x
if __name__ == '__main__':
main()
しかし、どうやら、Y値は切り取られます。誰かがクリッピングなしでY値を取得する方法を知っているなら、私は非常に感謝します。 btw: ここにファイルがあります
非表示のデータセグメントを見ているとは思わない。 FFD9はEOIマーカーであり、それに続くデータは無視する必要があるので、JPEGSnoopが実際にデコードしようとは思わないでしょう。 doesであるという事実は、エラーがEOIに関連していないことを示しているようです。
不正なYCC値は、範囲外の値が実際に情報のコーディングに使用されていることを示している可能性があります。いくつかの可能なスキームが可能です。たとえば、違反が発生しないか、シングレットまたはペアで違反が発生するダブルビットスキームを検討しているとします。
OK OK = it was not possible to code a bit in this pixel
FAIL OK = this pixel codes a zero (or a one)
FAIL FAIL= this pixel codes a one (or a zero)
ほとんどのJPEGデコーダは静かに値を範囲外にクリップするため、この種のエンコーディングはすぐには表示されず、画像サイズに大きな影響を与えません(つまり、画像に高周波ノイズが重畳されません)。
JPEGで可能な別のスキームは、ITU-R BT.601エンコーディングを乱用することです。これは、16から235までの正当なYCC値を持っています(ただし、バイトには0〜255の値を格納できます)。非常に黒い(16)または非常に白い(235)のピクセルを見つけた場合は常に、最下位ニブルに4つの追加ビットを埋め込むのに適しています。出力は16ではなく12になり、ITUデコーダーはそれを「黒」に変換しますが、ステガノグラフィーデコーダーは「1100b」を読み取ります。
また、YCCが非正規の場合、CbおよびCrコンポーネントの値は重要ではないはずです(私はそう思います)。黒には色相がないため、指定した色相は常に黒にデコードされます。つまり、これらの値を使用して追加情報を保存できます。
一方、上記のすべてはwrongであり、これらのデータは実際にはイメージの終わりマーカーの後にある可能性があります。それが何であるか、私は言うことができませんでした。試してみて、16進エディタで表示して、それが理にかなっているかどうかを確認できます。それはcouldたとえば、ASCIIシーケンスであり、YCCクリッピングエラーをスローする理由は、結局のところ「SQUEAMISH OSSIFRAGE」は実際には有効なDCT分解ではないためです。したがって、ゼロ(または1)に消え、YCCに変換されると、当然範囲外になります。
さて、ファイルはFFD9(EOI)で終わっているので、two EOIがない場合:
....legitimate image.... FFD9 EXTRA DATA ...FFD9
次に、JPEGSnoopによって報告されるYCCの「エラー」は、「正当な画像」データを参照する必要があります。
これらのバイトは 正しくDCTデコードされた 、butであり、Y値が3成分(Y、Cb、Cr)にデコードされます。範囲外のため、クリップされます。 JPEGsnoopデバッグで、256と258の値があることがわかります。これらは(明らかに)8ビットではありません。
これを使用してデノーマルをマッピングすることにより情報を運ぶことができます YCbCr 値を単一ビットに:
JPEG Stego
255 ... white 00
256 ... white 01
257 ... white 10
258 ... white 11
このようにして、完全な輝度を持つすべてのピクセルが2ビットの非表示情報をエンコードする可能性があります(または、偶然に整数アルゴリズムが257を出力しない場合は、0のみを256、1を258としてエンコードする可能性があります)。
それをデコードするには、それらのサンプルをすべて回復し(値がクリップされない JPEGデコーダーが必要 )、「余分な」ビットをダンプする必要があります。次に、それらのビットmeanを把握します。