这是一个专门讨论 idea 的地方。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
这是一个创建于 2395 天前的主题，其中的信息可能已经有所发展或是发生改变。
思路:
就我所知，所有文件格式都有着特定结构的数据，这样就有了某种特征，那是否能够提取其特征，再通过 AI 来识别特征，以此来识别文件格式?
详细过程:
例如有一个未知格式的文件，
我们以二进制来读取这个文件， 每隔 X 位换行，不足一行填 0， 这样就能组成一个 X 为宽的 01 阵列。
将 0 转成白色矩形，1 为黑色矩形，我们就能得到一个充满小的黑色正方形的图像，而这份图像就存在某种特征。
我们以各种文件格式的文件生成的图像训练 AI，并提取识别其图像特征
再与未知格式的文件对比，发现符合纯文本文件的图像特征
于是我们可以用 atom 打开它,atom 识别其为 python 源代码文件
天啦噜，原来是 py 文件啊!!!!
第 1 条附言 · 2018-04-26 02:41:37 +08:00
我当然知道世面上的各种文件格式方式，
但是我这个方法的确能解决某种需求，
比如其他方法可能每种格式都需手动写代码或配置，而我的方法只需丢训练素材给 AI 就行了。
但是我这个方法的确能解决某种需求，
比如其他方法可能每种格式都需手动写代码或配置，而我的方法只需丢训练素材给 AI 就行了。
第 2 条附言 · 2018-04-26 03:05:56 +08:00
想了想，2 进制读取数据信息密度太低，高进制其实更好，比如 16 进制读取，转换成 16 色图片。具体多少进制合适，还得写测试代码才知道。
第 3 条附言 · 2018-04-26 03:45:15 +08:00
我想得太简单了，其实往深了想，只要有足够的训练数据，甚至可以识别出是某人的代码风格
第 4 条附言 · 2018-04-26 04:17:49 +08:00
其实 8 年前别人就有类似这种想法了，只是当时似乎没 AI
http://nullprogram.com/blog/2010/05/20/
二进制文件转图片
https://github.com/skeeto/binitools
http://nullprogram.com/blog/2010/05/20/
二进制文件转图片
https://github.com/skeeto/binitools
 |
1
kamen OP 思路不收费，但用于商业的时候请记得给我一个激活码
|
 |
2
feather12315 2018-04-26 02:12:36 +08:00 via Android
不都是直接看 magic number ？
|
 |
3
quake0day 2018-04-26 02:27:10 +08:00
当然可以，但是为啥一定要转换成为图像来识别呢？
|
 |
4
Pyjamas 2018-04-26 02:27:23 +08:00
|
|
5
kamen OP @feather12315 虽然我不懂什么魔法数字，但是你这种方法肯定要自己提取魔法数字吧，不知道你的速度有没有 AI 识别图像的速度快?
|
 |
6
tyfulcrum 2018-04-26 02:31:57 +08:00 via iPhone
|
|
7
tyfulcrum 2018-04-26 02:32:44 +08:00 via iPhone
|
|
8
kamen OP @quake0day 避免一个可能现有格式识别的局限，不能识别出新现世的文件格式，需要重新写代码，而这个只需增加训练数据罢了
|
|
9
kamen OP |
 |
10
xupefei 2018-04-26 02:37:48 +08:00
照这个思路下来，说不定训练出的 AI 决定只用了这张图的前 32 个点，因为那里是 Magic ……
|
 |
11
GooMS 2018-04-26 02:38:03 +08:00 via Android
那么有什么场合是需要绝对文件类型正确？
|
|
12
Pyjamas 2018-04-26 02:40:04 +08:00
> 所有文件格式都有着特定结构的数据，这样就有了某种特征
这个所谓的某种特征就藏在那几个字节里，至于文件后面的内容，我觉得都可以看作是随机字符串了，所以对着那几个字节有什么好上 AI 的 |
|
15
kamen OP @xupefei emmm，我可不敢肯定所有文件特征都在开头，比如我设计的一种莫须有的私有格式文件，它的特征到处都有
|
|
16
kamen OP |
|
19
xupefei 2018-04-26 02:55:20 +08:00
@xupefei #18 你可以给一个函数考虑文件中间的特征，但这个函数很可能会对其他文件判断的正确性造成影响。
说白了就是，大家都把特征放在头部，你不放，那是你设计有问题。 |
|
20
kamen OP @xupefei 你可能弄错了一件事，我都被你绕进去了，格式描述能成为特征，但数据就不能成为特征了吗？太绝对了吧。
|
|
21
kamen OP @kamen 比如一种格式，开头是格式描述，后面的数据全是 unicode 码，而 unicode 码是有范围的，而这就是特征
说到这里，我觉得，2 进制其实不太好，可以尝试更高进制，比如 16 进制读取，转成 16 色图片，或许信息密度更大 |
|
22
xupefei 2018-04-26 03:07:34 +08:00  1
@kamen #20 数据能成为特征，例如 xml、txt 和 wav。
然而，现在绝大部分文件都不是直接存的，而是有一个压缩过程。压缩后的字节你说能有什么特征？ 某些分段压缩的文件中间会出现特征。例如，PNG 文件内会出现“ fcTL ”、“ fdAT ”之类的明文，但是人家头部已经有 magic 了，要中间的特征何用？ 我的思路如下： 1 ） Q：这是个问题吗？ A：不是，因为 magic 判断没有什么明显缺点。 2 ） Q：如何解决这个问题？ A：既然不是问题，那么不需要解决。 至于你说“自定义文件格式”，那只能说，首先你就不应该这样设计。 |
 |
23
Kagari 2018-04-26 03:10:49 +08:00 via Android
可惜我要睡了，不然看完#5 #21 我能笑一天
|
 |
24
qq316107934 2018-04-26 03:11:05 +08:00
完整的看了下，楼主完全不懂机器学习一直在 YY，想在此打住楼主比较民科的思想：
1.首先，做图像识别也是要把图像转换为矩阵作为输入数据，你说的把二进制位转换为图像这一步骤多此一举 2.大多数文件用 Magic number 作头部来标识文件类型不是没有道理的，一方面只需要读取文件开头的几个字节，效率很高，另一方面不同格式严格区分头部，这样有助于格式的识别。 3.如果按照楼主的思想，会出现以下问题：①有些类型的文件（如 ZIP，PNG ），在做压缩之后数据块完全没有规律可循，且模型冗余成分会很大，大部分节点不会活跃②文件内容相似的文件（例如 EXE 和 DLL ）不能被很好的区分③效率极低，对大文件格式的识别要扫描整个文件。④存在一个误报率的问题，识别率肯定不会是 100% 综上所述，希望楼主能从现实出发思考，不要继续 YY 了 |
|
25
qq316107934 2018-04-26 03:12:10 +08:00
刚打完字，感觉又有很多槽点，不知从何吐起了...
不过话说...有没有可能楼主就是来钓鱼的，我是不是做了把老实人... |
|
26
xupefei 2018-04-26 03:15:48 +08:00
另外，我觉得可以提一下 magic 识别有多简单，肯定比跑 AI 快：
var magic=文件前四字节 if magic=="GIF8" return "GIF" else if magic=="\x89PNG" return "PNG" else if magic=="PK\x03" return "ZIP" 下次添加新类型，只需要写两行代码。 |
 |
27
Xs0ul 2018-04-26 03:17:52 +08:00
在文件格式这种有规范的情况下，rule-based 的模型（比如根据开头的 magic number ）几乎铁定比 machine learning 的好得多。因为只要遵循同一个规则，肯定就是对的。machine learning 的方法只能拟合这些规则，而后面数据的特征，八成是噪声，给模型增加难度。
你真要做，不如只做文本文件，比如我手滑把 python 文件后缀名写了个.yp ，你弄个模型来判断这未知后缀名的文件，到底是 python 的还是 c 的代码，这还有点意思。 |
|
28
qq316107934 2018-04-26 03:20:02 +08:00
@Xs0ul #27 这个...感觉也是 rule-based ,按照不同语言的语法树解析一下，报错最少的那个，就是咯
|
|
29
Xs0ul 2018-04-26 03:27:03 +08:00
@qq316107934 #28 理论上可以用上语言风格的特征？比如变量命名的格式之类的。因为比较短的代码说不定能通过好几种语言的解析。当然实用性和准确性另说
|
|
30
Xs0ul 2018-04-26 03:27:56 +08:00
@qq316107934 #28 不过我很赞同对转换成图像的吐槽（
|
 |
31
msg7086 2018-04-26 03:28:41 +08:00
你这个太慢了。我来提供一种思路。
首先，我们可以用 honeyview 打开它，看看是不是图片。 噫，不是。下一个。 然后，我们可以用 atom 打开它，atom 识别其为 python 源代码文件。 天啦噜，原来是 py 文件啊。 这个还是太慢了。我再来提供一种思路。 首先，我们可以用一个文件格式识别工具扫描它，文件格式识别工具识别其为 python 源代码文件。 天啦噜，原来是 py 文件啊。 |
|
32
kamen OP @Xs0ul 拜托，这是一个人脑思路，所以有这一步，我知道你们厉害，可以脑内跑代码，我们这些智商低的只有人脑
|
|
33
xupefei 2018-04-26 03:34:26 +08:00 1
@msg7086 #31 你这还是有点儿慢。终极方案还是得靠记事本：
运行记事本，把文件拖进去，观察前几个字，天啦噜是 XXX。 另外，我现在就是这么干的，因为常见的 magic 都挺好记的。 题外话，把 exe/dll 拖到记事本里有时会有有趣的发现，比如作者的变量命名喜好、有趣的字符串、残留的 gdb 符号路径暴漏了开发者的名字之类的…… |
|
34
kamen OP 我也这么干过，不过是 16 进制编辑器，有时会发现一些蜜汁字符串
|
 |
36
lsvih 2018-04-26 14:41:50 +08:00 1
@kamen 刚好在调研这块，这篇： https://arxiv.org/pdf/1002.3174.pdf 有相关实现，不过用的是 PCA 和 NN。根据 binary 转成图像再识别产生的像素太多，且由于特征信息大概率已经是像素级别，不能通过重采样去减小图像尺寸。对这么大像素的全精度图像进行学习需要大量时间和资源消耗。
|
Select Language