使用 AI 来识别文件格式

[kamen]

思路:

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

详细过程:

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

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

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

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

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

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

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

我当然知道世面上的各种文件格式方式，
但是我这个方法的确能解决某种需求，

比如其他方法可能每种格式都需手动写代码或配置，而我的方法只需丢训练素材给 AI 就行了。

想了想，2 进制读取数据信息密度太低，高进制其实更好，比如 16 进制读取，转换成 16 色图片。具体多少进制合适，还得写测试代码才知道。

我想得太简单了，其实往深了想，只要有足够的训练数据，甚至可以识别出是某人的代码风格

其实 8 年前别人就有类似这种想法了，只是当时似乎没 AI
http://nullprogram.com/blog/2010/05/20/
二进制文件转图片
https://github.com/skeeto/binitools

[kamen]

思路不收费，但用于商业的时候请记得给我一个激活码

[feather12315]

不都是直接看 magic number ？

[quake0day]

当然可以，但是为啥一定要转换成为图像来识别呢？

[Pyjamas]

https://en.wikipedia.org/wiki/List_of_file_signatures

[kamen]

@feather12315 虽然我不懂什么魔法数字，但是你这种方法肯定要自己提取魔法数字吧，不知道你的速度有没有 AI 识别图像的速度快?

[tyfulcrum]

@kamen https://en.wikipedia.org/wiki/List_of_file_signatures

[tyfulcrum]

@kamen https://en.m.wikipedia.org/wiki/File_format#Magic_number

[kamen]

@quake0day 避免一个可能现有格式识别的局限，不能识别出新现世的文件格式，需要重新写代码，而这个只需增加训练数据罢了

[kamen]

@tyfulcrum 那如果指纹很难识别呢？
我这个想法肯定不能完全代替同类程序，但肯定解决了某些需求
比如私有文件格式识别

[xupefei]

照这个思路下来，说不定训练出的 AI 决定只用了这张图的前 32 个点，因为那里是 Magic ……

[GooMS]

那么有什么场合是需要绝对文件类型正确？

[Pyjamas]

> 所有文件格式都有着特定结构的数据，这样就有了某种特征

这个所谓的某种特征就藏在那几个字节里，至于文件后面的内容，我觉得都可以看作是随机字符串了，所以对着那几个字节有什么好上 AI 的

[kamen]

@Pyjamas 听说文件开头有特征? 纯文本了解一下

[Pyjamas]

@kamen 那就等于丢了一大堆随机字符串给 AI

[kamen]

@xupefei emmm，我可不敢肯定所有文件特征都在开头，比如我设计的一种莫须有的私有格式文件，它的特征到处都有

[kamen]

@Pyjamas https://zh.m.wikipedia.org/zh-hans/Unicode

[kamen]

@GooMS 我要知道了，直接靠这个小赚一笔了

[xupefei]

@kamen 世界上成千上万种格式特征都在头部，你一种格式大概会被当作噪音忽略。

[xupefei]

@xupefei #18 你可以给一个函数考虑文件中间的特征，但这个函数很可能会对其他文件判断的正确性造成影响。
说白了就是，大家都把特征放在头部，你不放，那是你设计有问题。

[kamen]

@xupefei 你可能弄错了一件事，我都被你绕进去了，格式描述能成为特征，但数据就不能成为特征了吗？太绝对了吧。

[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 的二进制文件。看来是不用了