Posts

在平时的日常测站过程中，经常遇到前端加密相关的对抗，对请求包及响应包进行加密、HASH校验对抗修改，根据加密算法可以分为以下几种： 字符编码：例如base64等。 对称加密：AES、RC4、DES、国密SM4等。 非对称加密：RSA、ECC、国密SM2等。 混合加密：混合多步加密，例如使用AES加密内容 + RSA加密密钥，拼接进SHA1做哈希，AES + base64等。 哈希算法：用于加密解密时的数据校验，例如SHA1/256、MD5、国密SM3等。 对于字符加密，对称加密，部分非对称加密算法： 使用 autoDecode 自带的算法可解。 对于复杂的加密算法，或是不想去逆向算法，不想扣JS补环境： 使用 autoDecode 的接口加解密 配合 JSRPC 提高工作效率。 对于复杂的加密算法，例如需要判断数据包来源时，或是扣出JS函数想直接调用时： 使用Galaxy实现，支持JS 和 Python脚本，可在Hook函数中直接执行JS 函数，也可发起http请求配合JSRPC进行加解密。 扩展插件 autoDecode 最常用的解密插件，通过内置算法与接口加解密配合，基本可以覆盖80%的加解密需求。 数据解密流向： Proxy 历史：浏览器客户端 -> Burp autoDecode栏 显示解密包 -> 发送到服务端 -> 服务端响应加密包 -> 返回 Burp -> Burp autoDecode栏 显示解密包 -> 浏览器返回密文 代理数据全程对数据包无修改，解密过程仅UI中展示。 Repeater 重放：编辑明文包 -> Burp 调用加密 -> 发送到服务端 -> 返回 Burp -> burp autoDecode栏 显示解密包 -> 浏览器 区别是请求时直接是密文，需要在加密时判断当前是否已加密，已加密则避免重复加密，未加密需要自动加密。 部分缺点： ...

注意事项 在Windows中，ASLR_(Address Space Layout Randomization)（内存随机化保护）的存在使得内存地址随机化成为常态。PE文件通过其重定向表(.reloc节)能够适应这种随机化，使得程序在每次启动时都能正确处理地址引用。 shellcode作为一段纯机器码，不存在重定向表。在编写时，不能依赖固定的内存地址，由于ASLR的作用，这些地址在重启后会发生改变，导致shellcode失效。 也就是说，在开启了ASLR的系统上，在Shellcode中不能直接通过名称调用Windows API，也不能通过DLL base + 偏移的方式调用API。如果没有启用 ASLR，Windows 加载器会尝试将 DLL 加载到其 PE 头中 ImageBase 字段指定的地址。并且由于系统 DLL 是共享的，在不同进程中它们会被映射到相同的虚拟地址。 由于Shellcode没有 rdata段，不能使用全局变量，所有的变量只能在函数的内部栈上分配，使用相对寻址而非绝对寻址。 工作可以分为三步： 在内存中查找需要调用的 DLL 文件。 解析 DLL 的导出表。 通过导出表名称对比定位到函数指针。 为了简化第3步，可以先获取两个关键API（GetProcessAddress、LoadLibrary） 第一步：获取 Kernel32.DLL 地址 Shellcode 中通常需要调用操作系统API，为了使该代码可以在不同的机器上运行，避免写死地址时由于地址随机化导致找不到的问题，需要动态定位Windows API地址。 参考：Finding Kernel32 Base and Function Addresses in Shellcode - ired.team 建议动手通过 windbg 跟一遍获取流程，会加深对偏移的理解。 PEB (Process Environment Block) 是 Windows 操作系统中每个进程都有的一个数据结构，每个进程都有一个唯一的PEB。PEB中存储了进程的各种关键信息：进程的基本参数如进程的镜像基址、命令行参数、环境变量等。PEB中还存储了进程加载的模块列表（LoaderData），这个列表记录了所有被加载到进程空间的DLL信息。 同理，TEB (Thread Environment Block) 是保存线程相关的结构体，一个进程只有一个PEB，但可以有多个TEB 对应多个线程，每个TEB都持有一个指向其所属进程PEB的指针，这样线程就能访问进程级的信息。 通过获取PEB结构，遍历其中的模块列表，可以找出所需要的DLL模块。 开始之前，先细化工作： 获取 PEB 结构体的地址 https://en.wikipedia.org/wiki/Win32_Thread_Information_Block ...