search

m13253 / lvdo

Video steganography implementation
GNU General Public License v3.0
98 stars 11 forks source link

Add base carrier data support? #3

Open jabbany opened 10 years ago

jabbany commented 10 years ago

隐写一般要有载体数据，一个看起来比较正当的含有杂质的数据流。现在LVDO仅仅是把文件DCT重排到了视频里面，下一步是不是要加入数据载体。

比如提供一个视频，然后把数据载在看似正当的视频上。

m13253 commented 10 years ago

如果是那样的话，数据量非常大。 建议看看 Video Steganography with Perturbed Motion Estimation.pdf，一帧只能存几个字节。

现在的lvdo实现在100%还原的情况下数据量会增加3倍，已经不让我满意了。

我的目的不是让别人看不出来我在存东西，而是让视频过审核。

先close了。如果有异议你可以再open。

jabbany commented 10 years ago

我觉得这样不好，没有隐写就没有意义了，完全可以生成一个基础key图片，然后把每一帧的颜色（HSV或者RGB）对Key的每一个像素做XOR，也能产生出抗压的乱码图片（压缩只干扰色彩还原）。视频审查完全可以见到这种类似乱码的视频立刻删掉。现在做DCT不是真正的加密，而是一种混乱化编码 （Obfuscation）。

不过要是能载到一个已有的视频上，让视频本身看起来好像没压缩好，那么被删可能性会大大降低。我认为既然说要做Steganography就好好做咯。。。Obfuscation真的不难。把视频切成小方框重新排列都可以让人看不出原来的内容╮(╯_╰)╭还是线性映射抗干扰很高。。。

有关数据量我觉得首先声音和视频并用，加上error checking和LSB校验应该很好，用DCT载主要的视频图像块（类似JPEG压缩可以不断清晰化的解码），然后通过LSB增加画面细节。二压的话LSB就没了，但是还能保证粗略低分辨率视频。

m13253 commented 10 years ago

我想到一个兼容现有实现的方法。

LVDO 有两个参数：--qmin 和 --qmax。可以调整好这两个参数让 LVDO 只使用 DCT 中高频部分。低频部分使用别的画面。而解码器仍然可以直接解码。但是不太好绕过 me，只能自己指定 merange=0。这样的效果大概就和低质量 JPEG 差不多。

事实上音频的话，你不了解编码器对相位的处理。听说 MP3 也是使用 DCT的，AAC 和 OGG/Vorbis 是使用我不熟悉的小波变换。可以保证频率和振幅，不能保证相位。这样一样只能使用 FM 和 AM，不能使用 QAM，效率很低。所以在有限的码率下只用视频就够了。音频随便填点东西。

还有你把问题想得太简单了。LSB 会挂得很惨，尤其是走 H.264 一趟。重新排列会死在 me。

LVDO 还没有在 H.265 上测试，其中一个原因是我不熟悉的小波变换。战 YouTube 要考虑 VP9，VP9 是用 DCT + DST 的听说，会陨 LVDO 的相位。

m13253 commented 10 years ago

你给我的音频加密的三种方式。

首先，LSB 编码相当于加上一个振幅为 1/65536，频率为 22050Hz 或其约数的高频正弦波。如此高的频率在压缩的时候丝毫不剩。

相位编码我上一帖已说了。你我都不了解编码器对相位的处理。

回音编码，在 OGG/Vorbis 上会挂得很惨，因为 Vorbis 的 pre-echo 效应。YouTube 的音频有 AAC-LC、OGG/Vorbis、OGG、OPUS 的。只要会挂就不是好方案。

m13253 commented 10 years ago

而且，LVDO 有一个黑白模式，就是只使用 Y 通道，UV 全部填 0x80。当然可以有一个只使用 UV 的模式。这样 Y 通道填别的视频。

这是第一点。第二点是 LVDO 可以不使用低频部分（--qmin），把低频让给别的视频用。由其是 DCT 的 0 号系数，是 8x8 格的亮度、色度平均值。即使是只使用这个系数，就可以让只看缩略图的审查者看不出破绽了。

但是，LVDO 的目的不是仅仅混淆视频，而是混淆任意数据。当然，媒体文件为主。正因为这样，吞吐量要非常大才可以。我目前的测试是，一个 480p 的视频至少要 720p 1Mbps 同等时长，才可以正确编码。大概编码后的文件大小是原来的 3～8 倍。所以和一般的隐写不同，LVDO 更追求吞吐量，所以不太有空间用来放一个明文的画面了。

总之，LVDO 也只是提供一个机制，而不是实现。LVDO 很多地方都没有优化，但是在目前的情况下来看，速度也够了。如果你有兴趣可以自己制作兼容或不兼容的、更快或更好的实现。

jabbany commented 10 years ago

现在主要问题是没有底层的衬托视频就没意义了。反正都是产生乱码，把数据扔到MSB都可以。 DCT的意义不就是载到已有信号上，把隐藏的数据扔到噪音里同时让噪音可压缩。

m13253 commented 10 years ago

所以，用-qmin限制中高频就好了。 而且扔到MSB是没有那么高的吞吐量的。

jabbany commented 10 years ago

填入别的视频要是也能通过一个stream流进去就可以了。。。我对C苦手没办法。希望LVDO能支持读取一个named pipe读入raw视频和文件一起压。

我是改不出的，但是那样作用会大很多。

jabbany commented 10 years ago

我以前有一个叫HMShuffle的程序会把视频的每一帧切成20x20的方块，根据一个key重新排列，然后产生输出。也能耐压缩无非是压缩后还原就在格子边框有损伤。但是一直不能解的就是载到载体视频上。

我觉得LVDO的专注目标应该是利用DCT载到任意一个载体视频上，那样功用就比传统obfuscation大很多了。

m13253 commented 10 years ago

我的意思是，让 LVDO 的这个实现变成一个 Reference Implementation 好了，保证 100% 正确，别的实现可以有优化，比如针对优酷和 YouTube 以及渣浪（是唯一可以自己压制的）的不同优化。

我在 #4 里提到说要在 LVDO Transport Layer 上建一个 Transmission Control Layer。

我是想再建立一个实现。把这些功能在那里完成。

m13253 commented 10 years ago

我以前有一个叫HMShuffle的程序会把视频的每一帧切成20x20的方块，根据一个key重新排列，然后产生输出。也能耐压缩无非是压缩后还原就在格子边框有损伤。但是一直不能解的就是载到载体视频上。

格子边框损伤的原因是你切的是 20x20 而不是 16x16……哈哈哈哈哈

jabbany commented 10 years ago

我是想再建立一个实现。把这些功能在那里完成。

也好。不过总觉得双输入的合并应该LVDO归这部分，协议主要保证数据损失恢复就好了。

格子边框损伤的原因是你切的是 20x20 而不是 16x16……哈哈哈哈哈

我写那个的时候差不多是写hmode那个文章之后不久。。。比较naive啦。。。不过好处是canvas也能很好的支持。。。就是不容易过审核。。。

m13253 commented 10 years ago

协议还要管优酷水印的问题啊。说白了就是绕过水印的区域。

总之在短期内打算对现有的 LVDO 找 bug。保证 bitstream freeze 之后才开新的实现。 BBC 的 Dirac 编码器的 libschrodinger 也是在 libdirac 写好之后才开始的啦。

m13253 commented 10 years ago

因为我和你那个 H-Mode 以及 HMShuffle 的出发点不同。你是加密模拟数据，我是加密数字数据。数字数据很容易受悬崖效应的影响。所以对于流量的控制要更复杂。但是更灵活，也很不错了。

话说你 C 语言苦手，那么你擅长什么语言呢？下一个实现要么换语言？（但是 FFT 库就没有现成的咯）

jabbany commented 10 years ago

嘛我觉得现在这个实现也挺好。。。别的语言没有这么高的效率估计做不了流处理器。 上层协议的话用Python估计比C好对付。Python有对fftw3的接口。

m13253 commented 10 years ago

我想到一个问题，如果 carrier data 用动态画面的话，可能会触发 x264 的 motion estimation。如果是自己压制还好，上传优酷的话就不好说了。

我的想法是用静态的，比如10秒一换的图片，配上音乐，设置合适的 --qmin 和 --qmax。让视频看起来是配乐图片幻灯一样。当然不能这么死板，在这么个架构的基础上可以发挥很大的想象空间。

jabbany commented 10 years ago

有道理，换图的时候会不会触发运动检测？其实我都不知道那些网站是怎么处理的，不过据说有招数避免被二压？好像如果你视频本身就符合某个拟定帧率什么的。。。（不清楚

说不定可以用后黑技术之类的。。。

m13253 commented 10 years ago

有道理，换图的时候会不会触发运动检测？其实我都不知道那些网站是怎么处理的，不过据说有招数避免被二压？好像如果你视频本身就符合某个拟定帧率什么的。。。（不清楚

说不定可以用后黑技术之类的。。。

我前几天查了相关资料。YouTube 一定 会二压，无法避免。优酷会加水印，怎么可能不二压？ 而且视频网站的压制参数都很低。YouTube是 High@L2.2 虽然码率很高（高你妹，卡爆了）但是效率很低。这对lvdo要求就更高了。

m13253 commented 10 years ago

换图的时候会不会触发运动检测

其实是只有换图的时候才没有运动检测。你对 H.264 了解太少。

而且 H.264 是基于频域的，所以什么 LSB MSB 这样基于时域的是会失败的。

m13253 commented 8 years ago

你还在关注这个项目吗？最近这几天似乎很多外国人开始关注这个项目。

我是没有时间继续开发了。但是如果你想实现数据载体，给你一个提示（不需要使用 DCT 变换的，但是能达到比较“能用”的结果）：

  1. 载体视频每 8x8 像素，取平均值（相当于只保留 DCT 结果数组的 [0, 0] 位）
  2. LVDO 的 --qmin 参数使用比 0 大的值
  3. 把 LVDO 的输出和取平均值之后的视频相加起来
  4. 尽量让帧率低，比如图片幻灯片，而不是动图

更好的方法是第一步用真正的 DCT 来替代取平均，这样你可以利用 [0, 0] 之外的数据。