re-license について
re-licenseは、許可されたテストや研究で登録・ライセンス検証箇所を特定し、処理を調べるリバースエンジニアリング用スキルです。静的・動的解析の手順を扱い、自社ソフトウェア、許可済みテスト、研究環境での利用に限定しています。
主な機能
- 01登録・アクティベーション検証の特定
- 02成功・失敗分岐の追跡
- 03比較・復号・署名検証の調査
- 04オンライン認証とオフライン認証の判別
- 05マシン紐付けや期限モデルの識別
- 06検証箇所と根拠の記録
活用シーン
- 01許可されたライセンス試験で検証箇所を特定
- 02認証がサーバーに依存するかを判定
- 03マシン紐付けや期限の挙動を調査
- 04後続解析用に検証ロジックを整理
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ dslsdzc/ rev-skills --skill re-licenseインストール後、Claude Code で/re-licenseを入力して読み込まれたか確認します。
同梱ファイルreferences/decision-tree.mdreferences/gotchas.md
詳細
ライセンス検証ロジックの分析(登録チェックの特定)
使う場合/使わない場合
- 境界([[re-cracking]]を継承):対象は自分が所有するソフトウェア/許可を得たテスト/CTF・研究環境に限ります。無許可でのソフトウェアのロック解除や商用ソフトウェアの回避は禁止です。戻り値の観察など、ブレークポイントを使った動的な手順に入る前に、ユーザーは対象の帰属(所有権/テスト許可/研究環境)を明示する必要があります。
- 使う:プログラムに登録/アクティベーションのフロー(シリアル番号、登録コード、ライセンスファイルの入力)があり、「どこで、どのように検証しているか」を特定する必要がある場合
- 使う:解析の前段階として、[[re-patching]]/[[re-keygen]]に検証ポイントのアドレスと検証アルゴリズムを提供する場合
- 使う:ライセンスがオンラインアクティベーションかオフライン検証かを判断する場合。マシンコードへの紐付けや、有効期限/サブスクリプション型ライセンスを特定する場合
- 使わない:検証分岐がすでに特定されており、バイト列の変更だけで回避する場合(直接[[re-patching]]を使用)
- 使わない:ライセンス機構がないと確認できた場合(登録 UI/レジストリ/ライセンスファイルの読み取りがない場合——正直にユーザーに伝えてください。落とし穴 5 を参照)
- 使わない:プロトコル層の分析のみを行う場合(オンラインアクティベーションの通信解析には[[re-protocol]]を使用)
- 注意:サンプルがパックされている場合は先にアンパックします([[re-anti-analysis]])。検証関数が難読化されている場合は、先に[[re-deobfuscate]]を使用します(落とし穴 1 を参照)。動的な手順ではサンドボックスを使用します([[re-sandbox]]、[[re-analyze/platform-tips]]の最優先原則)。
ツールの準備
デバッガー(OS 別)
- Linux/Wine で PE をデバッグ:[[re-gdb]] ——
apt install gdb/dnf install gdb/pacman -S gdbを実行し、gdb --versionで確認します。Wine から直接読み込む場合:wine sample.exeを実行した後、gdb -p <pid>でアタッチします([[re-analyze/platform-tips]]の Linux 分岐)。 - Windows:[[re-x64dbg]] —— 公式リリースの zip を使用します。アタッチには管理者権限が必要です([[re-analyze/platform-tips]]の Windows 分岐)。確認方法:サンプルを読み込んでステップ実行できること。
- macOS:[[re-lldb]] ——
brew install lldbを実行し、lldb --versionで確認します。アタッチ前に Developer Tools の許可を確認します([[re-analyze/platform-tips]]の macOS 分岐)。 - WSL:Windows プロセスにはアタッチできません。境界をまたぐ分析には Windows 側のツールを使用し、WSL 内では静的分析のみ行います([[re-analyze/platform-tips]]の WSL 分岐)。
デコンパイラー([[re-ghidra]]など、クロスリファレンス用ワークベンチ)
- Ghidra:
apt install ghidra/dnf install ghidra/pacman -S ghidra/brew install --cask ghidraを実行し、analyzeHeadless -helpで確認します(インストールの詳細は[[re-ghidra]]を参照)。 - 代替:[[re-ida]](ヘッドレス版
idat。コマンドは該当スキルを参照)、[[re-radare2]](インストール方法は該当スキルを参照。インストール後にrizin -vで確認)。 - 用途:strings/API のクロスリファレンス(xref)は、「登録関連の関数を呼び出しているのはどれか」を特定するうえで重要です。
strings —— 印字可能な文字列のクイックスキャン(全プラットフォーム)
- Linux:
apt install binutils/dnf install binutils/pacman -S binutils(多くの場合、標準でインストール済み) - macOS:システム標準の /usr/bin/strings
- Windows/WSL:WSL 内では Linux 版を使用します。Windows 本体では Sysinternals の
strings.exeを使用します。 - 確認:
strings --version
動的分析の補助(任意):strace/ltrace/ProcMon
- Linux:
apt install strace ltraceを実行し、strace --versionで確認します。レジストリ(Wine 使用時)/ファイル/API の呼び出しを観察します(詳細は[[re-tracing]]を参照)。 - Windows:Sysinternals Process Monitor(公式サイトから単体 exe をダウンロード。パッケージマネージャーはありません)——レジストリ/ファイル/プロセス/ネットワークの全量トレースに対応します([[re-behavior]]と連携)。レジストリ操作はライセンス情報の読み取りにおける主な経路です。
操作步骤
按顺序执行,每步记录结果(校验点地址 + 证据路径,见 [[re-triage]])。产物:全部校验点清单 + 校验算法,交给 [[re-patching]] / [[re-keygen]]。
-
字符串 / API 交叉引用定位校验函数:
strings -n 5 sample.exe | grep -iE 'register|serial|license|invalid|activation|trial|key' | head -50 strings -el sample.exe | grep -iE 'register|serial|license' | head -20 # UTF-16LE(Windows 常见)- 反编译器里对命中字符串查 xref(Ghidra 右键 Find References / IDA
x/ rizinaxt @ str.*)——看它被哪个函数引用:弹窗/输入框附近的引用函数就是候选校验函数(MessageBox 类"Invalid registration code"、注册对话框、注册表读取RegOpenKeyExW/RegQueryValueExW、GetVolumeInformationW机器码读取) - API 侧:导入表搜
MessageBox/Reg*/GetVolumeInformation/GetSystemTimeAsFileTime,反编译引用函数;Linux 目标用 ltrace 观察strcmp/ 文件读取调用([[re-tracing]]) - 记下每个候选函数的地址与文件名(可能多个校验函数,见坑 3)
- 反编译器里对命中字符串查 xref(Ghidra 右键 Find References / IDA
-
调用图与校验分支(成功 / 失败跳转):
- 反编译校验函数,确认结构:读输入(序列号字符串 / 注册表值)→ 计算 / 比较 → 按结果跳转(
jz/jnz到成功或失败处理)。失败路径特征:MessageBox 报错、置注册标志为假、调用ExitProcess - 找注册标志:全局变量(0/1)在成功路径置 1,功能代码检查它;xref 该标志可找出所有消费它的功能校验点(不只启动校验,见坑 3)
- 动态确认(沙箱内,[[re-analyze/platform-tips]] 最高原则):调试器断在校验函数返回处看返回值与跳转方向——[[re-gdb]]:
break <addr>后si跟跳转;[[re-x64dbg]]:bp <addr>后看标志位 - 产物:每个校验点的 地址 / 调用方 / 成功-失败分支地址 / 注册标志
- 反编译校验函数,确认结构:读输入(序列号字符串 / 注册表值)→ 计算 / 比较 → 按结果跳转(
-
算法还原(对比 / 解密 / 签名验证):
- 对比型:
strcmp/ 逐字节比较 → 序列号与固定值或动态派生值比较,还原派生计算(可能是 [[re-crypto-id]] 的 XOR / 查表 / 简单变换) - 解密型:序列号先解密(XOR / base64 / 自实现)再比对 → 还原解密为生成步骤(XOR 对称可直接逆;查表求逆映射)
- 签名验证型:
RSA_verify/ECC验签 → 算法不可逆,正推生成不可能 → 报告给网关转 [[re-patching]](见坑 4) - 用 [[re-crypto-id]] / [[re-crypto-decrypt]] 思路还原加解密环节;反编译伪代码转成独立脚本验证一遍(对已知合法序列号,程序行为与脚本结果一致)
- 对比型:
-
在线激活 vs 离线校验区分:
- 特征:导入表含网络 API(WinINet
InternetOpen*/WinHttp*/socket)、激活流程有"输入序列号 → 联网 → 返回激活码"、字符串含服务器 URL / "activation failed" - 在线激活:本地只校验响应格式(伪校验),真实验证在服务器 → 转 [[re-protocol]]([[re-netcap]] 沙箱抓包 + [[re-crypto-id]] [[re-crypto-keys]] [[re-crypto-decrypt]] 处理加密);本地侧只处理响应校验与离线回退逻辑
- 离线校验:算法完全在本地,正常走步骤 3 还原
- 区分方法:断网运行(沙箱断网)看激活是否失败/超时([[re-sandbox]] 网络隔离)
- 特征:导入表含网络 API(WinINet
-
机器码绑定识别:
- 搜索导入/调用:
GetVolumeInformationW(卷序列号)、GetComputerNameW、GetUserProfileDirectoryW、Windows 注册表MachineGuid、Linux/etc/machine-id读取 - 确认序列号生成 / 校验输入含机器码:反编译看校验函数是否先读机器码再参与运算
- 绑定确认后:注册机生成逻辑必须含输入(用户名 / 机器码参数化,见 [[re-keygen]] 坑 2);报告里注明"此授权绑定机器码"
- 搜索导入/调用:
-
授权模型识别(处置路线决定):
- 节点锁定(机器绑定):序列号 = f(机器码) → 可逆则 [[re-keygen]] 路线
- 有效期 / 订阅型:校验到期时间 → 时间型校验分支(步骤 7);到期提示字符串("expired"/"trial")xref 定位
- 功能开关型(freemium):校验点散在各功能入口,注册标志多个 → 全量清单必须完整(坑 3)
- 浮动授权(许可证服务器):本地无完整校验 → 转 [[re-protocol]] 分析许可证协议
- 模型判定依据:授权文件 / 注册表项内容(含到期日期字段 = 订阅型;含机器码哈希 = 节点锁定)
-
时间型校验(有效期):
- 时间读取 API:Windows
GetSystemTimeAsFileTime/GetLocalTime,Linuxtime()/gettimeofday——xref 到比较逻辑(> 到期时间) - 反篡改:程序可能记录"上次运行时间"并检测时钟回拨(当前时间 < 上次记录 → 报错)——改动系统时间前先定位该检测点
- 产物:到期时间存储位置(注册表 / 文件)、比较函数地址——补丁或绕过目标
- 时间读取 API:Windows
-
证据核对(收尾):
- 全量校验点清单(地址 / 分支 / 标志 / 证据级别)入档 [[re-analyze/analysis-contract]];结论按证据分级标注(动态确认 vs 静态推断,见 [[decision-tree]])
- 交付:校验点清单 + 算法文档 → [[re-cracking]] 网关统一验证
跨域联合
- [[re-cracking]]:本网关是 re-cracking 工作流第 2 步(授权定位),产物(校验点清单 + 算法)供第 4 / 5 步
- [[re-patching]]:下游——拿到校验点地址后改分支 / 跳过校验
- [[re-keygen]]:下游——拿到校验算法后逆推生成逻辑
- [[re-anti-analysis]]:带壳样本先脱壳(OEP 后再分析);校验函数被混淆先 [[re-deobfuscate]]
- [[re-protocol]]:在线激活 → 抓包分析激活协议(netcap → crypto-id → crypto-keys → crypto-decrypt → proto-rev)
- [[re-binary-core]]:反编译工作台([[re-ghidra]] / [[re-ida]] / [[re-radare2]])
- 动态:[[re-gdb]] / [[re-x64dbg]] / [[re-lldb]](断点看分支返回值)、[[re-tracing]](strace / ltrace 看注册表 / 文件 / API 调用)、[[re-memdump]](内存中的注册标志 / 校验结果)
- [[re-behavior]]:Windows 侧 ProcMon 注册表 / 文件行为 trace 衔接
- [[re-sandbox]]:动态定位与验证沙箱([[re-analyze/platform-tips]] 最高原则)
- [[re-ioc]]:注册相关字符串 / 校验指纹可作 YARA 特征
常见坑与陷阱
- 校验函数被混淆 / 加密:现象——定位到的校验函数反编译全是花指令 / 平坦化 / 字符串密文,看不出比较逻辑;原因——授权校验是重点保护对象,常叠加混淆;对策——先 [[re-deobfuscate]](花指令清除 → 平坦化还原 → 字符串解密)再分析,不要硬啃密文
- 在线激活当离线破解:现象——本地判定分支全改完,程序依然拒绝使用 / 功能锁死;原因——真实验证在服务器端(本地只有响应校验);对策——步骤 4 先区分在线 / 离线(断网测试),在线转 [[re-protocol]] 抓包分析激活协议,本地侧只处理响应校验
- 校验可能多次(启动 + 功能点):现象——启动校验绕过成功,用核心功能时又弹注册;原因——校验点不止一个(启动、功能点、定时器、版本升级检查);对策——步骤 2 遍历校验函数全部 xref / 注册标志的全部消费点,做全量校验点清单(这是 [[re-cracking]] 网关坑 2 的根源)
- 算法不可逆还硬还原:现象——校验含 SHA / MD5 / RSA 验签,序列号生成逻辑无法正推;原因——单向函数;对策——诚实报告不可逆,转 [[re-patching]](跳过验签 / 改分支),不要伪造"还原成功"
- 伪校验误导:现象——改了判定分支程序照常退出 / 无效果;原因——改动点不是真正的授权判定(假分支 / 蜜罐校验,真判定在别处);对策——动态断点确认每个分支真实影响注册标志与程序行为,再进补丁阶段
- 时间型校验漏判:现象——改完所有序列号校验仍提示过期;原因——另有到期时间校验(订阅 / 试用)独立于序列号校验;对策——步骤 7 查时间 API xref 与到期存储位置,纳入全量清单
- 更多决策分支与边界(授权模型判定树 / 证据分级 / 时间篡改反例)见 [[decision-tree]] 与 [[gotchas]]
コメント
Markdown 対応