使用 AI 来识别文件格式

[kamen]

思路:

就我所知，所有文件格式都有着特定结构的数据，这样就有了某种特征，那是否能够提取其特征，再通过 AI 来识别特征，以此来识别文件格式?

详细过程:

例如有一个未知格式的文件，

我们以二进制来读取这个文件， 每隔 X 位换行，不足一行填 0， 这样就能组成一个 X 为宽的 01 阵列。

将 0 转成白色矩形，1 为黑色矩形，我们就能得到一个充满小的黑色正方形的图像，而这份图像就存在某种特征。

我们以各种文件格式的文件生成的图像训练 AI，并提取识别其图像特征

再与未知格式的文件对比，发现符合纯文本文件的图像特征

于是我们可以用 atom 打开它,atom 识别其为 python 源代码文件

天啦噜，原来是 py 文件啊!!!!

[kamen]

@kamen 比如一种格式，开头是格式描述，后面的数据全是 unicode 码，而 unicode 码是有范围的，而这就是特征
说到这里，我觉得，2 进制其实不太好，可以尝试更高进制，比如 16 进制读取，转成 16 色图片，或许信息密度更大

[xupefei]

@kamen #20 数据能成为特征，例如 xml、txt 和 wav。
然而，现在绝大部分文件都不是直接存的，而是有一个压缩过程。压缩后的字节你说能有什么特征？
某些分段压缩的文件中间会出现特征。例如，PNG 文件内会出现“ fcTL ”、“ fdAT ”之类的明文，但是人家头部已经有 magic 了，要中间的特征何用？

我的思路如下：
1 ） Q：这是个问题吗？ A：不是，因为 magic 判断没有什么明显缺点。
2 ） Q：如何解决这个问题？ A：既然不是问题，那么不需要解决。

至于你说“自定义文件格式”，那只能说，首先你就不应该这样设计。

[Kagari]

可惜我要睡了，不然看完#5 #21 我能笑一天

[qq316107934]

完整的看了下，楼主完全不懂机器学习一直在 YY，想在此打住楼主比较民科的思想：
1.首先，做图像识别也是要把图像转换为矩阵作为输入数据，你说的把二进制位转换为图像这一步骤多此一举
2.大多数文件用 Magic number 作头部来标识文件类型不是没有道理的，一方面只需要读取文件开头的几个字节，效率很高，另一方面不同格式严格区分头部，这样有助于格式的识别。
3.如果按照楼主的思想，会出现以下问题：①有些类型的文件（如 ZIP，PNG ），在做压缩之后数据块完全没有规律可循，且模型冗余成分会很大，大部分节点不会活跃②文件内容相似的文件（例如 EXE 和 DLL ）不能被很好的区分③效率极低，对大文件格式的识别要扫描整个文件。④存在一个误报率的问题，识别率肯定不会是 100%
综上所述，希望楼主能从现实出发思考，不要继续 YY 了

[qq316107934]

刚打完字，感觉又有很多槽点，不知从何吐起了...
不过话说...有没有可能楼主就是来钓鱼的，我是不是做了把老实人...

[xupefei]

另外，我觉得可以提一下 magic 识别有多简单，肯定比跑 AI 快：

var magic=文件前四字节
if magic=="GIF8"
return "GIF"
else if magic=="\x89PNG"
return "PNG"
else if magic=="PK\x03"
return "ZIP"

下次添加新类型，只需要写两行代码。

[Xs0ul]

在文件格式这种有规范的情况下，rule-based 的模型（比如根据开头的 magic number ）几乎铁定比 machine learning 的好得多。因为只要遵循同一个规则，肯定就是对的。machine learning 的方法只能拟合这些规则，而后面数据的特征，八成是噪声，给模型增加难度。

你真要做，不如只做文本文件，比如我手滑把 python 文件后缀名写了个.yp ，你弄个模型来判断这未知后缀名的文件，到底是 python 的还是 c 的代码，这还有点意思。

[qq316107934]

@Xs0ul #27 这个...感觉也是 rule-based ,按照不同语言的语法树解析一下，报错最少的那个，就是咯

[Xs0ul]

@qq316107934 #28 理论上可以用上语言风格的特征？比如变量命名的格式之类的。因为比较短的代码说不定能通过好几种语言的解析。当然实用性和准确性另说

[Xs0ul]

@qq316107934 #28 不过我很赞同对转换成图像的吐槽（

[msg7086]

你这个太慢了。我来提供一种思路。

首先，我们可以用 honeyview 打开它，看看是不是图片。
噫，不是。下一个。
然后，我们可以用 atom 打开它，atom 识别其为 python 源代码文件。
天啦噜，原来是 py 文件啊。


这个还是太慢了。我再来提供一种思路。

首先，我们可以用一个文件格式识别工具扫描它，文件格式识别工具识别其为 python 源代码文件。
天啦噜，原来是 py 文件啊。

[kamen]

@Xs0ul 拜托，这是一个人脑思路，所以有这一步，我知道你们厉害，可以脑内跑代码，我们这些智商低的只有人脑

[xupefei]

@msg7086 #31 你这还是有点儿慢。终极方案还是得靠记事本：
运行记事本，把文件拖进去，观察前几个字，天啦噜是 XXX。

另外，我现在就是这么干的，因为常见的 magic 都挺好记的。
题外话，把 exe/dll 拖到记事本里有时会有有趣的发现，比如作者的变量命名喜好、有趣的字符串、残留的 gdb 符号路径暴漏了开发者的名字之类的……

[kamen]

我也这么干过，不过是 16 进制编辑器，有时会发现一些蜜汁字符串

[kamen]

@xupefei 我也这么干过，不过是 16 进制编辑器，有时会发现一些蜜汁字符串

[lsvih]

@kamen 刚好在调研这块，这篇： https://arxiv.org/pdf/1002.3174.pdf 有相关实现，不过用的是 PCA 和 NN。根据 binary 转成图像再识别产生的像素太多，且由于特征信息大概率已经是像素级别，不能通过重采样去减小图像尺寸。对这么大像素的全精度图像进行学习需要大量时间和资源消耗。

[kamen]

@lsvih 本来想写个低配版，通过现有图像库来个低配版 demo，用于区别 linux 和 win 的二进制文件。看来是不用了