SlemBunk木马浅析
这篇讲的是对SlemBunk这款Android木马的深度剖析。作者从拿到样本开始，一步步拆解其设计精妙之处。木马的核心目标很明确：伪装成常用应用，骗取用户的信用卡敏感信息。 它实现持久化和隐蔽性的手段堪称一套组合拳。首先，它通过获取设备管理员权限、控制锁屏状态、隐藏自身图标，并设置开机自启及SD卡监听，确保自己牢牢驻留在用户手机中。更狡猾的是，它会实时监控当前运行的应用，只在用户使用特定目标应用时才弹出欺骗界面，极大增加了欺骗的成功率。 在信息窃取层面，SlemBunk不仅读取短信记录、电话号码和设备ID，还能通过高优先级的广播接收器，监听甚至拦截所有短信。木马通过短信下发“CC”指令，实现远控。整个流程从激活、隐藏到窃密、回传，环环相扣。这种设计既高效又隐蔽，也为后续的变种演化提供了一个技术蓝本。
深入解析DLL劫持漏洞
这篇文章深入剖析了DLL劫持这项古老但依然实用的技术。作者从Windows DLL加载机制的核心漏洞出发，对比了Windows XP SP2前后搜索顺序的关键差异，特别是SafeDllSearchMode开启与否对“当前目录”优先级的影响。 文章重点区分了三种主流的利用场景：针对应用程序安装目录的劫持（需要写权限，常用于持久化或“白加黑”免杀）、针对文件关联的劫持（只需用户打开特定文件，如PDF，条件最简单），以及针对安装程序的劫持。通过Notepad++安装包的ProcMon抓包实例，具体展示了如何识别和利用漏洞。 此外，文章还结合了HaifeiLi关于Chrome/Edge浏览器“自动下载”漏洞的案例，拓展了DLL劫持在现代软件环境中的攻击面，并简要提及了新版Edge对DLL注入的缓解措施。整体来看，它系统梳理了从原理、挖掘（如使用ProcMon过滤）到利用的完整链条。
12行代码的浏览器DoS攻击分析及防御
这篇讲的是如何用12行JavaScript代码让主流浏览器甚至移动设备陷入DoS崩溃。作者从pjax技术所依赖的`history.pushState`接口切入，剖析了其工作机制：该接口允许无刷新修改URL并记录历史状态。 攻击的核心在于一个循环：代码通过上万次调用`history.pushState`，不断向浏览器历史堆栈中堆积记录。这会导致页面地址被无意义的长字符串覆盖，CPU与内存占用率在短时间内飙升至100%，最终造成Chrome、Firefox、Safari等浏览器崩溃，甚至引发iPhone重启或Android应用闪退。作者在虚拟机环境中的实测数据，清晰展示了循环次数与系统资源耗尽之间的关联。 在剖析原理的同时，文章也给出了面向用户的直接防御建议——保持安全意识，不轻易点击来源不明的链接。更深层次地，它提醒我们，现代Web API在提升体验的同时，也可能被滥用为攻击向量。开发者在使用这类接口时，需要考虑其潜在风险与边界情况。
看见CSRF我不怕不怕了
这是一篇典型的故障排查与实战经验分享。作者从自身接手安全项目时遇到的CSRF（跨站请求伪造）问题出发，坦诚自己之前因不理解而一直采用屏蔽或绕过的“鸵鸟策略”，最终在Django+Jinja2的实际环境中不得不直面解决。 文章首先清晰地拆解了CSRF是什么、为何危险以及其攻击原理，为后续实战奠定了理论基础。核心价值在于后半部分的解决方案详解：从Django中间件的配置原理，到在模板（包括Jinja2）中正确植入csrf_token的具体代码，再到处理AJAX异步请求时的注意事项，都给出了可操作的步骤。作者不仅讲了“怎么做”，也解释了中间件检查的“为什么”，比如必须置于SessionMiddleware之后等细节，让读者知其然也知其所以然。 对于曾对CSRF一知半解、或在Django项目中遇到同样困扰的开发者来说，这篇文章提供了从概念扫盲到落地修复的完整路径，是克服安全“踩坑”经历的一份实用参考。
WiFi 万能钥匙原理和危害探究
这篇讲的是，作者从一次偶然发现入手，探究了WiFi万能钥匙这类软件背后令人不安的运作逻辑与潜在风险。 他发现，即便自己从未主动使用，手机的WiFi列表也可能被软件打上“一键免费连接”的提示。分析指出，软件的核心在于一个庞大的云端数据库，它通过获取用户设备上保存的明文或弱加密密码，将每个用户的1-10个WiFi信息（如MAC地址、密码）上传汇总。凭借数亿用户，这个数据库的规模相当惊人。 连接时，软件会申请位置权限，以缓存附近WiFi信息并可能用于广告投放。它主要通过三种方式尝试联网：利用更精准的MAC地址进行密码匹配、对弱口令（如常见数字组合）进行撞库，以及可能在后台静默尝试暴力破解。 文章强调，真正的隐患不止于网速变慢。一旦网络被具备技术能力的攻击者蹭上，他们可能进一步尝试破解路由器管理密码，从而在同一局域网内实施欺骗、投毒等控制手段。作者最后给出了一些实用建议，如为访客单独设置受限的WiFi子网络，或隐藏SSID广播，来防范这种“无感知”的蹭网行为。
Android安全–Dex文件格式详解
这篇讲的是 Android 系统里 Dex 文件格式的深度解析。作者从一个简单的 Java 程序生成 Dex 文件开始，聚焦分析了文件头这个核心区域的内部构造。 文章详细解读了魔数、校验码和 SHA-1 等关键字段。特别是为了确保文件安全，系统设计了双重校验机制：先用 Adler32 快速筛查文件是否损坏，再用 SHA-1 进行高精度的完整性验证。这种分层的设计思路既高效又可靠。 此外，文章还剖析了文件头中字符串索引的存储方式。作者指出，Dex 文件使用了 uleb128 变长编码来表示字符串长度，这种精巧的编码能在绝大多数情况下节省空间，是针对移动端场景的务实优化。 通过对这些底层细节的拆解，文章揭示了 Dex 文件如何兼顾执行效率与安全性。理解这些格式规范，是深入进行 Android 应用安全分析和性能调优的基础。
老生常谈，安全上你不该犯的错！
这篇文章聚焦于Web开发中几个老生常谈却依然常见的安全漏洞：SQL注入、XSS攻击与猜测URL攻击。作者从实际案例出发，剖析了漏洞存在的根源——核心问题都在于未对外部输入进行充分验证与处理。 对于SQL注入，文章以一段直接拼接参数的查询代码为例，展示了攻击者如何通过构造`?ID=1 OR 1=1`获取全表数据，并指出了使用ORM框架或参数化查询是根本的解决方案。针对XSS攻击，文章解释了恶意脚本如何通过URL或数据库存储窃取用户Cookie，并强调了对所有输入进行HTML编码的重要性。至于猜测URL攻击，则是通过遍历参数来越权访问数据，建议采用无规律ID、增加权限校验或添加校验字段来防范。 文章最后提出了一个关键观点：安全是一个系统工程，其首要原则是“不要相信任何输入”，需对包括URL参数、Cookie、Header在内的所有外部信息保持警惕。同时，配合使用安全扫描工具进行检测，能进一步提升系统安全性。
也来谈谈沙箱逃逸技术
这篇讲的是作者基于过往经验，总结的一系列针对在线沙箱检测的逃逸技巧。核心观点是：沙箱因其环境特征，反而可能暴露出独特的“指纹”，而绕过检测的关键在于识别并利用这些差异。 文章首先从进程检测入手，指出直接明文比对进程名（如vmtoolsd.exe）会触发监控，而用加密后的密文进行比对则是一种有效规避。接着，作者详细列举了多种沙箱指纹特征：例如特定的Windows ProductId（如Anubis沙箱的76487-640-1457236-23837）、有规律的ComputerName（如某些沙箱环境以“xiaochen”开头）、固定的内存大小（Anubis 128M、火眼512M），以及固定的样本路径（如Comodo沙箱的C:\TEST\sample.exe），这些在不同厂商间存在明显差异。 此外，文章还探讨了如何在不联网的情况下泄露沙箱数据，比如将文件内容写入注册表，或更巧妙地将二进制数据编码到图片像素中，利用沙箱截图功能来传递信息。最后，作者总结道，逃逸的核心思路在于找到“沙箱有的而别的机器却没有的”特征，以及开发“你有的而别人没有的”绕过方法，为攻防双方提供了具体的实战视角。
Android安全–一次简单的脱壳Dump dex实践
这篇讲的是作者对一个加壳Android应用进行手动脱壳、还原出完整dex文件的完整实践。APK的dex文件只有1KB多，显然代码被加密保护了，真正的内容需要在运行时解密和动态加载。 作者的核心思路是“在运行时拦截解密后的代码”。他没有用一键脱壳工具，而是通过经典的调试器组合来亲手捕获。具体流程是：先部署IDA的android_server进行远程调试，通过adb和jdb完成进程附加，然后在关键的动态链接库`libdvm.so`中，找到了负责加载dex文件的`dvmDexFileOpenPartial`函数并下断点。这个函数在程序运行时会被调用，其参数就包含了内存中解密后的dex文件地址。 断点命中后，通过查看寄存器R0的值，就能在内存中看到完整的dex数据结构。最后，利用一个简单的IDC脚本，根据dex文件头部记录的文件大小信息，将这段内存区域完整地dump出来，就得到了一个可用的dex文件。 整个操作像一次精密的追踪：从静态分析发现异常，到动态调试定位关键函数，再到内存取证完成“抓捕”。它演示了一种不依赖特定脱壳工具、而是基于对Android运行时机制理解的通用思路。
Joomla反序列化漏洞的查漏补缺
当2015年Joomla曝出高危的反序列化漏洞时，安全社区迅速展开了分析。但这篇来自绿盟科技的技术复盘，却质疑了当时主流分析中的一个共识——“漏洞源于Joomla自定义了SESSION序列化机制”。作者通过源码分析指出，Joomla虽然注册了自定义的session处理函数，但其write方法并未改变PHP默认的序列化格式（键名+竖线+serialize值）。问题根源不在于此。 文章随后将矛头指向了更底层的问题：PHP本身的SESSION序列化处理器配置。它引用ryat的经典研究，说明当系统配置中写入SESSION（如php_serialize处理器）与读取SESSION（如php处理器）使用了不同的处理器时，会导致数据解析出错，从而触发反序列化对象注入。Joomla的漏洞正是利用了这种配置不一致。 这篇文章的价值在于“查漏补缺”，它引导读者跳出对应用层“奇技淫巧”的讨论，重新审视PHP底层机制本身可能埋下的坑。对于安全研究者和开发者而言，这是一个重要的提醒：漏洞的根源有时藏在更基础的依赖配置之中。
Burpsuite插件开发之RSA加解密
这篇讲的是如何为 Burpsuite 开发一个处理特定混合加密格式的插件，核心目标是解密数据包、注入测试 payload 后再加密回传，主要用于针对自定义加密通信的 APK 进行安全测试。 作者面对的数据包是典型的“RSA+DES”混合加密结构：一个 JSON 串中包含用 RSA 加密的 DES 密钥（encryptKey）和用该 DES 密钥加密的数据（data）。插件开发的核心，在于正确实现了 `InsertionPoint` 接口，以支持这种非标准格式。具体思路是，在 `getInsertionPoints` 方法中，插件会解析请求参数，识别出特定的加密参数（如参数名“c”），随后依次用配置的 RSA 私钥解密得到 DES 密钥，再用该 DES 密钥解密出明文 JSON 内容。最后，将解密后的明文 JSON 中的各个键值对分别构造为独立的注入点，从而让 Burpsuite 的扫描器和 Intruder 模块能够直接对原本不可见的加密数据内部进行模糊测试或漏洞探测。 这个插件的价值在于，它将一个需要手工逆向分析加解密流程才能进行安全测试的场景，自动化为了一个可复用、可配置的插件。实现的关键在于透彻理解目标应用的加解密协议，并利用 Burpsuite 的 `InsertionPoint` 扩展点，巧妙地将加密解密逻辑无缝嵌入到测试流程中。
IOS安全—阻止tweak注入hook api
这篇讲的是如何通过一种简单的编译设置来阻止iOS应用被Tweak注入和Hook。作者从网上看到一个通过添加特定Linker Flags来防止dylib注入的方法，并动手进行了验证。 他先用Theos编写测试Demo，在不添加任何flags的情况下，成功Hook了viewDidLoad方法并打印日志。随后，在Xcode的Other Linker Flags中加入`-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null`并重新编译。再次测试后，发现注入的dylib无法加载，Hook失败。通过MachOView可以看到，二进制文件中多出了一个名为`__RESTRICT/__restrict`的段。 文章深入分析了其原理：根据dyld源码，当主可执行文件包含此特定段时，系统会忽略`DYLD_INSERT_LIBRARIES`等环境变量，从而阻断了动态库注入的途径。这是一种轻量级的防护手段。然而，作者也展示了攻防的动态性——他使用010 Editor手动修改了这个段的名称，重新签名安装后，应用又能够被成功注入了。这清晰地揭示了该防护机制的核心依赖于段的特定名称，为安全研究提供了有价值的视角。
JAVA序列化和反序列化及漏洞补救
这篇从最近一起Joomla高危漏洞事件讲起，探讨了由此延伸出的Java序列化与反序列化的安全风险。文章首先用通俗的语言解释了什么是对象序列化——即将内存中的对象转换为可存储或传输的字节流，以及其反向过程。 重点在于，作者揭示了反序列化过程中的一个致命风险：当应用接受并反序列化外部输入时，如果缺乏检查，攻击者可构造恶意字节流，在服务器端触发任意代码执行。即便代码未直接使用危险类，只要运行环境中存在如Apache Commons Collections这样的依赖库，漏洞就可能被利用。 对此，文章给出的补救方案包括：升级Apache Commons Collections至3.2.2及以上版本，并通过配置默认关闭那些不安全的Transformer类序列化支持；同时，参考RedHat等厂商发布的针对具体产品（如JBoss）的补丁。文章还提到一个更根本的思路：通过限制JVM执行外部命令的能力，来降低未知漏洞的危害。 最后，作者点出这类问题的本质常在于反射的滥用，提醒开发者在跨网络传输序列化数据时，必须将安全性作为核心考量。
iOS安全—dumpdecrypted APP砸壳
这篇讲的是iOS应用逆向工程中一个关键步骤：如何给从App Store下载的加密应用“砸壳”。作者从dumpdecrypted这个工具出发，详细拆解了整个解密流程。 文章首先点明背景：商店下载的应用都带有加密壳，阻碍了class-dump或IDA这类静态分析工具的使用。核心方案分三步走：首先在本地下载并编译dumpdecrypted源码，生成一个dylib动态库；接着，通过Cycript等工具定位到目标应用的沙盒目录——因为只有沙盒内才有读写权限；最后，将生成的dylib上传至该目录并注入，启动应用即可完成解密。 其巧妙之处在于原理的简洁：通过DYLD_INSERT_LIBRARIES环境变量，强制让App加载这个自定义的dylib。动态库在初始化时便会执行dump操作，从而在运行时将解密后的二进制数据导出。整个过程清晰地展示了如何利用系统机制与沙盒环境来实现对加密应用的动态脱壳，为后续的深度分析扫清了障碍。
内存寻址原理
这篇讲的是内存寻址的底层原理，作者从网络安全分析中遇到的寻址难题切入，直接点明这是理解漏洞分析和系统行为的关键基础。 文章的核心内容，是对CPU几种工作模式——实模式、保护模式与虚拟8086模式——进行了清晰的对比。它解释了实模式下1MB的寻址限制、所有内存均可直接访问的特性，以及它在系统启动阶段的作用；而保护模式则支持高达4G（32位）的地址空间，并通过段页式机制实现了内存隔离与保护，这是现代操作系统安全运行的基石。 在概念梳理上，文章厘清了逻辑地址、线性地址与物理地址的转换链条。特别是通过一个具体的程序地址实例，逐步拆解了段选择符如何从描述符表中定位段描述符，最终与偏移量相加得到线性地址的过程，让抽象的理论变得可视化。 理解这些寻址细节，对于追踪内存越界、分析指针漏洞以及编写底层驱动都至关重要。文章将计算机体系结构的演进需求与具体的内存管理实现结合起来，为开发者搭建了一个从逻辑地址到物理内存的完整认知地图。
SSL多域名绑定证书的解决方案
这篇讲的是如何在一个服务器上，为多个不同的域名部署HTTPS服务。传统上，一张SSL证书通常绑定一个域名，但在实际运维中，我们常常遇到一个服务器需要同时承载多个域名的情况。文章从这个现实背景出发，梳理了几种主要的解决方案。 最直接的方式是采用虚拟主机技术，为每个域名分配独立的IP地址并绑定各自证书，但这对IP资源要求较高。对于同级子域名，可以申请通配符证书，但它只能匹配二级子域名，无法覆盖更深层级或主域名本身。更灵活的方案是使用支持“使用者可选名字”（SAN）扩展的证书，通过XCA等工具，就能将多个不同的域名都写入同一张证书中。 如果必须为每个域名单独签发证书，那么SNI（服务器名称指示）技术就成了关键。它允许服务器在SSL握手阶段就识别出客户端请求的域名，从而返回正确的证书，实现“单IP、多证书”。文章指出，这项技术已获得主流浏览器和Web服务器的支持，为灵活部署HTTPS提供了坚实的基础。
谈谈go语言编程的并发安全
这篇讲的是Go并发安全的一个经典认知误区。作者从修复分布式存储项目Weed-FS中的一个非并发安全问题出发，提交了加锁的PR，却意外被维护者以“单写多读场景不需要加锁”为由拒绝。 这挑战了作者基于C/C++开发经验的常识，促使他深入探究Go内存模型。文章梳理了Go官方建议的核心：对多goroutine访问的数据必须序列化（加锁或使用channel），并引用了社区讨论中的警句——“Don't be clever”。最终，通过go-nuts邮件列表的权威讨论，验证了作者“必须保护”的观点是正确的，维护者也接受了修改。 文章特别指出，许多人存在“每次读取都是原子行为”或“数据竞争最多只是读到旧值”的误解，这其实是非常危险的。作者推荐使用`go run/build/test -race`命令来检测这类难以复现的隐患，并提醒大家，即使程序运行正常，也不代表没有并发问题。
说说下载劫持那些事儿
这篇从双十一“苹果6变6袋苹果”的梗出发，生动剖析了安卓应用下载劫持的技术原理。作者将网络下载类比为“网购”，把DNS服务器和运营商网关形象地称为“黄页”和“总机”，清晰拆解了从发起请求到文件传输的完整链路。 文章重点揭示了劫持发生的两个关键节点：一是DNS服务器被篡改，导致域名解析到“骗子服务器”；二是运营商网关通过302跳转机制，将用户引导至合作的推广服务器。这两种方式都会让用户最终下载到并非预期的应用包，可能被捆绑其他软件。 最后也提到了一个初步的解决方案——手动修改DNS，但运营商网关层面的劫持则更难规避。全文通过生活化比喻和流程图，把原本隐蔽的网络劫持手段讲得通俗明白，结尾幽默地回到了“六袋苹果”的调侃，读来轻松又有收获。
学习手册：浅析DDoS的攻击及防御
这篇讲的是DDoS攻击的完整图景——从基础概念到实战工具。作者从“拒绝服务”和“分布式”这两个核心点出发，解释了攻击如何演变成依靠“僵尸网络”进行的协同作战。文章梳理了DDoS的发展史：早期只是黑客的炫技游戏，后来被宗教和商业组织用于勒索与报复，最终甚至成为国家级网络战争的武器，其中中国和美国是受灾最严重的地区。 在技术层面，文章将攻击方式归纳为四类：耗尽网络带宽的流量洪水、针对TCP连接表的SYN洪水、专门攻击DNS和Web服务的应用层攻击，以及混合多种手段的综合性攻击。特别提到随着僵尸网络小型化，慢速应用层攻击正成为新的趋势。文章还介绍了几款知名的开源工具，比如曾被广泛使用的低轨道离子炮（LOIC）和专门产生HTTP流量的HULK，让读者直观了解攻击的实现手段。 整体而言，这篇文章不仅解释了DDoS“是什么”，更通过攻击工具和态势分析展现了“如何发生”，对于理解当前网络空间中的流量型威胁提供了清晰的框架。
文档安全加密系统的实现方式
这篇讲的是文档安全加密系统如何实现高效且透明的安全防护。文章从加密技术的基础出发，指出虽然DES、RSA等算法是核心，但真正决定系统效能的，是加密操作在系统中的实现方式。它重点对比了静态加密与动态加密：前者需要用户手动解密才能使用文件，后者则在后台实时处理，合法用户完全无感，文件访问体验与未加密时无异。 实现真正的动态加密极具挑战，因为它需要在操作系统内核层进行干预。文章清晰地剖析了Windows文件操作流程的四个层次，指出只有在内核层的文件过滤驱动程序中，才能拦截所有文件操作请求，从而实现实时加解密。位于应用层的方案本质上只是“伪动态”，无法做到真正的透明。 最后，文章以亿赛通SmartSec系统为例，展示了动态加密的落地架构：通过内核层的文件过滤驱动实现核心加解密，同时结合应用层进行访问控制和行为审计，两者配合既提升了安全性，也优化了系统性能。这种分层协同的设计思路，为构建企业级文档安全方案提供了清晰参考。
