Showing Posts From
安全
Frida / frida-tools / Objection 版本对齐 + 32 位 Python 的坑
CTF / 授权渗透 / 自己应用的安全测试里 Frida 是常用工具。装的时候版本三个（frida、frida-tools、objection）加设备端 frida-server 要对得上，不然经常 unable to communicate with remote frida-server。 目前最稳的组合 写在最前面——如果你不追新，直接抄这套： pip install frida==16.7.19 frida-tools==13.7.1 objection设备端 frida-server-16.7.19（对应 Android 架构）。这套是当前社区教程覆盖最广、踩坑最少的组合。 用最新 Frida 17 呢 装最新版： pip install frida frida-tools objectionfrida-tools 会跟着 Frida 版本自动装匹配的（一般是 13.x）。Objection 最新版也已经跟上了 Frida 17，但 iOS 场景仍有已知问题，比如：ObjC is not defined 部分 explore 命令异常 SSL Pinning 相关脚本行为变化Android 场景 Frida 17 已经比较稳。iOS 建议留在 16.7.x。 frida-ps -U 报"unable to handle 64-bit" 一装完想连手机测： frida-ps -U崩： Failed to enumerate processes: unable to handle 64-bit processes due to build configuration几乎 100% 是你装了 32 位 Python，而设备上 frida-server 是 64 位。Frida 的 Python 绑定的位数必须和目标进程匹配。 先确认 Python 位数： python -c "import struct;print(struct.calcsize('P')*8)"输出 32 就是罪魁祸首。 解法：从 python.org 下 64-bit 安装包（找 "Windows installer (64-bit)" 或者 "Windows embeddable package (64-bit)"） 卸载 32 位 Python 新建虚拟环境：python -m venv frida_env frida_env\Scripts\activate pip install frida==16.7.19 frida-tools==13.7.1 objection主机 Frida vs 设备 frida-server 必须版本一致 主机 Python 侧和手机上的 frida-server 必须严格同版本号，包括小版本。混版本症状： frida.core.RPCException: unable to communicate with remote frida-server对齐流程： # 1. 主机装什么版本 frida --version # 假设 16.7.19# 2. 下对应设备端 # github.com/frida/frida/releases → frida-server-16.7.19-android-arm64.xz# 3. 手机架构 adb shell getprop ro.product.cpu.abi # arm64-v8a → 用 android-arm64 # armeabi-v7a → 用 android-arm# 4. 推送 + 启动 adb push frida-server-16.7.19-android-arm64 /data/local/tmp/frida-server adb shell "chmod +x /data/local/tmp/frida-server" adb shell "/data/local/tmp/frida-server &"# 5. 主机验证 frida-ps -U | head环境里有多个 frida.exe pip show frida 显示当前 venv 装了，但 frida-ps -U 还是老版本行为——大概率是 PATH 上另一个 Python 里也有 frida.exe： where frida where frida-ps看到两条以上路径，把不想用的从 PATH 里挪走，或者用 venv 里的绝对路径调： D:\project\frida_env\Scripts\frida-ps.exe -U一张速查表症状 常见原因unable to handle 64-bit 32 位 Pythonunable to communicate with remote frida-server 版本不一致 / server 没起 / SELinuxObjC is not defined（iOS） Objection + Frida 17 兼容问题Failed to attach: process not found root 权限 / SELinux / SEAndroidfrida-server 起来立刻退出 架构下错、缺可执行权限一句话总结 64 位 Python + frida==16.7.19 frida-tools==13.7.1 + 同版本 frida-server 是当前最稳的组合。Frida 17 追新可以，iOS 用户等它再稳一稳。
BIP39 助记词会不会重复：数学上不会，现实中被坑的另有其人
有人问过我一个纠结的问题：用钱包 APP 生成助记词，会不会跟别人重复导致钱包被盗？ 数学上算一下就知道，重复的概率低到根本不用担心；真正被盗的原因，几乎都是别的坑。 BIP39 生成流程 12 词助记词的生成，标准流程只有三步： 1. 从系统 CSPRNG 取 128 位熵 import secrets entropy = secrets.token_bytes(16) # 16 字节 = 128 位secrets 底层用的是操作系统提供的密码学安全随机源：Windows：BCryptGenRandom Linux：/dev/urandom macOS：SecRandomCopyBytes2. 拼上 4 位校验和 对 128 位熵做 SHA-256，取前 4 位挂到熵尾部，凑成 132 位： 128 位熵 + 4 位校验和 = 132 位3. 每 11 位查一次词表 BIP39 词表有 2^11 = 2048 个词。132 位 / 11 = 12 个词。 10010101100 → abandon 11100101010 → ability ...碰撞概率有多低 12 词的熵是 128 位，等于 3.4 × 10³⁸ 种可能。用生日悖论算一下极端情况： 假设全球 100 亿人，每人生成 100 万个钱包，一共 10¹⁶ 个： 碰撞概率 ≈ N² / (2 × 2¹²⁸) ≈ 10³² / 6.8 × 10³⁸ ≈ 1.5 × 10⁻⁷约 0.000015%，还是极端假设。真实世界远远达不到这个量级。24 词是 256 位熵，那更是天文数字。 只要用正规钱包 + 系统 CSPRNG 生成，重复被盗几乎不可能。 真被盗的常见姿势 1. 随机数不安全 自己造轮子最容易出问题： import random random.seed(time.time()) # 危险Python 的 random 是伪随机 + 可预测种子。攻击者知道大概时间戳，就能枚举出你所有可能的助记词。 永远用 secrets 或 os.urandom，不用 random。 2. "幸运数字"当种子 有人觉得自己的生日、手机号能当种子更好记： seed = "5201314" entropy = sha256(seed)这种熵严重不足。攻击者跑一遍 0 到 9,999,999,999 就把你的钱包翻出来了。任何"人可以记住"的种子都不够安全。 3. 脑钱包 想一句话当助记词： iloveyou123彩虹表早就把常见短语算光了，这种钱包上链一分钟就被扫走。 4. 假钱包 APP 流程： APP 生成助记词 → 悄悄上传服务器 → 等你存币 → 转走来路不明的浏览器插件、"新币空投工具"是重灾区。装钱包只从官网或 App Store。 5. 助记词泄露截屏保存到手机相册（云同步就完了） 记在便笺、微信自己的对话 输入到"辅助工具"网页正确做法：只离线纸质备份，多份异地存放。 安全生成的一行代码 用 bip_utils： from bip_utils import Bip39MnemonicGenerator, Bip39WordsNummnemonic = Bip39MnemonicGenerator().FromWordsNumber(Bip39WordsNum.WORDS_NUM_12) print(mnemonic)内部就是 CSPRNG + 128 位熵 + SHA-256 校验，标准 BIP39 流程。 一句话总结 担心助记词重复是想多了；担心自己不用 CSPRNG、拿脑钱包和假钱包 APP 是应该的。 只要用正规钱包生成 + 离线纸质备份，安全性远高于随机重复这种理论问题。
AES加密CBC模式没有iv也可以解密
问题分析首先看请求，发现密码被加密了跟一下代码，发现是AES加密CBC模式，向服务器发送了密文，key存在session里头，发现iv没有只要有key的话iv随机只会影响前面64位的结果，可以发现生成了64位随机数结论 在AES加密CBC模式中，如果没有IV（初始化向量），只要拥有密钥（key），仍然可以解密数据。IV的作用是确保相同的明文在不同加密过程中产生不同的密文，但在没有IV的情况下，解密时使用全零的IV即可。