每一个不曾起舞的日子都是对生命的辜负。
瞎扯淡又到年底了， 祝各位大佬新年快乐。本期就讲一讲 Ghidra 11.0 版本的更新。 更新简介英文版更新可以点击这里 大的更新就2个点，一个是 BSim 和 GhidraGo。 BSim 是基于Ghidra 反编译器做的一个函数相似度匹配能力。 咋一看， 我还以为又搞了一个 VersionTracking 出。它可以比较本地文件间的相似度， 也可以比较远程服务器中的文件。 相似度比较这块我用的比较少，暂时也没法评价他的优劣。 Gh
看了《我在北京送快递》这本书， 忽然也想起了我大学时做的各种兼职， 记录一下。 起因为什么要做兼职？ 具体的原因我已经想不起来了，但是有一定肯定是记得的，那就是没有钱，而兼职是钱的来源之一。受限于当时的认知吧， 只知道兼职可以赚到钱，所以在大一大二那段时间做了一些兼职。那个时候学业相对比较空， 课程也不算太难，再加上大一上不允许带电脑， 所以时间是挺多的。 兼职是通过中介找的，中介的意思是可以选择帮找一年，或者4年吧，收的钱不一样。当时
背景最近分析了一个 app，有 frida 检测，一旦 attach 之后，app 就退出了。过去分析的一些 app，通常都有 frida 的检测，但不会这么暴力的退出。 于是我就分析了一下这个 app 的检测逻辑。基于此，我把市面上常见的一些 frida 检测逻辑都整理了一下。 检测方法frida 的检测可以分为两种， 一种检测frida-server 是否运行， 一种检测frida 是否已经注入到程序中。 检测frida-serve
背景之前研究过某个 android app 的 vmp，通过模拟执行成功把里面的算法破解了。 ios 版本的 vmp 一直没有破解，原因在于 vmp init 阶段符号找不到，我想排查问题，但海量的日志让我难以分析，所以就放弃模拟执行这条路了。app 本身有反调试，当时也没仔细去研究，所以就无法调试。 由于不知道 vmp 解释器在哪， 我采用 ghidra 指令匹配收集了一堆可能是 instruction handler的点， 但fri
背景去年遇到一个 js 版本的 aes加密算法，这个算法有一个巨大的表(4* 256), 基本可以断定是一个白盒aes 算法了， 然后我手工使用 DFA，发现并不能将白盒 aes 的密钥还原，由于当时还原 key 并不是一个强需求，所以在尝试了两次之后我就放弃了。 今年机缘巧合，为了排查线上的问题数据，需要对数据解密，还原key就变成了强需求。我本身是不太想搞的，感觉会投入很多时间并且最终还没有分析出来，但本着事不过三的原则，我还是决定
0x01 前言以前分析微信小程序，都是通过移动端获取wxapkg之后，使用解包工具解包的， 现在pc/mac都已经支持小程序了，所以移动端的操作就多少有些麻烦了。网上找了一圈，我发现pc的包跟移动端的包不太一样，根据pc_wxapkg_decrypt 可以知道，在pc端，文件是被加密了，并且现在新版本可能就不支持了。而我使用的mac端，目前并没有解密工具，所以我只能自己想办法解密了。 逆向过程打开微信的包， 可以发现微信有两个程序，一个
这篇文章主要是看看雪上的一篇分析文章之后写的，部分内容从文章中拷贝， 文章链接在这里 漏洞原理 漏洞的原理很简单， 对于命令行程序，通常会有参数， 体现在代码中就是argc 和 argv, argc 代表参数个数，argv 是参数，默认情况下，argv[0]是当前程序的路径。当我们访问argv的偏移大于argc的时候，就会出现越界访问。所以，通常情况下都是先检查下argc个数，然后再去访问的，但是linux中挺多程序写法上有一定问题。这
Ghidra 上脚本和扩展的开发都需要用到 Eclipse, 但 Eclipse 除了创建项目和调试的时候方便一点，开发体验却很糟糕。于是我就有了用 IDEA 替代 Eclipse 的想法，Ghidra 脚本支持 java 和 python2 开发， 我这里只讲 java 的配置。 使用 Ghidra 开发 Script首先，从github链接 中下载IDEA的插件， 这个插件应该只适用于社区版本的IDEA， 如果你用的是商业版， 则
前言这题是PCTF 2018 中的一道浏览器利用题。 漏洞分析存在漏洞的代码如下： 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051 void GenerateSetLength(TNode<Context> context, TNode<Object> array,
虽然还没想好写点什么，但是总觉得这里放句话比较和谐。