来自 NSA 的逆向工具 GHIDRA 发布了

2019-03-06 15:09:53 +08:00
 codehz

http://ghidra-sre.org/

Java 写成,包含多个架构的核心,支持 Mac/Linux/Windows 主流系统(毕竟 Java 写成)

( PS: 附带伪代码生成)功能上和 IDA 有得一拼(当然,差距还是很大的,比如分析速度太慢,c++逆向支持较少,没有调试功能等),还是免费的。

略微遗憾的是,目前并没有完全开源,github 上的现在还是一个 placeholder

5794 次点击
所在节点    分享发现
23 条回复
cattrace
2019-03-06 16:30:51 +08:00
version tracking 不错
nanaw
2019-03-06 16:38:51 +08:00
着这不开源好像还可以接受?我理解的像密码管理那类只接受开源其他的不会危害使用的到无所谓了
codehz
2019-03-06 18:10:46 +08:00
@nanaw #2 只是暂时没开源啊,之前不就说要开源了么( nsa 自己说的话总得讲信用吧
估计还在审查代码呢(
secondwtq
2019-03-06 22:36:22 +08:00
提醒下,中国和毛子的 IP 被 ban 了 :)
secondwtq
2019-03-06 22:37:37 +08:00
@nanaw NSA 的还是要小心,这个有 Remote Code Execution 的问题哦 https://github.com/NationalSecurityAgency/ghidra/issues/6
codehz
2019-03-06 23:10:55 +08:00
刚简单试用了一下,有几个感受:
1. 相比 IDA,它速度确实慢了很多,一个约 100 兆的文件,ida 用了一个半小时就完成了,它需要约 8 小时
2. 数据库发现比 IDA 大,上面那个项目 IDA 生成了 1.9G 的数据库,它生成了 5.6G
3. UI 性能方面比 IDA 强上不少,IDA 界面容易失去响应,它只是略卡(在分析过程中操作)
4. 逆向结果方面,各有千秋,IDA 生成的反汇编结果比较紧凑(还能怎么比较,这俩东西看着都差不多,一时半会也看不出啥区别),HexRays 插件生成的伪代码相对质量比较高(比如自动识别调用约定,还有就是对一些特殊函数如 terminate 的处理),但是这款工具能整理类(特指成员函数)和结构(特指偏移量这种),还能识别 c++函数参数中的类型信息并以此来搜索 usage
5. 其他的待进一步研究。。。。(时间都花在等它分析上了)😂
winterx
2019-03-06 23:13:02 +08:00
@secondwtq #4 难怪打开 403.....
codehz
2019-03-07 10:03:58 +08:00
补充图片,顺便问一波 java 在 linux 下怎么开启字体抗锯齿,网上流传的 OPTIONS 大法似乎并没有奏效

iwtbauh
2019-03-07 10:45:12 +08:00
@codehz #8

应该是 0 配置的,不需要用户手动干预

遵守桌面规范的应用程序会检索 XSETTINGS 获取字体渲染配置,如果失败会回退到 Xresouse,最后回退到 fontconfig 等配置。

如果你正在使用桌面环境,桌面环境会为你设置 XSETTINGS 配置 Xft/DPI、Xft/Hinting、Xft/HintStyle、Xft/Antialias 等参数。

如果你使用的应用程序无法正常工作,请向你的上游请求支持桌面规范。
codehz
2019-03-07 10:50:19 +08:00
@iwtbauh #9 ummmm 我用 i3wm,应该是得手动配(字体是都能渲染,就是全部没有抗锯齿,看起来可能和 java 11 有关系。。。
iwtbauh
2019-03-07 11:04:23 +08:00
@codehz #10

非桌面环境用户的话,运行 xrdb -query -a | grep Xft 返回什么。

如果没有输出,尝试配置 ~/.Xresources

```
Xft.antialias: 1
Xft.hinting: 0
Xft.hintstyle: hintnone
Xft.rgba: rgb
```

如果仍然不行,就只能考虑配置 fontconfig 了。
iwtbauh
2019-03-07 11:06:22 +08:00
@iwtbauh #11 修改后应运行 xrdb -merge ~/.Xresources 或者重启 X
codehz
2019-03-07 11:12:08 +08:00
java 并没有读取 Xresources 文件。。。而且 java 的字体渲染不是自己做的么,又不是走 xft 的。。不过现在我解决了,用的是直接把参数加入 ghidra 的启动脚本里,这样可以生效了
iwtbauh
2019-03-07 11:21:35 +08:00
@codehz #13

桌面程序都不去读 Xresources 文件,Xresources 文件在 X 启动时被加载到 X11 的根窗口的一个属性里,符合桌面规范的应用程序会通过 X11 协议读取到配置,而不会去磁盘读取 Xresources 文件,其实上这个文件叫不叫 Xresources 都可以,你甚至可以在 xinit 脚本里以编程的形式自己向根窗口添加新属性。

另一个规范是 XSETTINGS 机制,XSETTINGS 类似于 Xresources,也是基于 X11 协议,但是是较新的方案,例如,gnome 的 tweaks 中设置的主题、字体、字体渲染效果实际上是告诉 gnome settings daemon 设置 XSETTINGS,因此符合规范的应用程序都可以直接使用。

由于不使用桌面环境可能不能配置 XSETTINGS,因此只能选择较旧的 Xresources 方案。

应该尽量避免使用平台特定方案,因为这样其实是鼓励将桌面规范碎片化。
codehz
2019-03-07 11:26:09 +08:00
@iwtbauh #14 整个 X11 都快被 wayland 吃了,也不在乎最后那么一点了)此外之前用 gnome3 和 kde 的时候 java 都是炸的,当时也没迫切使用的需求,所以也没管
iwtbauh
2019-03-07 11:27:35 +08:00
@codehz #13

并不是要走 Xft,而是这个属性的名字因为历史原因就是以 Xft 开头的,甚至在 XSETTINGS 上也是以 Xft 开头,然而 GTK 和 QT 程序照样读取此属性。这完全是历史原因。换句话说,这些属性只是几个值(开不开抗锯齿?微调方式? RGBA 模式?),并不是字体渲染程序。
iwtbauh
2019-03-07 11:31:38 +08:00
@codehz #15

我个人是及其反对 wayland 的,只要 X11 不倒(没人去维护了),我是不会去切换到既不成熟也不优雅的 wayland 的。

我的 java jre 一直是遵守某个规范的(可能是 XSETTINGS,也可能支持 Xresources ),我今天晚上回去看看装个 java 11 看看能不能遵守,按理说不会出现新版不遵守的情况,也可能是上游还没搞好。
Cloutain
2019-03-07 11:36:35 +08:00
试了试,1.要装 JDK ( java 开发的,我晕了) 2.比 IDA 分析慢了些 3.居然没识别出 WinMain (可能是我设置问题) 4.有类信息汇总(这点比 IDA 好,不过 IDA 有 RTTI 相关的插件...) 4.反编译结果比预想的好多了,自动对应着看很舒服( F5 太重要了)
比预想的好多了,尤其是有界面,开源的一些分析工具都是命令行的(糟心)。
Cloutain
2019-03-07 11:51:06 +08:00
加一点,上面有老兄提到了,NSA 的东西要小心,TK 才在微博提到了 NSA 入侵华为总部的事情,华为的安全等级有多高不需要说了。
cattrace
2019-03-07 12:34:54 +08:00
目前最严重的 bug:更改后的 pe 文件导出后异常,无法使用

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/541752

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX