翻车了,一次十分特别的体验,真是容不得一丝松懈。
编写ZAProxy请求处理(加密、解密)插件
最近遇到个事情,需要给ZAProxy编写请求处理的插件,以便于支持对加密请求扫描的功能。和之前写过的BurpSuite插件类似,ZAProxy也需要实现两个接口来完成,分别是HttpSenderListener和ProxyListener。HttpSenderListener用于处理面向Server的数据,ProxyListener处理代理的数据。相比之下,ZAProxy的接口要比BurpSuite清晰一些:
@Slf4j public class Demo implements HttpSenderListener, ProxyListener { @Override public void onHttpRequestSend(HttpMessage msg, int initiator, HttpSender sender) { // requestOut } @Override public void onHttpResponseReceive(HttpMessage msg, int initiator, HttpSender sender) { // responseIn } @Override public boolean onHttpRequestSend(HttpMessage msg) { // requestIn } @Override public boolean onHttpResponseReceive(HttpMessage msg) { // responseOut } }
此外,还需要在hook回调中完成注册:
@Override public void hook(ExtensionHook extensionHook) { super.hook(extensionHook); if (getView() != null) { extensionHook.addProxyListener(this); extensionHook.addHttpSenderListener(this); } }
为Simple DNSCrypt配置转发规则加速国内域名解析
长期以来一直使用的GeekDNS和RubyFish最近一直不稳定,通过GeekDNS的官方群,了解到最近两家又遭到了攻击,短期内无法恢复,不得已又切换回114苟且了几日。从实际使用的体验来说,在国内114DNS最为省心,解析速度快,服务稳定,EDNS-Client-Subnet和CDN支持良好。但毕竟是国内的DNS,总会冷不丁的恶心一下,用着实在难受。
从GeekDNS的官方群公告中得知,GeekDNS的启动脚本已经在Github开源。好奇他们之前解析到国内是如何做的,发现在domestic.conf中,针对特定的域名使用了国内的DNS解析:
forward-zone: name: "qq.com." forward-addr: 101.226.4.6 forward-addr: 218.30.118.6 forward-addr: 123.125.81.6 forward-zone: name: "iteye.com." forward-addr: 101.226.4.6 forward-addr: 218.30.118.6 forward-addr: 123.125.81.6
而Simple DNSCrypt只是UI,核心实际上是dnscrypt-proxy。而dnscrypt-proxy支持本地Cloaking和Forwarding,所以,在GeekDNS挂掉的时候,可用本地的规则进行“半裸奔”。Forward的规则十分简单,在配置文件中指定规则路径即可:
DNSSEC原理和分析
以前对于DNS相关的技术仅仅是略懂皮毛,没有进行全面和深入的了解。最近几年由于各方面的原因,主动被动的接触了不少,包括:
- 家庭组网和改造:尤其是近两年国内IPv6的普及;
- 公司兼职网管:负责处理公司的网络问题和VPN问题;
- VPS:也就是本博客VPS的配置;
- 项目、任务:内网渗透、应急响应等;
- 越来越糟糕的网络环境。
其中,影响最大的是DoH、DoT、DNSCrypt等安全DNS协议的出现,同时越来越多的厂商开始部署,主流操作系统也开始逐渐支持。这是一个好的开始,至少在保护个人隐私方面有了更多的选择。同时,我也开始在个人电脑、家庭、公司网络(小范围)中部署、测试安全DNS,为了做出更好的选择,在这过程中学习了很多DNS相关的知识,趁着最近因为疫情仍未复工,整理一些以前的笔记。
今天先从DNSSEC说起。作为一项互联网的基础设施,DNS协议十分重要但过于单纯,也正因如此,DNSSEC很早就被提出,是一种通过扩展DNS协议实现认证的机制,其核心原理是使用数字签名机制和信任链来确保DNS的完整性。通过DNSSEC机制,DNS Resolver或者终端用户可以确保DNS查询到的结果是否可信,即是否为权威域名服务器返回,某种层面上增加了DNS的安全性。
一种判断Android模拟器的思路
前段时间在测试一些手机、设备的时候顺手写了一些工具,由于当时现场的环境不佳,只能使用模拟器调试,无意中发现可以让模拟器拒绝服务,演示效果如下:

所以,除了通过各种行为特征检测模拟器,也可以通过是否存在某些漏洞来检测模拟器。
目前的模拟器中大多数采用了较老的Android版本,而这些Android的版本中包含了一些已知的漏洞,同时模拟器在自身的实现上也存在一些漏洞,顺着这个思路,可以找到不少能让模拟器无法使用的方法,并且能在普通权限下完成。类似于当初的nProtect,发现调试行为后,在Ring0使用out指令重启电脑。
使用Scoop安装、管理常用的编程字体
scoop-nerd-fonts是一个包含了大多数热门编程字体的Scoop Bucket,除了包括Nerd Fonts的所有字体,还包括了一些热门的编程字体,如更纱黑体、JetBrains-Mono、Source Code Pro等,而且该仓库已经加入了Scoop Known Buckets,使用以下命令可以直接添加:
scoop bucket add nerd-fonts
Windows上看着舒服且支持中文的编程字体确实不多,之前一直使用YaHei Consolas Hybrid,去年开始使用更纱黑体,直到更纱黑体上架Microsoft Store后,终于省了不少事情。而从Microsoft Store安装的字体被放在了C:\Program Files\WindowsApps*目录下(因为有收费的字体,此举应该是出于DRM的考虑?),目前Android Studio、PyCharm等未适配的程序无法找到对应的字体。考虑到还有一些Windows 10 LSTC、Windows Server之类的机器,用scoop-nerd-fonts是最省事的。
而scoop-nerd-fonts安装字体和手动的一样,复制文件并添加相关的注册表项,因此没有兼容性的问题:
编写BurpSuite请求处理(加密、解密)插件
Intro
一直以来抓包都是用Fiddler居多,Python、BurpSuite辅助。以前用不惯BurpSuite的原因主要是界面过于繁杂,Request、Reponse窗口不如Fiddler直观,以及十分不友好的Intercept功能。所以,在之前的工作中,如果遇到协议加密,我的处理方式如下:
- 优先考虑是否能通过一些手段Bypass、去掉加密;
- 编写Fiddler解密插件,有时需要Xposed、Frida、Substrate、Flex的配合;
- 使用Python编写HTTP Server、Proxy,或类似Brida之类的方式,作为Fiddler、BurpSuite的上游代理;
- 放弃或安排给其他同事。
所以之前没有写过BurpSuite插件和脚本。这几个月经历多次实战渗透之后,逐渐熟悉了BurpSuite的界面和操作,于是在最近一个需要做协议解密的App分析中,尝试使用Java编写BurpSuite的插件,用于对Request、Response的加密和解密。BurpSuite的插件并没有Fiddler那么直观,搜了一下内部仓库竟然没有相关插件供参考,大惊。进一步抽样Review了报告和近期的入职培训,才意识到自从MonkeyLord编写了XServer并在内部大力推广之后,基本没人再分析加密过程、编写插件。另外一个同事lyxhh也开源过类似的辅助工具,参考这里。
XServer大概的原理是,使用Xposed在进程中注入模块,同时开启一个HTTP Server,HTTP Server提供反射机制,所以BurpSuite可以将App的任意函数作为RPC进行调用。在此基础上进一步完善,实现重放、response修改等功能。
解决Hyper-V外部网络下Host和Guest网络互访的问题
简而言之,再一次被Microsoft自带的驱动坑了。
实际上早就遇到了这个问题,一直没搜到好的解决方案。具体情况可以描述为:
- 在Windows 10、Windows Server 2016、Windows Server 2019下,使用Hyper-V创建虚拟机并使用外部网络交换机的情况下,Host和Guest的网络无法互访。表现为Host无法ping通Guest,反之亦然。
Hyper-V的外部网络模式相当于VMWare Workstation的Bridge模式,虚拟机可以直接接入企业或者家庭的网络中,对于搭建各种服务相对方便。
Windows 10下Frida无法通过USB连接iOS设备解决方法
前几年的某个时间点,大概是在Windows的某次更新后,或者iTunes上架Microsoft Store那段时间,Frida无法通过USB访问iOS设备,而iTunes、libimobiledevice、PP助手等则不受影响。之前尝试了各种组合,包括使用Microsoft Store和独立安装的iTunes,均未能解决。简单看了一下代码,没有发现处理不当的地方。只好在遇到iOS任务时更换MacBook Pro或者Ubuntu。在Frida的Issues也有相关的讨论,参考这里和这里。
今天在处理某个任务的时候,无意中发现一台Windows 10 LTSC上,Frida能够正常通过USB连接iOS设备,iTunes是独立安装包。简单分析和尝试后,以下方法可解决无法找到设备的问题:
- 如果从Microsoft Store中安装了iTunes,卸载之;
- 连接iOS设备,从设备管理器中删除设备,并勾选删除驱动;
- 下载iTunes安装包;
- 拔掉iOS设备,重启,断网安装iTunes;
- 启动iTunes,插上iOS设备,运行Frida进行测试。
上述方法在两台Windows 10 Pro上测试通过。
iOS越狱后Cydia联网记录
在工信部发布《移动智能终端应用软件预置和分发管理暂行规定》之后,从iOS 10的某个更新开始,国行手机在安装新应用后,默认情况下不会拥有网络连接权限,必须由用户手动设置后,才能访问WLAN或者移动网络。
这功能怎么说,略显鸡肋和脱离实际。Android应用可以很好的规避,如APK安装时有相关的提示,国内市场也可以在页面上进行权限的标注,然后静默安装。所以,对于原本应该规范的Android并没有受到影响,反而是相对可靠的iOS手机(国行),变得十分多余。
受到显著影响的,则是越狱后的Cydia、Sileo及其他越狱后安装的程序。虽然有帖子表示会有一定概率能够让系统自动弹出联网权限提示,但我从来没遇到过。通过参考各种帖子和实践,目前可用的方法大概有如下几种。