# Table of Contents - [CrackProof Research](#crackproof-research) - [Welcome! | Home](#welcome-home) - [CrackProof 研究 | CrackProof Research](#crackproof-crackproof-research) - [CrackProof 研究 | CrackProof Research](#crackproof-crackproof-research) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [驗證與參考 | Reference | CrackProof Research](#-reference-crackproof-research) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [bytecode_vm.py | Reference | CrackProof Research](#bytecode-vm-py-reference-crackproof-research) - [huffman.py | Reference | CrackProof Research](#huffman-py-reference-crackproof-research) - [detect.py | Reference | CrackProof Research](#detect-py-reference-crackproof-research) - [Unknown](#unknown) - [aes_impl.py | Reference | CrackProof Research](#aes-impl-py-reference-crackproof-research) - [primitives.py | Reference | CrackProof Research](#primitives-py-reference-crackproof-research) - [Unknown](#unknown) - [Unknown](#unknown) - [vectors.txt | Reference | CrackProof Research](#vectors-txt-reference-crackproof-research) - [Unknown](#unknown) - [vectors.txt | Reference | CrackProof Research](#vectors-txt-reference-crackproof-research) - [Unknown](#unknown) - [Unknown](#unknown) - [验证与参考 | Reference | CrackProof Research](#-reference-crackproof-research) - [調試日誌示例 | Reference | CrackProof Research](#-reference-crackproof-research) - [detect.py | Reference | CrackProof Research](#detect-py-reference-crackproof-research) - [detect.py | Reference | CrackProof Research](#detect-py-reference-crackproof-research) - [Verification & reference | Reference | CrackProof Research](#verification-reference-reference-crackproof-research) - [Sample debug logs | Reference | CrackProof Research](#sample-debug-logs-reference-crackproof-research) - [调试日志示例 | Reference | CrackProof Research](#-reference-crackproof-research) - [huffman.py | Reference | CrackProof Research](#huffman-py-reference-crackproof-research) - [存儲佈局 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [CrackProof for Android SO internals | Android SO | CrackProof Research](#crackproof-for-android-so-internals-android-so-crackproof-research) - [CrackProof for Android SO 內部機制 | Android SO | CrackProof Research](#crackproof-for-android-so-android-so-crackproof-research) - [常量 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [Validation checklist | Android SO | CrackProof Research](#validation-checklist-android-so-crackproof-research) - [Huffman and LZ compression | Android SO | CrackProof Research](#huffman-and-lz-compression-android-so-crackproof-research) - [Constants | Android SO | CrackProof Research](#constants-android-so-crackproof-research) - [常量 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [概覽 | Windows | CrackProof Research](#-windows-crackproof-research) - [第一階段首部 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [加载与节恢复 | Windows | CrackProof Research](#-windows-crackproof-research) - [加載與節恢復 | Windows | CrackProof Research](#-windows-crackproof-research) - [Overview | Windows | CrackProof Research](#overview-windows-crackproof-research) - [Observed limitations | Windows | CrackProof Research](#observed-limitations-windows-crackproof-research) - [Overview | Windows | CrackProof Research](#overview-windows-crackproof-research) - [第一阶段首部 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [PE 重建 | Windows | CrackProof Research](#pe-windows-crackproof-research) - [vectors.txt | Reference | CrackProof Research](#vectors-txt-reference-crackproof-research) - [Overview | Windows | CrackProof Research](#overview-windows-crackproof-research) - [Environment and anti-analysis checks | Windows | CrackProof Research](#environment-and-anti-analysis-checks-windows-crackproof-research) - [Stage 1 header | Android SO | CrackProof Research](#stage-1-header-android-so-crackproof-research) - [概览 | Windows | CrackProof Research](#-windows-crackproof-research) - [PE 重建 | Windows | CrackProof Research](#pe-windows-crackproof-research) - [環境與反分析檢查 | Windows | CrackProof Research](#-windows-crackproof-research) - [结构发现与验证 | Windows | CrackProof Research](#-windows-crackproof-research) - [已观察到的局限 | Windows | CrackProof Research](#-windows-crackproof-research) - [概览 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [概览 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [Overview | Android SO | CrackProof Research](#overview-android-so-crackproof-research) - [概览 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [Dynamic linking | Android SO | CrackProof Research](#dynamic-linking-android-so-crackproof-research) - [Huffman 与 LZ 压缩 | Android SO | CrackProof Research](#huffman-lz-android-so-crackproof-research) - [概覽 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [Overview | Android SO | CrackProof Research](#overview-android-so-crackproof-research) - [Overview | Android SO | CrackProof Research](#overview-android-so-crackproof-research) - [第二阶段记录流 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [Huffman 與 LZ 壓縮 | Android SO | CrackProof Research](#huffman-lz-android-so-crackproof-research) - [概覽 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [概覽 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [概览 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [概覽 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [概覽 | Android SO | CrackProof Research](#-android-so-crackproof-research) - [概览 | Windows | CrackProof Research](#-windows-crackproof-research) - [概览 | Windows | CrackProof Research](#-windows-crackproof-research) - [概覽 | Windows | CrackProof Research](#-windows-crackproof-research) - [概覽 | Windows | CrackProof Research](#-windows-crackproof-research) - [环境与反分析检查 | Windows | CrackProof Research](#-windows-crackproof-research) - [已觀察到的侷限 | Windows | CrackProof Research](#-windows-crackproof-research) - [結構發現與驗證 | Windows | CrackProof Research](#-windows-crackproof-research) - [Loading and section recovery | Windows | CrackProof Research](#loading-and-section-recovery-windows-crackproof-research) - [重定位、頁變換與 CLR 數據 | Windows | CrackProof Research](#-clr-windows-crackproof-research) - [節數據與伴生文件 | Windows | CrackProof Research](#-windows-crackproof-research) - [Overview | Windows | CrackProof Research](#overview-windows-crackproof-research) - [Section data and companion files | Windows | CrackProof Research](#section-data-and-companion-files-windows-crackproof-research) - [重定位、页变换与 CLR 数据 | Windows | CrackProof Research](#-clr-windows-crackproof-research) - [導入、TLS 與導出 | Windows | CrackProof Research](#-tls-windows-crackproof-research) - [CrackProof for Windows internals | Windows | CrackProof Research](#crackproof-for-windows-internals-windows-crackproof-research) - [PE reconstruction | Windows | CrackProof Research](#pe-reconstruction-windows-crackproof-research) - [概覽 | Windows | CrackProof Research](#-windows-crackproof-research) - [Page protection and loader code | Windows | CrackProof Research](#page-protection-and-loader-code-windows-crackproof-research) - [LFSR, string, and page transforms | Windows | CrackProof Research](#lfsr-string-and-page-transforms-windows-crackproof-research) - [页保护与加载器代码 | Windows | CrackProof Research](#-windows-crackproof-research) - [LFSR、字符串與頁變換 | Windows | CrackProof Research](#lfsr-windows-crackproof-research) - [aes_impl.py | Reference | CrackProof Research](#aes-impl-py-reference-crackproof-research) - [节数据与伴生文件 | Windows | CrackProof Research](#-windows-crackproof-research) --- # CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/readme.md) . CrackProof® is a family of commercial binary-protection systems from HyperTech. This site records independently verified details of its file formats, data transforms, loaders, and runtime components. GitBook Assistant The research currently covers Windows PE files and Android native libraries. Each platform has its own container format and restoration path, so their internals are documented separately. GitBook Assistant [](https://xn--ri8h.gitbook.io/crackproof-research/windows) **Windows internals** GitBook Assistant Protected PE layout, transforms, staged loading, PE reconstruction, and runtime behavior. GitBook Assistant [](https://xn--ri8h.gitbook.io/crackproof-research/android-so) **Android SO internals** GitBook Assistant Protected AArch64 ELF layout, module streams, container decoding, ELF restoration, and IL2CPP metadata. GitBook Assistant [](https://xn--ri8h.gitbook.io/crackproof-research/reference) **Verification and reference** GitBook Assistant Executable test vectors and small reference implementations for the documented Windows transforms. GitBook Assistant Research boundaries[](https://xn--ri8h.gitbook.io/crackproof-research#research-boundaries) ------------------------------------------------------------------------------------------- The pages describe observable structures and behavior. Names are taken from binaries, logs, established platform terminology, or a literal description of what a field does. A claim is treated as format behavior only when it survives checks across more than one sample or is supported by an internal consistency rule. GitBook Assistant Protected product names, deployment-specific driver names, and identifying sample details are omitted. Implementation projects used to verify the research are not part of the public terminology. GitBook Assistant Legal notice[](https://xn--ri8h.gitbook.io/crackproof-research#legal-notice) ----------------------------------------------------------------------------- Use this information only with binaries you own or are explicitly authorized to analyze. Laws and license terms governing circumvention vary by jurisdiction. This independent publication contains no vendor source code or keys, is not affiliated with HyperTech, and does not authorize redistribution of restored binaries. GitBook Assistant --- # Welcome! | Home For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/home/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/home/welcome.md) . What are you looking for? --- # CrackProof 研究 | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/home/zh-tw/readme.md) . CrackProof® 是 HyperTech 開發的一系列商用二進制保護系統。本站記錄通過獨立分析驗證的文件格式、數據變換、加載器與運行時組件。 GitBook Assistant 當前研究範圍包括 Windows PE 文件和 Android 原生庫。兩個平臺使用不同的容器格式與恢復路徑，因此分別編寫內部機制文檔。 GitBook Assistant [](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/) **Windows 內部機制** GitBook Assistant 受保護 PE 佈局、數據變換、分階段加載、PE 重建與運行時行為。 GitBook Assistant [](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/) **Android SO 內部機制** GitBook Assistant 受保護 AArch64 ELF 佈局、模塊流、容器解碼、ELF 恢復與 IL2CPP 元數據。 GitBook Assistant [](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/) **驗證與參考** GitBook Assistant 文中 Windows 數據變換的可執行測試向量與小型參考實現。 GitBook Assistant 研究邊界[](https://xn--ri8h.gitbook.io/crackproof-research/home/zh-tw#yan-jiu-bian-jie) ------------------------------------------------------------------------------------ 文檔只描述可觀察的結構與行為。名稱來自二進制、日誌、已有平臺術語，或對字段作用的直白說明。只有經過多個樣本驗證，或能通過內部一致性約束證明的結論，才會寫成格式行為。 GitBook Assistant 文檔不記錄受保護產品名稱、部署專用驅動名和可識別樣本的信息。用於驗證研究結論的實現項目名稱不作為公開術語。 GitBook Assistant 法律聲明[](https://xn--ri8h.gitbook.io/crackproof-research/home/zh-tw#falsheng-ming) --------------------------------------------------------------------------------- 僅可將這些信息用於您擁有或已獲明確授權分析的二進制。各司法轄區的規避限制與許可條款不同。本文檔是獨立研究成果，不包含廠商源代碼或密鑰，與 HyperTech 無隸屬關係，也不授權再分發恢復後的二進制。 GitBook Assistant --- # CrackProof 研究 | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/home/zh-cn/readme.md) . CrackProof® 是 HyperTech 开发的一系列商用二进制保护系统。本站记录通过独立分析验证的文件格式、数据变换、加载器与运行时组件。 GitBook Assistant 当前研究范围包括 Windows PE 文件和 Android 原生库。两个平台使用不同的容器格式与恢复路径，因此分别编写内部机制文档。 GitBook Assistant [](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn) **Windows 内部机制** GitBook Assistant 受保护 PE 布局、数据变换、分阶段加载、PE 重建与运行时行为。 GitBook Assistant [](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn) **Android SO 内部机制** GitBook Assistant 受保护 AArch64 ELF 布局、模块流、容器解码、ELF 恢复与 IL2CPP 元数据。 GitBook Assistant [](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn) **验证与参考** GitBook Assistant 文中 Windows 数据变换的可执行测试向量与小型参考实现。 GitBook Assistant 研究边界[](https://xn--ri8h.gitbook.io/crackproof-research/home/zh-cn#yan-jiu-bian-jie) ------------------------------------------------------------------------------------ 文档只描述可观察的结构与行为。名称来自二进制、日志、已有平台术语，或对字段作用的直白说明。只有经过多个样本验证，或能通过内部一致性约束证明的结论，才会写成格式行为。 GitBook Assistant 文档不记录受保护产品名称、部署专用驱动名和可识别样本的信息。用于验证研究结论的实现项目名称不作为公开术语。 GitBook Assistant 法律声明[](https://xn--ri8h.gitbook.io/crackproof-research/home/zh-cn#falsheng-ming) --------------------------------------------------------------------------------- 仅可将这些信息用于您拥有或已获明确授权分析的二进制。各司法辖区的规避限制与许可条款不同。本文档是独立研究成果，不包含厂商源代码或密钥，与 HyperTech 无隶属关系，也不授权再分发恢复后的二进制。 GitBook Assistant --- # Unknown \# Home ## Home - \[Welcome!\](https://xn--ri8h.gitbook.io/home/welcome.md) --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://xn--ri8h.gitbook.io/home/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://xn--ri8h.gitbook.io/home/welcome.md). # Welcome! What are you looking for? --- # Unknown \# CrackProof Research ## Home - \[CrackProof Research\](https://xn--ri8h.gitbook.io/crackproof-research/readme.md): Independent technical research into CrackProof protection formats and runtime behavior. ## Windows - \[CrackProof for Windows internals\](https://xn--ri8h.gitbook.io/crackproof-research/windows/readme.md): Internal structures and runtime behavior of CrackProof-protected Windows PE files. - \[Overview\](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/file-format.md): How protected Windows files are laid out, recognized, and divided between a stub and optional companion data. - \[Container and encrypted header\](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/container-layout.md): The Windows container layout, encrypted info header, and the values derived from it. - \[Recognition and build families\](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/recognition.md): Structural checks that distinguish protected PE files and the layouts observed across build families. - \[Section data and companion files\](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/companion-layout.md): How section payloads are located and how stub executables refer to external companion files. - \[Overview\](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/data-transforms.md): The reversible data transforms used across Windows headers, loader stages, names, sections, and code pages. - \[Rolling-key and rotation ciphers\](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/rolling-and-rotation.md): The rolling XOR, dword rotation, and byte rotation transforms used by Windows payload stages. - \[LFSR, string, and page transforms\](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/lfsr-strings-pages.md): The LFSR stream, import-name cipher, and sparse per-page code transform. - \[Checksums and key progression\](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/checksums.md): CRC-32, triangular key progression, and the checksum chain that links protected records. - \[AES-CBC layer\](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/aes.md): The AES-CBC layer and its in-buffer expanded key schedule. - \[Huffman and LZ compression\](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/compression.md): The combined Huffman and LZ stream format used for compressed section records. - \[Per-build byte transform\](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/bytecode-transform.md): The compact instruction stream that defines a build-specific byte permutation. - \[Loading and section recovery\](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/loading.md): How encrypted loader stages are found, decoded, and used to recover protected Windows sections. - \[Stage chain and marker layout\](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/loading/stage-chain.md): The common stage-decrypt pattern and the marker-based 64-bit loader sequence. - \[PE32, DLL, and marker-less layouts\](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/loading/layout-variants.md): How the 32-bit, older DLL, and newer marker-less loader layouts differ. - \[Structural discovery and validation\](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/loading/discovery-validation.md): Why loader structures are discovered by shape and how false candidates are rejected. - \[PE reconstruction\](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction.md): How a recovered memory image is turned back into a coherent PE file. - \[Headers, sections, and zero-fill ranges\](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction/memory-image.md): How protected section headers describe a memory image and which PE fields are restored. - \[Imports, TLS, and exports\](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction/imports-tls-exports.md): How import names, TLS state, and exported data are recovered from different protected layouts. - \[Relocations, page transforms, and CLR data\](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction/relocations-managed.md): Relocation policy, the final page transform, and the special handling required for managed images. - \[Overview\](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/runtime.md): What the Windows loader checks and changes at runtime before and after the original program starts. - \[Startup sequence and status reporting\](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/startup-status.md): The runtime boot sequence, status values, and diagnostic logging left by protected binaries. - \[Environment and anti-analysis checks\](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/environment-checks.md): User-mode and kernel-assisted checks performed before control reaches the original program. - \[Page protection and loader code\](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/page-protection.md): On-demand page decryption, loader-code variation, decoys, and self-loading behavior. - \[Manually mapped helper modules\](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/mapped-modules.md): The helper-module roles embedded in the loader and mapped without the normal Windows loader. - \[Htsysm kernel components\](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/kernel-components.md): The observed Htsysm generations, their kernel responsibilities, and their version stamp. - \[Overview\](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/analysis.md): Methods, validation criteria, known limitations, metadata behavior, and quick-reference values. - \[Analysis workflow\](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/workflow.md): A repeatable workflow for locating stages, interpreting logs, and checking reconstructed images. - \[Observed limitations\](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/observed-limitations.md): Weaknesses and failure modes observed in specific protection mechanisms and build families. - \[il2cpp metadata obfuscation\](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/il2cpp-metadata.md): The optional -GMD method-token obfuscation applied to Unity il2cpp titles' global-metadata.dat. - \[Constants and offsets\](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/constants.md): Quick-reference tables of constants, offsets, and encodings used across the format, loader, and runtime. ## Android SO - \[CrackProof for Android SO internals\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/readme.md): Internal structures and recovery behavior of CrackProof-protected Android native libraries. - \[Overview\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/file-format.md): Recognize a protected ELF and follow its outer and inner stream boundaries. - \[Protected ELF\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/protected-elf.md): ELF properties and private-section facts used to identify protected Android libraries. - \[Stage 1 header\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/stage1.md): Decode and validate the fixed-size outer header before reading the payload. - \[Stage 2 streams\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/stage2-streams.md): Follow the stage 2 record stream and its nested direct records. - \[Overview\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/data-transforms/data-transforms.md): The arithmetic, module, container, and compression layers used by Android streams. - \[Module configuration\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/data-transforms/module-config.md): Fields supplied by the configuration module to later stream decoders. - \[Container transforms\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/data-transforms/container.md): Decode container descriptors, segment transforms, and raw or compressed writes. - \[Huffman and LZ compression\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/data-transforms/compression.md): The Huffman and LZ writer format and the checks needed for safe expansion. - \[Overview\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/restoration/restoration.md): Reassemble image bytes, dynamic-linking data, and the final ELF layout. - \[Module streams\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/restoration/module-streams.md): Dispatch nested records and apply the required Android decoder modules. - \[Dynamic linking\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/restoration/dynamic-linking.md): Rebuild dynamic symbols, version tables, and relocation records from protected streams. - \[ELF output\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/restoration/elf-output.md): Validate the rebuilt ELF image, program layout, and removal of protection-only data. - \[Overview\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/metadata/metadata.md): IL2CPP metadata signatures, method-token ranges, and storage variants. - \[Method tokens\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/metadata/method-tokens.md): Identify IL2CPP metadata version 31 and validate per-image method ranges. - \[Storage layouts\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/metadata/storage-layouts.md): Distinguish external and embedded IL2CPP metadata without changing its logical format. - \[Overview\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/analysis/analysis.md): Evidence-based checks for recognizing, restoring, and rejecting Android candidates. - \[Validation checklist\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/analysis/validation.md): A compact validation checklist for protected Android native libraries. - \[Constants\](https://xn--ri8h.gitbook.io/crackproof-research/android-so/analysis/constants.md): Observed Android format constants and the scope in which each is valid. ## Reference - \[Verification & reference\](https://xn--ri8h.gitbook.io/crackproof-research/reference/readme.md): Runnable snippet verification and desensitized reference material from protected binaries. - \[primitives.py\](https://xn--ri8h.gitbook.io/crackproof-research/reference/primitives.py.md): Rolling, rotation, LFSR, string, page, CRC-32, checksum, and key-schedule reference code. - \[aes\\\_impl.py\](https://xn--ri8h.gitbook.io/crackproof-research/reference/aes\_impl.py.md): AES decryption in CBC mode with an in-buffer key schedule; T-tables generated from GF(2^8) arithmetic. - \[huffman.py\](https://xn--ri8h.gitbook.io/crackproof-research/reference/huffman.py.md): The Huffman/LZ hybrid decompressor: 3-byte table entries, literal/run-fill/back-reference tokens. - \[bytecode\\\_vm.py\](https://xn--ri8h.gitbook.io/crackproof-research/reference/bytecode\_vm.py.md): The per-build custom byte transform: x86 stub decoder, interpreter, translation table, and inverse chain. - \[detect.py\](https://xn--ri8h.gitbook.io/crackproof-research/reference/detect.py.md): Content-based detection and classification of protected files (KONN magic, native/managed EXE and DLL). - \[run\\\_tests.py\](https://xn--ri8h.gitbook.io/crackproof-research/reference/run\_tests.py.md): The comparison harness: replays every scenario in Python and compares byte-for-byte with the reference vectors. - \[rust\\\_vectors.rs\](https://xn--ri8h.gitbook.io/crackproof-research/reference/rust\_vectors.rs.md): The independent reference port of the algorithms; compiles to a program that prints ground-truth vectors. - \[vectors.txt\](https://xn--ri8h.gitbook.io/crackproof-research/reference/vectors.txt.md): The 30 ground-truth vectors printed by the reference port, which run\\\_tests.py compares against. - \[Sample debug logs\](https://xn--ri8h.gitbook.io/crackproof-research/reference/sample-debug-logs.md): Desensitized debug logs from protected host, native DLL, and managed DLL samples. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on a page URL with the \`ask\` query parameter: \`\`\` GET https://xn--ri8h.gitbook.io/crackproof-research/readme.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # 驗證與參考 | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/readme.md) . 本欄目以完整、可運行的形式發佈 [CrackProof 內部機制](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/) 背後的參考材料。 GitBook Assistant 驗證套件[](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw#yan-zheng-tao-jian) ------------------------------------------------------------------------------------------- 主文檔中的每個 Python 片段在發佈前都經過驗證：每個函數的輸出在相同輸入上與算法的獨立參考移植逐字節比對。完整套件——每個文件一頁： GitBook Assistant 文件 作用 `primitives.py` GitBook Assistant 滾動密鑰密碼、字節旋轉、LFSR、字符串密碼、頁置亂、CRC-32、校驗和、三角調度 GitBook Assistant `aes_impl.py` GitBook Assistant 帶緩衝區內置密鑰調度的 AES-CBC 解密 GitBook Assistant `huffman.py` GitBook Assistant Huffman/LZ 混合解壓器 GitBook Assistant `bytecode_vm.py` GitBook Assistant 逐構建字節碼樁解碼器/解釋器及其逆變換 GitBook Assistant `detect.py` GitBook Assistant 基於內容的識別與分類 GitBook Assistant `run_tests.py` GitBook Assistant 比對工具（30 個向量） GitBook Assistant `rust_vectors.rs` GitBook Assistant 打印基準真值的獨立參考移植 GitBook Assistant `vectors.txt` GitBook Assistant 比對工具所對照的期望輸出 GitBook Assistant 要重跑全部比對，下載這些文件並執行 `python run_tests.py`。預期結果：`all vectors match`。 GitBook Assistant 參考捕獲[](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw#can-kao-bu-huo) --------------------------------------------------------------------------------------- 調試日誌示例——從受保護進程捕獲的真實 CrackProof 調試日誌，已脫敏：一個功能完整的宿主 EXE（頁加密）、一個原生插件 DLL（僅整體解密）與一個託管 DLL。 GitBook Assistant [下一頁primitives.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/primitives.py) 最後更新於 20 小時前 * [驗證套件](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw#yan-zheng-tao-jian) * [參考捕獲](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw#can-kao-bu-huo) --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://xn--ri8h.gitbook.io/crackproof-research/home/zh-tw/readme.md). # CrackProof 研究 CrackProof® 是 HyperTech 開發的一系列商用二進制保護系統。本站記錄通過獨立分析驗證的文件格式、數據變換、加載器與運行時組件。 當前研究範圍包括 Windows PE 文件和 Android 原生庫。兩個平臺使用不同的容器格式與恢復路徑，因此分別編寫內部機制文檔。 | | | | | --- | --- | --- | | **Windows 內部機制** | 受保護 PE 佈局、數據變換、分階段加載、PE 重建與運行時行為。 | [/spaces/sFi4W2Zr1UBoxZd5YI3A](https://xn--ri8h.gitbook.io/spaces/sFi4W2Zr1UBoxZd5YI3A) | | **Android SO 內部機制** | 受保護 AArch64 ELF 佈局、模塊流、容器解碼、ELF 恢復與 IL2CPP 元數據。 | [/spaces/HezwIJwx0lhm5CUG7g8R](https://xn--ri8h.gitbook.io/spaces/HezwIJwx0lhm5CUG7g8R) | | **驗證與參考** | 文中 Windows 數據變換的可執行測試向量與小型參考實現。 | [/spaces/2p7kzW649ZlKfmpYdJ87](https://xn--ri8h.gitbook.io/spaces/2p7kzW649ZlKfmpYdJ87) | \## 研究邊界 文檔只描述可觀察的結構與行為。名稱來自二進制、日誌、已有平臺術語，或對字段作用的直白說明。只有經過多個樣本驗證，或能通過內部一致性約束證明的結論，才會寫成格式行為。 文檔不記錄受保護產品名稱、部署專用驅動名和可識別樣本的信息。用於驗證研究結論的實現項目名稱不作為公開術語。 ## 法律聲明 僅可將這些信息用於您擁有或已獲明確授權分析的二進制。各司法轄區的規避限制與許可條款不同。本文檔是獨立研究成果，不包含廠商源代碼或密鑰，與 HyperTech 無隸屬關係，也不授權再分發恢復後的二進制。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://xn--ri8h.gitbook.io/crackproof-research/home/zh-tw/readme.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://xn--ri8h.gitbook.io/crackproof-research/home/zh-cn/readme.md). # CrackProof 研究 CrackProof® 是 HyperTech 开发的一系列商用二进制保护系统。本站记录通过独立分析验证的文件格式、数据变换、加载器与运行时组件。 当前研究范围包括 Windows PE 文件和 Android 原生库。两个平台使用不同的容器格式与恢复路径，因此分别编写内部机制文档。 | | | | | --- | --- | --- | | **Windows 内部机制** | 受保护 PE 布局、数据变换、分阶段加载、PE 重建与运行时行为。 | [/spaces/fEb9nKPvKsjkPAHMUbOt/pages/leX4uGGSEZGSSwclOXy8](https://xn--ri8h.gitbook.io/spaces/fEb9nKPvKsjkPAHMUbOt/pages/leX4uGGSEZGSSwclOXy8) | | **Android SO 内部机制** | 受保护 AArch64 ELF 布局、模块流、容器解码、ELF 恢复与 IL2CPP 元数据。 | [/spaces/Aoyn9wKiHAVzBKGSUifa/pages/M9IZYnz1nxsxRFF8ueKA](https://xn--ri8h.gitbook.io/spaces/Aoyn9wKiHAVzBKGSUifa/pages/M9IZYnz1nxsxRFF8ueKA) | | **验证与参考** | 文中 Windows 数据变换的可执行测试向量与小型参考实现。 | [/spaces/L9bXLua8yrIPEUZOHO21/pages/zWysJGTW9cHMDOSsVJkC](https://xn--ri8h.gitbook.io/spaces/L9bXLua8yrIPEUZOHO21/pages/zWysJGTW9cHMDOSsVJkC) | \## 研究边界 文档只描述可观察的结构与行为。名称来自二进制、日志、已有平台术语，或对字段作用的直白说明。只有经过多个样本验证，或能通过内部一致性约束证明的结论，才会写成格式行为。 文档不记录受保护产品名称、部署专用驱动名和可识别样本的信息。用于验证研究结论的实现项目名称不作为公开术语。 ## 法律声明 仅可将这些信息用于您拥有或已获明确授权分析的二进制。各司法辖区的规避限制与许可条款不同。本文档是独立研究成果，不包含厂商源代码或密钥，与 HyperTech 无隶属关系，也不授权再分发恢复后的二进制。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://xn--ri8h.gitbook.io/crackproof-research/home/zh-cn/readme.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://xn--ri8h.gitbook.io/crackproof-research/readme.md). # CrackProof Research CrackProof® is a family of commercial binary-protection systems from HyperTech. This site records independently verified details of its file formats, data transforms, loaders, and runtime components. The research currently covers Windows PE files and Android native libraries. Each platform has its own container format and restoration path, so their internals are documented separately. | | | | | --- | --- | --- | | **Windows internals** | Protected PE layout, transforms, staged loading, PE reconstruction, and runtime behavior. | [/spaces/PuKTEy2soDgSB3qfWACy/pages/5XgJwTj7wXhGAL8EID9N](https://xn--ri8h.gitbook.io/spaces/PuKTEy2soDgSB3qfWACy/pages/5XgJwTj7wXhGAL8EID9N) | | **Android SO internals** | Protected AArch64 ELF layout, module streams, container decoding, ELF restoration, and IL2CPP metadata. | [/spaces/fcBZibCo72OSh5jVcKoo/pages/vUn8pXP1LuwzQtfEohsX](https://xn--ri8h.gitbook.io/spaces/fcBZibCo72OSh5jVcKoo/pages/vUn8pXP1LuwzQtfEohsX) | | **Verification and reference** | Executable test vectors and small reference implementations for the documented Windows transforms. | [/spaces/8S0xnfw9UP9A2yylicaA/pages/qMcHS1SyAeHk8UKNkmMJ](https://xn--ri8h.gitbook.io/spaces/8S0xnfw9UP9A2yylicaA/pages/qMcHS1SyAeHk8UKNkmMJ) | \## Research boundaries The pages describe observable structures and behavior. Names are taken from binaries, logs, established platform terminology, or a literal description of what a field does. A claim is treated as format behavior only when it survives checks across more than one sample or is supported by an internal consistency rule. Protected product names, deployment-specific driver names, and identifying sample details are omitted. Implementation projects used to verify the research are not part of the public terminology. ## Legal notice Use this information only with binaries you own or are explicitly authorized to analyze. Laws and license terms governing circumvention vary by jurisdiction. This independent publication contains no vendor source code or keys, is not affiliated with HyperTech, and does not authorize redistribution of restored binaries. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://xn--ri8h.gitbook.io/crackproof-research/readme.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # bytecode_vm.py | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/bytecode_vm.py.md) . 解碼每個構建獨有 x86 樁的字節碼 VM，見 [字節碼變換](https://app.gitbook.com/s/sFi4W2Zr1UBoxZd5YI3A/shu-ju-bian-huan/bytecode-transform) 。 GitBook Assistant GitBook Assistant詢問複製 """The per-build custom byte transform ("bytecode VM"). Each protected build generates a unique x86 stub: it takes one byte in AL, applies a short sequence of arithmetic/rotate instructions, and returns. The loader runs this stub over every payload byte between the block-cipher pass and decompression. Instead of executing x86, the instruction bytes are decoded into a tiny op list and interpreted. Every op is reversible (add/sub, xor, rol/ror, inc/dec), so the whole chain is a permutation of the 256 byte values and can be precomputed as a 256-entry translation table. Only a narrow instruction subset ever appears; anything else fails the parse, which is what makes trial-decoding candidate locations reliable. """ # Opcode map: x86 encoding -> VM operation. # 04 ib ADD AL, imm8 ("add", imm) # 2C ib SUB AL, imm8 ("sub", imm) # 34 ib XOR AL, imm8 ("xor", imm) # 90 NOP (skipped) # C0 /0 ib ROL AL, imm8 ("rol", imm) # C0 /1 ib ROR AL, imm8 ("ror", imm) # FE /0 INC AL ("inc",) # FE /1 DEC AL ("dec",) # C3 RET end of program # # For C0/FE the ModR/M byte must encode register-direct AL (mod=3, rm=0); # the reg field selects the sub-operation. def generate(data, offset=0): """Decode the stub at `offset` into an op list, or return None if the byte stream is not a valid stub (must terminate in RET).""" pos = offset ops = [] def take(): nonlocal pos if pos >= len(data): return None b = data[pos] pos += 1 return b while True: op = take() if op is None: return None if op == 0x04: # ADD AL, imm8 imm = take() if imm is None: return None ops.append(("add", imm)) elif op == 0x2C: # SUB AL, imm8 imm = take() if imm is None: return None ops.append(("sub", imm)) elif op == 0x34: # XOR AL, imm8 imm = take() if imm is None: return None ops.append(("xor", imm)) elif op == 0x90: # NOP pass elif op in (0xC0, 0xFE): modrm = take() if modrm is None: return None mod, reg, rm = modrm >> 6, (modrm >> 3) & 7, modrm & 7 if mod != 3 or rm != 0 or reg > 1: return None if op == 0xC0: # ROL/ROR AL, imm8 imm = take() if imm is None: return None ops.append(("rol" if reg == 0 else "ror", imm)) else: # INC/DEC AL ops.append(("inc" if reg == 0 else "dec",)) elif op == 0xC3: # RET return ops else: return None def apply_ops(ops, x): """Run an op chain over a single byte.""" for op in ops: name = op[0] if name == "add": x = (x + op[1]) & 0xFF elif name == "sub": x = (x - op[1]) & 0xFF elif name == "xor": x ^= op[1] elif name == "rol": n = op[1] & 7 x = ((x << n) | (x >> (8 - n))) & 0xFF elif name == "ror": n = op[1] & 7 x = ((x >> n) | (x << (8 - n))) & 0xFF elif name == "inc": x = (x + 1) & 0xFF elif name == "dec": x = (x - 1) & 0xFF return x def build_translation_table(ops): """The op chain is a pure function of one byte, so precompute all 256 results once and translate whole regions by table lookup.""" return bytes(apply_ops(ops, i) for i in range(256)) def inverse_ops(ops): """Reverse the chain: walk backwards, swapping each op for its inverse. (Documents why the transform is a permutation - it can always be undone.)""" inverse = {"add": "sub", "sub": "add", "xor": "xor", "rol": "ror", "ror": "rol", "inc": "dec", "dec": "inc"} return [(inverse[op[0]], *op[1:]) for op in reversed(ops)] [上一頁huffman.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/huffman.py) [下一頁detect.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/detect.py) 最後更新於 20 小時前 --- # huffman.py | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/huffman.py.md) . 用於 stage 與節數據塊的解壓器，見 [Huffman 與 LZ 壓縮](https://app.gitbook.com/s/sFi4W2Zr1UBoxZd5YI3A/shu-ju-bian-huan/compression) 。 GitBook Assistant GitBook Assistant詢問複製 """The Huffman/LZ hybrid decompressor. Compressed blocks carry their own decoding table at `key_offset` in the same buffer. The table is a forest of 3-byte entries: +0 u16 symbol / child index +2 u8 accumulated code length in bits Root selection reads 8 bits (entry index = next 8 bits of input). An entry with the top bit (0x8000) set is a leaf: the low 15 bits are the token. A clear top bit means an internal node: the low 15 bits are the index of the first of a sibling pair, and one more input bit picks between them. The stored length byte counts the bits consumed so far (8 for a root), so a leaf reached after walking N internal levels has a total code length of 8 + N bits. Each token has a mode in its bits 8-9 and a payload in bits 0-7: 0x000 literal: emit the payload byte 0x100 count accumulator: append the payload to a big-endian pending value (emits nothing by itself) 0x200 run fill: repeat the previously written 1/2/4-byte unit pending * payload times 0x300 LZ back-reference: copy `payload` bytes from (pending + payload) bytes behind the output cursor """ def get_u16(d, off): return d[off] | (d[off + 1] << 8) def get_u32(d, off): return d[off] | (d[off + 1] << 8) | (d[off + 2] << 16) | (d[off + 3] << 24) def put_u16(d, off, value): d[off:off + 2] = (value & 0xFFFF).to_bytes(2, "little") def put_u32(d, off, value): d[off:off + 4] = (value & 0xFFFFFFFF).to_bytes(4, "little") def decompress(d, src, dest, key_offset, s_size, d_size): """Decompress s_size bytes at `src` into d_size bytes at `dest`, in place within buffer `d`. Returns True when exactly d_size bytes were produced.""" bit_pos = 0 buf = bytearray(d[src:src + s_size]) + bytearray(3) # 3 bytes of slack buf_off = 0 src_consumed = 0 pending = 0 written = 0 while src_consumed < s_size and written < d_size: word = get_u32(buf, buf_off) >> bit_pos tab_addr = key_offset + (word & 0xFF) * 3 tab = get_u16(d, tab_addr) if tab & 0x8000: # leaf: token is in the low 15 bits tab &= 0x7FFF bits = d[tab_addr + 2] else: # internal node: walk down one bit per level bits = d[tab_addr + 2] if bits >= 32: return False mask = 1 << bits bits += 1 idx = (tab & 0x7FFF) + (1 if word & mask else 0) t2 = get_u16(d, key_offset + idx * 3) depth = 0 while not (t2 & 0x8000): depth += 1 if depth > 64: return False mask <<= 1 bits += 1 idx = (t2 & 0x7FFF) + (1 if word & mask else 0) t2 = get_u16(d, key_offset + idx * 3) tab = t2 & 0x7FFF bit_pos += bits advance = bit_pos // 8 buf_off += advance src_consumed += advance bit_pos %= 8 mode = tab & 0x300 payload = tab & 0xFF if mode == 0x000: # literal step = 1 d[dest] = payload elif mode == 0x100: # count accumulator step = 0 if pending >= 256: return False pending = payload if pending == 0 else (pending << 8) | payload elif mode == 0x200: # run fill if pending == 0: pending = 1 step = pending * payload if step + written > d_size: return False if payload == 1: if dest < 1: return False v = d[dest - 1] for k in range(pending): d[dest + k] = v elif payload == 2: if dest < 2: return False v = get_u16(d, dest - 2) for k in range(pending): put_u16(d, dest + k * 2, v) elif payload == 4: if dest < 4: return False v = get_u32(d, dest - 4) for k in range(pending): put_u32(d, dest + k * 4, v) else: return False pending = 0 else: # 0x300: LZ back-reference step = payload if written + payload > d_size or pending + payload > written: return False back = pending + payload for k in range(payload): d[dest + k] = d[dest + k - back] pending = 0 dest += step written += step if bits == 0 and step == 0: return False return written == d_size [上一頁aes\_impl.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/aes_impl.py) [下一頁bytecode\_vm.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/bytecode_vm.py) 最後更新於 20 小時前 --- # detect.py | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/detect.py.md) . [識別與構建家族](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/file-structure/recognition) 中記載的識別與分類邏輯。 GitBook Assistant GitBook Assistant詢問複製 """Content-based detection and classification of a protected PE file. A protected file is recognized by content, never by name or extension: derive the 8-dword info table from offset 4096 and check the magic in info[1]. The PE header stays plaintext, so the usual PE fields classify the file further. """ MAGIC_KONN = 0x4E4E4F4B # the shell stamp def get_u16(d, off): return d[off] | (d[off + 1] << 8) def get_u32(d, off): return d[off] | (d[off + 1] << 8) | (d[off + 2] << 16) | (d[off + 3] << 24) def header_kdf(file_data, offset=4096): info = [0] * 8 info[0] = get_u32(file_data, offset) k = info[0] for i in range(7): cell = get_u32(file_data, offset + 4 + 4 * i) info[i + 1] = k ^ cell k = (i * i) ^ ((k + cell - i) & 0xFFFFFFFF) return info def detect(file_data): """Return ("native-exe" | "managed-exe" | "native-dll" | "managed-dll", magic) for a protected file, or None when the file is not protected by this scheme.""" if len(file_data) < 4128: return None pe_off = get_u32(file_data, 0x3C) if file_data[pe_off:pe_off + 4] != b"PE\0\0": return None info = header_kdf(file_data) if info[1] != MAGIC_KONN: return None characteristics = get_u16(file_data, pe_off + 4 + 18) # IMAGE_FILE_HEADER is_dll = bool(characteristics & 0x2000) # IMAGE_FILE_DLL # COM descriptor (CLR) data directory: managed vs native, EXE and DLL alike. # Data directories start at optional-header +96 on PE32, +112 on PE32+. opt_magic = get_u16(file_data, pe_off + 24) # 0x10B / 0x20B dd_base = 112 if opt_magic == 0x20B else 96 clr_rva = get_u32(file_data, pe_off + 24 + dd_base + 14 * 8) managed = bool(clr_rva) if is_dll: return ("managed-dll" if managed else "native-dll", info[1]) return ("managed-exe" if managed else "native-exe", info[1]) [上一頁bytecode\_vm.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/bytecode_vm.py) [下一頁run\_tests.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/run_tests.py) 最後更新於 20 小時前 --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/readme.md). # 驗證與參考 本欄目以完整、可運行的形式發佈 \[CrackProof 內部機制\](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/)背後的參考材料。 ## 驗證套件 主文檔中的每個 Python 片段在發佈前都經過驗證：每個函數的輸出在相同輸入上與算法的獨立參考移植逐字節比對。完整套件——每個文件一頁： | 文件 | 作用 | | ----------------- | ------------------------------------------ | | \`primitives.py\` | 滾動密鑰密碼、字節旋轉、LFSR、字符串密碼、頁置亂、CRC-32、校驗和、三角調度 | | \`aes\_impl.py\` | 帶緩衝區內置密鑰調度的 AES-CBC 解密 | | \`huffman.py\` | Huffman/LZ 混合解壓器 | | \`bytecode\_vm.py\` | 逐構建字節碼樁解碼器/解釋器及其逆變換 | | \`detect.py\` | 基於內容的識別與分類 | | \`run\_tests.py\` | 比對工具（30 個向量） | | \`rust\_vectors.rs\` | 打印基準真值的獨立參考移植 | | \`vectors.txt\` | 比對工具所對照的期望輸出 | 要重跑全部比對，下載這些文件並執行 \`python run\_tests.py\`。預期結果：\`all vectors match\`。 ## 參考捕獲 調試日誌示例——從受保護進程捕獲的真實 CrackProof 調試日誌，已脫敏：一個功能完整的宿主 EXE（頁加密）、一個原生插件 DLL（僅整體解密）與一個託管 DLL。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/readme.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # aes_impl.py | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/aes_impl.py.md) . 分組密碼：AES-CBC 解密，密鑰調度嵌入數據緩衝區，見 [AES 變換](https://app.gitbook.com/s/sFi4W2Zr1UBoxZd5YI3A/shu-ju-bian-huan/aes) 。 GitBook Assistant GitBook Assistant詢問複製 """The block cipher: AES decryption in CBC mode with an in-buffer key schedule. The loader embeds the expanded key schedule inside the same buffer as the ciphertext: a small header at `key_offset` (the round count as a little-endian u16 at key_offset+2) followed by (rounds+1) 16-byte round keys. Decryption runs in 16-byte blocks; each block is XORed with the previous ciphertext block (CBC chaining, zero IV). The five lookup tables are the standard AES *decryption* T-tables (InvSubBytes fused with InvMixColumns), generated below from GF(2^8) arithmetic - they are public AES constants, not proprietary data. """ MASK32 = 0xFFFFFFFF def get_u16(d, off): return d[off] | (d[off + 1] << 8) def get_u32(d, off): return d[off] | (d[off + 1] << 8) | (d[off + 2] << 16) | (d[off + 3] << 24) # --- table generation ------------------------------------------------------- def _gf_mul(a, b): """Multiply in GF(2^8) with the AES reduction polynomial.""" p = 0 for _ in range(8): if b & 1: p ^= a hi = a & 0x80 a = (a << 1) & 0xFF if hi: a ^= 0x1B b >>= 1 return p def _inverse_sbox(): inv = [0] * 256 for a in range(1, 256): for b in range(1, 256): if _gf_mul(a, b) == 1: inv[a] = b break fwd = [0] * 256 for i in range(256): x = s = inv[i] for _ in range(4): s = ((s << 1) | (s >> 7)) & 0xFF x ^= s fwd[i] = x ^ 0x63 isb = [0] * 256 for i in range(256): isb[fwd[i]] = i return isb def _build_tables(): """Each table has 256 u32 entries. SBOX broadcasts invsbox(x) to all four lanes; COLUMMIX1 holds [0x0b*s, 0x0d*s, 0x09*s, 0x0e*s] and COLUMMIX2/3/4 are its one-, two- and three-byte rotations.""" isb = _inverse_sbox() sbox = bytearray(1024) cm = [bytearray(1024) for _ in range(4)] for x in range(256): s = isb[x] lanes = [_gf_mul(0x0B, s), _gf_mul(0x0D, s), _gf_mul(0x09, s), _gf_mul(0x0E, s)] for j in range(4): sbox[x * 4 + j] = s for t in range(4): cm[t][x * 4 + j] = lanes[(j + t) % 4] return sbox, cm _SBOX, _CM = _build_tables() # --- decryption ------------------------------------------------------------- def _aes_round(d, pos, key_offset, rounds): """Decrypt one 16-byte block in place. The state words are loaded and stored big-endian; the round keys are read from the same buffer.""" n = [int.from_bytes(d[pos + 4 * i:pos + 4 * i + 4], "big")\ ^ get_u32(d, key_offset + 4 * i) for i in range(4)] # Middle rounds: InvSubBytes + InvShiftRows + InvMixColumns, fused into # four T-table lookups per state word, plus the round key. for r in range(1, rounds): off = key_offset + r * 16 n = [\ get_u32(_CM[1], ((n[3] >> 16) & 0xFF) * 4) ^ get_u32(_CM[2], ((n[2] >> 8) & 0xFF) * 4)\ ^ get_u32(_CM[0], (n[0] >> 24) * 4) ^ get_u32(_CM[3], (n[1] & 0xFF) * 4) ^ get_u32(d, off),\ get_u32(_CM[1], ((n[0] >> 16) & 0xFF) * 4) ^ get_u32(_CM[0], (n[1] >> 24) * 4)\ ^ get_u32(_CM[2], ((n[3] >> 8) & 0xFF) * 4) ^ get_u32(_CM[3], (n[2] & 0xFF) * 4) ^ get_u32(d, off + 4),\ get_u32(_CM[1], ((n[1] >> 16) & 0xFF) * 4) ^ get_u32(_CM[2], ((n[0] >> 8) & 0xFF) * 4)\ ^ get_u32(_CM[0], (n[2] >> 24) * 4) ^ get_u32(_CM[3], (n[3] & 0xFF) * 4) ^ get_u32(d, off + 8),\ get_u32(_CM[2], ((n[1] >> 8) & 0xFF) * 4) ^ get_u32(_CM[1], ((n[2] >> 16) & 0xFF) * 4)\ ^ get_u32(_CM[0], (n[3] >> 24) * 4) ^ get_u32(_CM[3], (n[0] & 0xFF) * 4) ^ get_u32(d, off + 12),\ ] # Final round: S-box substitution with the ShiftRows lane permutation. s = [\ (get_u32(_SBOX, (n[0] >> 24) * 4) & 0xFF000000) | (get_u32(_SBOX, ((n[3] >> 16) & 0xFF) * 4) & 0x00FF0000)\ | (get_u32(_SBOX, ((n[2] >> 8) & 0xFF) * 4) & 0x0000FF00) | (get_u32(_SBOX, (n[1] & 0xFF) * 4) & 0x000000FF),\ (get_u32(_SBOX, (n[1] >> 24) * 4) & 0xFF000000) | (get_u32(_SBOX, ((n[0] >> 16) & 0xFF) * 4) & 0x00FF0000)\ | (get_u32(_SBOX, ((n[3] >> 8) & 0xFF) * 4) & 0x0000FF00) | (get_u32(_SBOX, (n[2] & 0xFF) * 4) & 0x000000FF),\ (get_u32(_SBOX, (n[2] >> 24) * 4) & 0xFF000000) | (get_u32(_SBOX, ((n[1] >> 16) & 0xFF) * 4) & 0x00FF0000)\ | (get_u32(_SBOX, ((n[0] >> 8) & 0xFF) * 4) & 0x0000FF00) | (get_u32(_SBOX, (n[3] & 0xFF) * 4) & 0x000000FF),\ (get_u32(_SBOX, (n[3] >> 24) * 4) & 0xFF000000) | (get_u32(_SBOX, ((n[2] >> 16) & 0xFF) * 4) & 0x00FF0000)\ | (get_u32(_SBOX, ((n[1] >> 8) & 0xFF) * 4) & 0x0000FF00) | (get_u32(_SBOX, (n[0] & 0xFF) * 4) & 0x000000FF),\ ] last = key_offset + rounds * 16 for i in range(4): d[pos + 4 * i:pos + 4 * i + 4] = (s[i] ^ get_u32(d, last + 4 * i)).to_bytes(4, "big") def aes_decrypt(d, pos, size, key_offset): """CBC decryption over `size` bytes at `pos`; the schedule lives in the same buffer at `key_offset` (round count at key_offset+2).""" rounds = get_u16(d, key_offset + 2) prev = bytes(16) for i in range(size >> 4): p = pos + i * 16 cur = bytes(d[p:p + 16]) _aes_round(d, p, key_offset + 4, rounds) for j in range(16): d[p + j] ^= prev[j] prev = cur [上一頁primitives.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/primitives.py) [下一頁huffman.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/huffman.py) 最後更新於 20 小時前 --- # primitives.py | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/primitives.py.md) . 除分組密碼、解壓器與字節碼 VM 之外的全部數據變換——[數據變換](https://app.gitbook.com/s/sFi4W2Zr1UBoxZd5YI3A/shu-ju-bian-huan/data-transforms) 中記載的各密碼與校驗和。 GitBook Assistant GitBook Assistant詢問複製 """Reference implementations of the protection scheme's data transforms. Written for readability: every function mirrors the algorithm the loader executes at runtime, using plain Python with explicit 32-bit/8-bit wrapping (Python ints don't overflow, so masks are applied where the original uses fixed-width machine words). Conventions: - All buffers are bytearrays (mutable, like the loader's in-place passes). - get_u32 / put_u32 are little-endian, matching the x86 environment. """ # --------------------------------------------------------------------------- # Fixed-width helpers # --------------------------------------------------------------------------- MASK32 = 0xFFFFFFFF def get_u16(d, off): return d[off] | (d[off + 1] << 8) def get_u32(d, off): return d[off] | (d[off + 1] << 8) | (d[off + 2] << 16) | (d[off + 3] << 24) def put_u32(d, off, value): value &= MASK32 d[off:off + 4] = value.to_bytes(4, "little") def rol32(x, n): return ((x << n) | (x >> (32 - n))) & MASK32 def ror32(x, n): return ((x >> n) | (x << (32 - n))) & MASK32 def rol8(x, n): return ((x << n) | (x >> (8 - n))) & 0xFF def ror8(x, n): return ((x >> n) | (x << (8 - n))) & 0xFF # --------------------------------------------------------------------------- # Header key derivation (offset 4096 -> info[8]) # --------------------------------------------------------------------------- def header_kdf(file_data, offset=4096): """Derive the 8-dword info table from the encrypted header cells. info[0] is stored directly; every following cell is XORed with a rolling key that mixes in the cell value and the square of the index. """ info = [0] * 8 info[0] = get_u32(file_data, offset) k = info[0] for i in range(7): cell = get_u32(file_data, offset + 4 + 4 * i) info[i + 1] = k ^ cell k = (i * i) ^ ((k + cell - i) & 0xFFFFFFFF) return info # --------------------------------------------------------------------------- # Rolling XOR chain over the payload body # --------------------------------------------------------------------------- def payload_xor_chain(file_data, out, info, decrypt_size): """Decrypt the bulk of the payload into the image buffer. Same rolling-key family as the header KDF, but the key is seeded from info[0] and the complement of the decrypted size, and advances with +i. """ base_src = (info[4] + 4096) & MASK32 k = (info[0] + (~decrypt_size & MASK32)) & MASK32 for i in range(decrypt_size >> 2): cell = get_u32(file_data, (base_src + 4 * i) & MASK32) put_u32(out, (info[3] + 4 * i) & MASK32, k ^ cell) k = (i * i) ^ ((k + cell + i) & MASK32) # --------------------------------------------------------------------------- # XOR + rotate-right dword cipher (rolling key), shift 19 or 21 # --------------------------------------------------------------------------- def xor_ror_dwords(d, pos, key, shift): """Decrypt a dword region described by the (addr, len) pair at `pos`. Used to unwrap each stage's pointer block. The key rolls forward by the loop index; the index is also subtracted after the rotation. """ base_addr = get_u32(d, pos) length = get_u32(d, pos + 4) for i in range(length >> 2): off = (base_addr + 4 * i) & MASK32 v = get_u32(d, off) ^ key key = (key + i) & MASK32 put_u32(d, off, (ror32(v, shift) - i) & MASK32) # --------------------------------------------------------------------------- # Triple byte-rotate ciphers with two rolling keys # --------------------------------------------------------------------------- def byte_rotate3(d, pos): """Descriptor-addressed variant: rotate by 3, keyed from the address.""" base_addr = get_u32(d, pos) length = get_u32(d, pos + 4) b = ((base_addr >> 8) + base_addr) & 0xFF b2 = (b + 1) & 0xFF for i in range(length): idx = base_addr + i x = rol8(d[idx], 3) ^ b2 x = rol8(x, 3) ^ b d[idx] = rol8(x, 3) b = (b + 1) & 0xFF b2 = (b2 + 1) & 0xFF def byte_rotate2(d, va, size): """Position-keyed variant: rotate by 2, keyed from the address itself. Each output byte depends only on the input byte and the low 8 bits of its address, so any 4 bytes can be trial-decrypted without touching the rest of the buffer - a property the loader's table walks rely on. """ b = va & 0xFF b2 = (b + 1) & 0xFF for i in range(size): idx = va + i x = rol8(d[idx], 2) ^ b2 x = rol8(x, 2) ^ b d[idx] = rol8(x, 2) b = (b + 1) & 0xFF b2 = (b2 + 1) & 0xFF def trial_byte_rotate2(d, va): """Non-mutating 4-byte trial decrypt (relies on the no-cross-byte-state property of byte_rotate2). Used to peek at encrypted descriptors.""" out = bytearray(4) for i in range(4): b = (va + i) & 0xFF x = rol8(d[va + i], 2) ^ ((b + 1) & 0xFF) x = rol8(x, 2) ^ b out[i] = rol8(x, 2) return get_u32(out, 0) # --------------------------------------------------------------------------- # LFSR keystream (protects the embedded bytecode stubs) # --------------------------------------------------------------------------- def lfsr_keystream(n): """n bytes of the LFSR keystream: seed 1, feedback 0x8003, 8 bits per output byte, LSB first. The stream is data-independent and can be replayed at any position.""" out = bytearray(n) state = 1 for i in range(n): b = 0 for k in range(8): b |= (state & 1) << k state = (state << 1) & MASK32 if state & 0x8000: state ^= 0x8003 out[i] = b return out def lfsr_decrypt_block(d, pos): """XOR a bytecode stub with the keystream. The block length is stored unencrypted at pos+95.""" length = d[pos + 95] ks = lfsr_keystream(length) for i in range(length): d[pos + i] ^= ks[i] # --------------------------------------------------------------------------- # Import-name string cipher # --------------------------------------------------------------------------- def string_cipher(d, pos, key): """Decrypt a NUL-terminated string in place: nibble swap, rolling subtract (step 67). The initial key is the low byte of the string RVA.""" i = 0 while d[pos + i] != 0: b = ror8(d[pos + i], 4) b = (b - key) & 0xFF if b == 0: b = (-key) & 0xFF d[pos + i] = b key = (key + 67) & 0xFF i += 1 # --------------------------------------------------------------------------- # Per-page .text scramble # --------------------------------------------------------------------------- def page_scramble(d, va, size, key): """XOR one byte per 16-byte block across a page. Block 0 only advances the key. `key` is the page index shifted left by a build-specific amount (0 or 15).""" for i in range(size >> 4): mixed = (ror32(key, 15) + i) & MASK32 key = (mixed + i) & MASK32 if i == 0: continue d[va + i * 16 + (mixed & 0xF)] ^= key & 0xFF def page_scramble_pe32(d, pa, page, big_formula): """32-bit build variant. The page key is either (page+1) or 0x8000*(page+1); the formula is not recorded anywhere in the file.""" key = (0x8000 * (page + 1)) & MASK32 if big_formula else page + 1 key = ror32(key, 15) for bi in range(1, 256): rk = ror32(key, 15) ri = (rk + bi) & MASK32 key = (ri + bi) & MASK32 d[pa + bi * 16 + (ri & 0xF)] ^= key & 0xFF # --------------------------------------------------------------------------- # CRC-32 (standard reflected polynomial 0xEDB88320) # --------------------------------------------------------------------------- def _build_crc_table(): table = [] for i in range(256): c = i for _ in range(8): c = 0xEDB88320 ^ (c >> 1) if c & 1 else c >> 1 table.append(c) return table _CRC_TABLE = _build_crc_table() def crc32_append(initial, data): crc = ~initial & MASK32 for b in data: crc = _CRC_TABLE[(crc ^ b) & 0xFF] ^ (crc >> 8) return ~crc & MASK32 def crc32(data): return crc32_append(0, data) def calculate_checksum(d, pos): """crc32(region) ^ length, where (offset, length) is read from d[pos].""" offset = get_u32(d, pos) length = get_u32(d, pos + 4) return crc32(d[offset:offset + length]) ^ length # --------------------------------------------------------------------------- # Triangular-number key schedule (stage key "advance") # --------------------------------------------------------------------------- def advance_key(key, iterations): """Roll a stage key forward: for m in 0..iterations, add every integer 1..(m+1)*100. The constants make each stage's key depend on content that only exists after the previous stage decrypted correctly.""" for m in range(iterations): bound = ((m + 1) * 25) << 2 for n in range(1, bound + 1): key = (key + n) & MASK32 return key [上一頁驗證與參考](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw) [下一頁aes\_impl.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/aes_impl.py) 最後更新於 20 小時前 --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/bytecode\_vm.py.md). # bytecode\\\_vm.py 解碼每個構建獨有 x86 樁的字節碼 VM，見 \[字節碼變換\](https://app.gitbook.com/s/sFi4W2Zr1UBoxZd5YI3A/shu-ju-bian-huan/bytecode-transform)。 \`\`\`python """The per-build custom byte transform ("bytecode VM"). Each protected build generates a unique x86 stub: it takes one byte in AL, applies a short sequence of arithmetic/rotate instructions, and returns. The loader runs this stub over every payload byte between the block-cipher pass and decompression. Instead of executing x86, the instruction bytes are decoded into a tiny op list and interpreted. Every op is reversible (add/sub, xor, rol/ror, inc/dec), so the whole chain is a permutation of the 256 byte values and can be precomputed as a 256-entry translation table. Only a narrow instruction subset ever appears; anything else fails the parse, which is what makes trial-decoding candidate locations reliable. """ # Opcode map: x86 encoding -> VM operation. # 04 ib ADD AL, imm8 ("add", imm) # 2C ib SUB AL, imm8 ("sub", imm) # 34 ib XOR AL, imm8 ("xor", imm) # 90 NOP (skipped) # C0 /0 ib ROL AL, imm8 ("rol", imm) # C0 /1 ib ROR AL, imm8 ("ror", imm) # FE /0 INC AL ("inc",) # FE /1 DEC AL ("dec",) # C3 RET end of program # # For C0/FE the ModR/M byte must encode register-direct AL (mod=3, rm=0); # the reg field selects the sub-operation. def generate(data, offset=0): """Decode the stub at \`offset\` into an op list, or return None if the byte stream is not a valid stub (must terminate in RET).""" pos = offset ops = \[\] def take(): nonlocal pos if pos >= len(data): return None b = data\[pos\] pos += 1 return b while True: op = take() if op is None: return None if op == 0x04: # ADD AL, imm8 imm = take() if imm is None: return None ops.append(("add", imm)) elif op == 0x2C: # SUB AL, imm8 imm = take() if imm is None: return None ops.append(("sub", imm)) elif op == 0x34: # XOR AL, imm8 imm = take() if imm is None: return None ops.append(("xor", imm)) elif op == 0x90: # NOP pass elif op in (0xC0, 0xFE): modrm = take() if modrm is None: return None mod, reg, rm = modrm >> 6, (modrm >> 3) & 7, modrm & 7 if mod != 3 or rm != 0 or reg > 1: return None if op == 0xC0: # ROL/ROR AL, imm8 imm = take() if imm is None: return None ops.append(("rol" if reg == 0 else "ror", imm)) else: # INC/DEC AL ops.append(("inc" if reg == 0 else "dec",)) elif op == 0xC3: # RET return ops else: return None def apply\_ops(ops, x): """Run an op chain over a single byte.""" for op in ops: name = op\[0\] if name == "add": x = (x + op\[1\]) & 0xFF elif name == "sub": x = (x - op\[1\]) & 0xFF elif name == "xor": x ^= op\[1\] elif name == "rol": n = op\[1\] & 7 x = ((x << n) | (x >> (8 - n))) & 0xFF elif name == "ror": n = op\[1\] & 7 x = ((x >> n) | (x << (8 - n))) & 0xFF elif name == "inc": x = (x + 1) & 0xFF elif name == "dec": x = (x - 1) & 0xFF return x def build\_translation\_table(ops): """The op chain is a pure function of one byte, so precompute all 256 results once and translate whole regions by table lookup.""" return bytes(apply\_ops(ops, i) for i in range(256)) def inverse\_ops(ops): """Reverse the chain: walk backwards, swapping each op for its inverse. (Documents why the transform is a permutation - it can always be undone.)""" inverse = {"add": "sub", "sub": "add", "xor": "xor", "rol": "ror", "ror": "rol", "inc": "dec", "dec": "inc"} return \[(inverse\[op\[0\]\], \*op\[1:\]) for op in reversed(ops)\] \`\`\` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/bytecode\_vm.py.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/aes\_impl.py.md). # aes\\\_impl.py 分組密碼：AES-CBC 解密，密鑰調度嵌入數據緩衝區，見 \[AES 變換\](https://app.gitbook.com/s/sFi4W2Zr1UBoxZd5YI3A/shu-ju-bian-huan/aes)。 \`\`\`python """The block cipher: AES decryption in CBC mode with an in-buffer key schedule. The loader embeds the expanded key schedule inside the same buffer as the ciphertext: a small header at \`key\_offset\` (the round count as a little-endian u16 at key\_offset+2) followed by (rounds+1) 16-byte round keys. Decryption runs in 16-byte blocks; each block is XORed with the previous ciphertext block (CBC chaining, zero IV). The five lookup tables are the standard AES \*decryption\* T-tables (InvSubBytes fused with InvMixColumns), generated below from GF(2^8) arithmetic - they are public AES constants, not proprietary data. """ MASK32 = 0xFFFFFFFF def get\_u16(d, off): return d\[off\] | (d\[off + 1\] << 8) def get\_u32(d, off): return d\[off\] | (d\[off + 1\] << 8) | (d\[off + 2\] << 16) | (d\[off + 3\] << 24) # --- table generation ------------------------------------------------------- def \_gf\_mul(a, b): """Multiply in GF(2^8) with the AES reduction polynomial.""" p = 0 for \_ in range(8): if b & 1: p ^= a hi = a & 0x80 a = (a << 1) & 0xFF if hi: a ^= 0x1B b >>= 1 return p def \_inverse\_sbox(): inv = \[0\] \* 256 for a in range(1, 256): for b in range(1, 256): if \_gf\_mul(a, b) == 1: inv\[a\] = b break fwd = \[0\] \* 256 for i in range(256): x = s = inv\[i\] for \_ in range(4): s = ((s << 1) | (s >> 7)) & 0xFF x ^= s fwd\[i\] = x ^ 0x63 isb = \[0\] \* 256 for i in range(256): isb\[fwd\[i\]\] = i return isb def \_build\_tables(): """Each table has 256 u32 entries. SBOX broadcasts invsbox(x) to all four lanes; COLUMMIX1 holds \[0x0b\*s, 0x0d\*s, 0x09\*s, 0x0e\*s\] and COLUMMIX2/3/4 are its one-, two- and three-byte rotations.""" isb = \_inverse\_sbox() sbox = bytearray(1024) cm = \[bytearray(1024) for \_ in range(4)\] for x in range(256): s = isb\[x\] lanes = \[\_gf\_mul(0x0B, s), \_gf\_mul(0x0D, s), \_gf\_mul(0x09, s), \_gf\_mul(0x0E, s)\] for j in range(4): sbox\[x \* 4 + j\] = s for t in range(4): cm\[t\]\[x \* 4 + j\] = lanes\[(j + t) % 4\] return sbox, cm \_SBOX, \_CM = \_build\_tables() # --- decryption ------------------------------------------------------------- def \_aes\_round(d, pos, key\_offset, rounds): """Decrypt one 16-byte block in place. The state words are loaded and stored big-endian; the round keys are read from the same buffer.""" n = \[int.from\_bytes(d\[pos + 4 \* i:pos + 4 \* i + 4\], "big")\ ^ get\_u32(d, key\_offset + 4 \* i) for i in range(4)\] # Middle rounds: InvSubBytes + InvShiftRows + InvMixColumns, fused into # four T-table lookups per state word, plus the round key. for r in range(1, rounds): off = key\_offset + r \* 16 n = \[\ get\_u32(\_CM\[1\], ((n\[3\] >> 16) & 0xFF) \* 4) ^ get\_u32(\_CM\[2\], ((n\[2\] >> 8) & 0xFF) \* 4)\ ^ get\_u32(\_CM\[0\], (n\[0\] >> 24) \* 4) ^ get\_u32(\_CM\[3\], (n\[1\] & 0xFF) \* 4) ^ get\_u32(d, off),\ get\_u32(\_CM\[1\], ((n\[0\] >> 16) & 0xFF) \* 4) ^ get\_u32(\_CM\[0\], (n\[1\] >> 24) \* 4)\ ^ get\_u32(\_CM\[2\], ((n\[3\] >> 8) & 0xFF) \* 4) ^ get\_u32(\_CM\[3\], (n\[2\] & 0xFF) \* 4) ^ get\_u32(d, off + 4),\ get\_u32(\_CM\[1\], ((n\[1\] >> 16) & 0xFF) \* 4) ^ get\_u32(\_CM\[2\], ((n\[0\] >> 8) & 0xFF) \* 4)\ ^ get\_u32(\_CM\[0\], (n\[2\] >> 24) \* 4) ^ get\_u32(\_CM\[3\], (n\[3\] & 0xFF) \* 4) ^ get\_u32(d, off + 8),\ get\_u32(\_CM\[2\], ((n\[1\] >> 8) & 0xFF) \* 4) ^ get\_u32(\_CM\[1\], ((n\[2\] >> 16) & 0xFF) \* 4)\ ^ get\_u32(\_CM\[0\], (n\[3\] >> 24) \* 4) ^ get\_u32(\_CM\[3\], (n\[0\] & 0xFF) \* 4) ^ get\_u32(d, off + 12),\ \] # Final round: S-box substitution with the ShiftRows lane permutation. s = \[\ (get\_u32(\_SBOX, (n\[0\] >> 24) \* 4) & 0xFF000000) | (get\_u32(\_SBOX, ((n\[3\] >> 16) & 0xFF) \* 4) & 0x00FF0000)\ | (get\_u32(\_SBOX, ((n\[2\] >> 8) & 0xFF) \* 4) & 0x0000FF00) | (get\_u32(\_SBOX, (n\[1\] & 0xFF) \* 4) & 0x000000FF),\ (get\_u32(\_SBOX, (n\[1\] >> 24) \* 4) & 0xFF000000) | (get\_u32(\_SBOX, ((n\[0\] >> 16) & 0xFF) \* 4) & 0x00FF0000)\ | (get\_u32(\_SBOX, ((n\[3\] >> 8) & 0xFF) \* 4) & 0x0000FF00) | (get\_u32(\_SBOX, (n\[2\] & 0xFF) \* 4) & 0x000000FF),\ (get\_u32(\_SBOX, (n\[2\] >> 24) \* 4) & 0xFF000000) | (get\_u32(\_SBOX, ((n\[1\] >> 16) & 0xFF) \* 4) & 0x00FF0000)\ | (get\_u32(\_SBOX, ((n\[0\] >> 8) & 0xFF) \* 4) & 0x0000FF00) | (get\_u32(\_SBOX, (n\[3\] & 0xFF) \* 4) & 0x000000FF),\ (get\_u32(\_SBOX, (n\[3\] >> 24) \* 4) & 0xFF000000) | (get\_u32(\_SBOX, ((n\[2\] >> 16) & 0xFF) \* 4) & 0x00FF0000)\ | (get\_u32(\_SBOX, ((n\[1\] >> 8) & 0xFF) \* 4) & 0x0000FF00) | (get\_u32(\_SBOX, (n\[0\] & 0xFF) \* 4) & 0x000000FF),\ \] last = key\_offset + rounds \* 16 for i in range(4): d\[pos + 4 \* i:pos + 4 \* i + 4\] = (s\[i\] ^ get\_u32(d, last + 4 \* i)).to\_bytes(4, "big") def aes\_decrypt(d, pos, size, key\_offset): """CBC decryption over \`size\` bytes at \`pos\`; the schedule lives in the same buffer at \`key\_offset\` (round count at key\_offset+2).""" rounds = get\_u16(d, key\_offset + 2) prev = bytes(16) for i in range(size >> 4): p = pos + i \* 16 cur = bytes(d\[p:p + 16\]) \_aes\_round(d, p, key\_offset + 4, rounds) for j in range(16): d\[p + j\] ^= prev\[j\] prev = cur \`\`\` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/aes\_impl.py.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # vectors.txt | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/vectors.txt.md) . 期望輸出。每行為 `名称 十六进制值`；前兩行是標準的 CRC-32 已知答案（`crc32(b"123456789") == 0xCBF43926`）及其鏈式形式——一個獨立於其餘向量的廉價交叉校驗。 GitBook Assistant GitBook Assistant詢問複製 crc32_123456789 cbf43926 crc32_chain cbf43926 kdf_info a07f35c4 08c23441 788c7e3e e4fcee52 30c61262 a5f0b9a7 8d927c7a cd491cb3 dd3_shift19 6fa2a6a442b0c33a208e2427319316cebeaa48f9eccfe41b533a8d8f5d206d4b dd3_shift21 9ba829e90fecb0ce8623c989caa48533ac2a52bef733f946904ee3631248db12 dd4 154fe25134b3a830e267b8085ba330867daf4d3b03318746fee42c1d14766971 dd5 ae04d26a350937426de7e73c7d1fbabd432b327735f22eb57a8fb7e69f2427fd lfsr96 018000600028001e80086006a802fe8180606028281e9e886866aeaafc7f01e0004800368016e00ec80456837ee1e0484836b696f6eec6cc52d5fd9f01a8007e80206018280a9e8728629ea9a87efea0407830229419af4afc3701d6805ee038 dd6_len95 5ecf7642b0dc99bccc6aca4e29242cf04c3e3d06077f1a6248ff6d9297c8b10bc4c99fc54fc973b710e91462ebceccfed10ca234a18c8bb8b4954ffbda8641786025febcd0a19b36a034ebed2ef7fb42c25af0c9c80fda352a935161e249d6 dd7_cipher b88c817519bd507468ffa4d8 dd7_plain 4b45524e454c33322e646c6c dd8_shift0 8b47b3c7549885b8d4b73ded824cd9ccfdb6b0b58ee3474a013577923678cd2f1fdb7e1bf0e55199c8d5965b1ce9a6029572b17745bb20cc4e934fe5707cb91807eac441980bc5f44409eec3a1bb37d6333d813bcdda7463f541e5b85c07ba8bf8baa2bfa2547ff45b865d1ea14bd8b76cd9620fcaa3c8632b2fc5abcee2ad77e80808aa7bbd8e9726766177b152756619167b956030c2f5ea3fdd4b9a2711c81202cfafb1f7b1af81f4cef069c0a1fd58cfd6bf3a4a2c14f04881839d1f0a41f54cb10d716a16e28b110fbe66d191e588ee601e8466f692bf136850b54460a154fe91986a2f81ab29d1a82949901fdf506ced49f0e031779e5eaec7c44a7e1117a231b8cf14d457422db38db5d4c9fd994f3375b476160a95ded20d0d13750ee8391f68589a19088311a05c5442b1a68e0ecc2689d2ffca742bb75e65bbf86af6353a3940f87d0d5b5e461ad2cd9d95a2993676adde6a70cb05a507d08c5e49357edf4c5218502900e8de5fe09df5da894f4a13e1d1faf0f2d5466ce508a425236fbe5bb2970701687704d9310bc9d83d07ea3f6b2f7714032aaa0399e56a53e4d8d0b146c83caf50c8bb47803fc946fa0ba6cf15ccca76da7b44567f0af35c4dfdf02e50b0aa79388bf18087354c2f4116132d2bc603871b327b05d095274ddc94e0459f0932ef6465d26a08ab4cf3d85c26577ff1558b2cadddc353449167b6c943fe87d4daa0dbee2804c7336544c88000de68d7169b363eb655785562c8463ca1f4df7acb346bb2fc5d8d2cdb294e9e75e7beb1c0a2272d7a964ac86ee13cff6758028b5037a29f439a262a92fe29419c2edf71f461b2b39176d61b2b768b9be5ecd1fcdaa8d6e255f462f41572006cf7fe06bb736c4c00c6f63071b7a1690a5009af0b003e1d2bf0b918d19188fc949e3b8ce5da2b3034482e6f1fd0d052bdbf9a83ac780c556936471d09d83179a24c5967fd13da0868aa47abaddac30596d11fb88321f81cedab1451e6604b1af32f62acc26e8990a4428205d7de8f84ec81ac40eafaeed8fa3aa892b343a2c25a58f34ba7871c54e852309f6c879e178c78e78c4529e5b0c92ea1c6393ef09b49bf40bad6d64cf226b2b79ffc24ad49b5bc0e9456f6d7aa873aafd478b3dc11f03d0cf329f5a5784528942f731acce91adbefd592cec728557396faa3a861d70791b37331a387b81e3a647f83b16209e244ee4dce43bfedea522f3821c7cee0005c203c31c2084780d59ac1ed742702a94c0380e9269f1562b467738c5dc667f126d7fe225b8a812e471c2ba6d2286d7f07b97673f6179fa7db3f53b45d41e74859ed42af979082de43a6f7d651c72ae6fd31bab30bae48046bcad49b5ca22255420b1738c5e72c3ae21666da17955dd7c31d5ba267be965f6f33d279943e1d37246f62d1581327e19f5eb843f0066bbb60c5eef04f75d08f7eb5c2b8e25322efe7ebba43e626dc66578634d74c0c01749d0689fc2bd60261eaa115f6c90fbcd6b3e438a02b22784d50a7268e3f7d0c54274ec9df89b6fd95675c70082c0dbdb957557952061def1330f2da94805d57238da2cc6019c055e1645e72f49b3d3bda94ca9f03786ef56602a7a64c6c05951cae9937ffaf7261ebdf3454f5bee18def136550b4aa8206e7368add49022345efa55e0eed461f3e51397f3079e89152205cdcb5b0e5e85eada0c2dcbde7b8cfbfebb26410f978cba237f42124d0386a0cdf797bf898f101c47511006d6025762336e802020ad1ad64035aa3cdcf15fbc37d1ad54057c1b468529eadc15cefc2268ce7bd11dca14b0f638fcc7ee2bb6ccbbc2f78eed8b801cc361048b768377d49d42ccd3efafad20f9b84d2b9ad126c1e67f99c20f56a361884203ce7ba42b67f3cc6ee400f5532c5af3c882974542e28ed6401a5aeb06665039ff81e29b6c12e4f585e81ecfb1f841dd11f3c65101fcc2f4ae601259565c1df6eef99308c3333c81be21f870a109603b3cb8c422b805ef434136ca262cf30648496daf011eaddbcd9c1eaf8748037e258c42709dacba8e677d0d28ef102a74eec69fc2be603ef87f3076a7bffb5979fe048504caa02e893fdea1179f81e102cc4e5614b00e11e6b5d43d872462dda846e967e84786ace6e44b5c215b30b4cfc408eda5ba82c9d8b9d092361b7311a3e80f35bcfc68a81cd5d04a83a42732bdda5376b0a7ccec7efd070ebf2940f62dfa7a8c7ef343299eaed3140e1ccc3746f4f834fad6cf76985a58b87f0f3d6b3db8701d54a847125e4301bfb2b522de143ac28f03abf19d41b60130261be59010bda50cbe9979da5bcf122fc58eaa822fb3eadf14fdaecbe67d993171eb4b234ae6ae7247bf24e2459942c1bd27aedd7299d66272a426b19007a3a3b9b66bc2ab01a2090516b62cb8673a2e521c07b99e073ae99afa0d5486445f492203b16b233de58d9602dfab9f0e6734af64a94f1997f258667beac2171cc30f6306d269184beee5d43b77a292a3d102922593d5d2d936c5d7d8258f0ed37e2f66e0a937f24d8482138de8de0abc36d409c944150dd9656c5c12c0475e44282d3a4f4c929445bceba20c71e18cbbf063980982ded4b830b95a64cdee4b63d0a84be9af92f7a8decdd80ee5f7ecb09d7790c6a55598068bcdb45c6dbe3800a21b1cc5c1525c0c6146f8422c434921061c3a2bdcd18e569efd859d5888db12358b905c2d7957173b98bf88708cfd3d5ab90cb1b6faf4bba5c00415dd9730291a9afbf46bbf9501454d64e932759cced3db72fdfdb55e5a8ebfd033856980ff6f9577aeeffc3d53f61d49d12614f868326179f3a71351d92cfab44a2e8735985d72bd4c0a958919b623a9d223da2b155f7440d2f596c75e8574753ce77ef4305580e93e7800f69e6da9ead3782b796b3c5868f977b0dc6331a931d972e6c17d212c79f3111345bf0531fce19ec699b832bd9611f8620ff0de38a372f7dbe00dc2205066eab671e9d5810a7e2c404653f44ede245ec9d492581afd81c152c0ea62660f92263c2ca267bf88001a64bedf5df26935fe4732e3cc6e1de36ef70374943d5cb831087dcda5087493abe71f147a09ba39466869e2b8837c6ab45bb516f2016f6634f7537976ecd92ca29224969b01a48e122aaecdba3f7b5fc95b0a458e78916697f9b1e5274cb91a84879e32613200515c7acb74bf4a173fea56732d84a48ed1bc5ff3c5501e42109c10a92dc7ae367d66f48648f5e586bda796a1d577b545fa008999efbbaa3bed77cca0b7b1b4aa39b313227cbc8a5ae0d5eb943d1329575420c54b4b548c58b7ba65de98ab0f215afdd10fe3c1cfe9e68e2c8f0d4abdc5beafd135508463f4dafb188aa23742a3c35047c30c0493b8511d87e5685a5de636251c7ba8d96386f8351b8b1f22cf5baf1fd04670941dd6e815837889b6339ef48ecdd7ff0bc09fe5a7fc4443af60d5635e02cb33ffb9a4785bcc19262ad40ce0e886da7f38142aceb79198cd00bdcfc158d69875b7259563da46115bacff887fba60a9669a1a6ceaabf09991e4a84b82da626bbfda33882ccf2cd0c16981b0c288a57153b362c5ebb1730ac22aad6bfc38fc289d7918757f6ce31097e5b1863843cedb966f8fffb0d8911ae6d7f5d68e6748e92af44cd04dda22c948df10fb3d18859dffb527de63d63c44525a43b2c9b43d1d861c5c15e461ed31874b5d74ba5fe1ab11ef63a06a736d8c30376a8ab65adc6c3db2350dbf562abe7f586fb9b6bf1a6200875fde0fad64da856d701a84d289b1e20719c99041cb29e69c7b7365f7b64ea050fbfa7395d985bfe2cb4094fef721813c5f956e1515518bb9ffdd79677b231779bb12bbb27a426725ecfdacb006244793959774b91798e6cbf745ba785df79d1f735e32bd6ce38bbdb1148d11c759bf6ec3f03a5e074788dd076c134092fac9da9e2e6894fe6f27795eea746caa9761002d6a674851399c809102ee32bdc1d78a383f428bb335dd8018e6d4a53f2962f9fd9b0590b959b575f04ec66d7126c11c0986faf866f40a419cc3630c6341dccefa2141840adae0b50c967f0bef0c02e46d15b18e7c50b315a39bf91f54c937620be6b1739825248da87308d528d8ca7271767b444d86070c618ed397607e4d1656aef104bb0cc04811dfc1acdefadeb5685d52566bdc6e3e362c531a227dd92f526820f1247afcb4d1ea34ba9136473cceaa26243fea69fb9c372d69963b584098fa7766dc917bd49ce22a42aea58dd864860b79d974f4dd61b44523b66ff87e18785f97f51058f04289b81505891cd84d648c379fbf32b4dfaac362fceb98bbe9fe8a3afe25d8693d9510ee5367c80cbff3a061f0fa80bb1ac43c6df2dc29a759a40cfa947e7808c44ae4ff44feb486363b6201f2c69531e2dc2c07809a0cca972a12f5a274f7c8c7f3e1a4d65138859d3e253471f14fb30ac089eeedd3151d155c3c9f6d325ccb1525f19852c8dbabd588802ad2a6c920a0c1834f618496b2ea294f5f503dfbaa03de0c9b34b576aa32b166faae9163a50e6192b0a1c15719bef5b611067d4e17f72c07db460463926bc9e32dcd29c992c8656ff683f68cdf205750e482140fffbd56e5ca7fcc3db5f47d53623366e244b793dff12cb79ff8fe09750dfca046a43012b5f71a1541972d715b9a43fdd8fe0ca61b6ce00e498d7b2add2fc6de4090a445c547ac911cf81435c50c87320589f8a79ea260fa7400ddf46908b892c5788a08adfeee1ecefb6304be13dcc5186c347609a698327b2040196db7a117d6379ca624fbc483a7d3d1129a8f3b66eb308cb15ffa74a2bbbc2e474597c6ef3d3812db45e9853b592468ee0341f13400bb1acba8eb89fdd3edc895e03317afedd33e775bbfc4a7a5a0681fc673b3ada518310968e3620cc33c825713d5b84164c09c9be7d226a0a16b6efb07903f299dac7ea141c7dc3eea414217362325198816659cc6b0ce45c1b9238d2f5797926914ad7c228b17480af091acbae1018c4709cd1000a7cdb84d1dbb6dbbbe182f2f15f2e5477b70f85875dfc85529c83be9f7e35de06fb6865b5d51ee9fdc530670edbf5a09f3a69d673867a51ecc2b38f2b63e60f7ad597fe57c84fbf43621f878d18e8a20fa7460dcd0f1e816cb13b23c4277b604c1a44c55d025bc067775abfa8f378770431621204863c0f18db2249ac28e7c2ac9dd393fed38af999ab64b92be6c86295cd6b2f9b7e729689f8e4b8bb4ce94940f8bca4898e83165d2731a27a8cb1b4a9350415298c9755ad0370055ef9f32f9a86019b5d8e6e69a1c82c2c8999bd3cfc3ac2d7584cb431c33a29d1941b2acf2167727dee2eb5e747af3206e2e32e641e2830cce65c04b16221e715f02169abc57fd5b346cf432b194093c1a3dbf61673fbcc2da75f8501737ff67c9aff08687377e10981d66173d025c5d57d76be48342a0add80fb39f0325e140b4e2de8ce2d0342b3d0aa90a0944bf59bb72de2156d444f9d6edb9bc5320f75d05ca561cbf477994478698138e0e2db5229ff72bdfe9af675cdad2c235623c1baa6e9506e54a454b6d0731b658361eb1c426c31a135444dd1d2242f39d972139da6fa1543a8f87067474c7bf4a07fbaff03d69749cc1a977fa2f617954717fa9e6660c0a025eff4175cbeee57af3bfee602b4d15feebb09b239de8d3d8171791686281805cfca78eca444f7a5d0d42f9e6826beb33088cf03f59b6fd7122309c83ae197bc828c5f6fc8f54d9622d0446af362f33696a9076c48eecdaf85 dd8_shift15 8b47b3c7549885b8d4b73ded824cd9ccfdb4b0b58ee3474a013577923666cd2f1fdb7a1bf0e55199c8d5965b1ce986029572b17745bb20cc4e934f95707cb91807eac441080bc5f44409eec3a1bb37d6333d813bcdda7463f541e5b85c47ba8bf8baa2bfa2543ff45b865d1ea14bd8b76cd9620fcaa3c8632b2fc5abcee2ad77e80808aa7bbd8e9726766177b152756619167b956030c2f5ea3fdd4b9a2711c81202cfafb1f7b1af81f4cef069c0a1fd58cfd6bf3a4a2c14f04881839d1f0a41f54cb10d716a16e28b110fbe0eb891e588ee601e8474e592bf136850b54460a154fe51986a2f81ab29d1a8294990a3df506ced49f0e031119e5eaeadc44a7e1137a223b8cf14d457422db38db5d4c9fd994f3375b476160a95de190db013750ee839bb68589a19088311cc5c5442b1a68e5acc2689d2ffca7437b75e65bbf86af6353a3940f87d6d5b5e461ad2cd9d95a2993676ad3e6a70cb05a507d08c5e49357edf4cd218502900e8de5fe09df5da894fca13e1d1faf0f2d5466ce508a425236fbe5bb2970701687704d9310bc9d83d07ea3f6b2f7714032aaa0399e56a53e4d8d0b146c83caf50c8bb47803fc946fa0ba6cf15ccca76da7b44c0e80af35c4dfdf02e50b0aa79388bf18087354c2f4116132d2bc603878e32ec05d095274ddc94e0459f09327a64f2d26a08ab4cf3d85c26577ff1c08b2cadddc353d89167b6c943fe8741daa0dbee28045b336544c880b3de68d7819b363eb655785562c8463ca141df7acbad6bb2fc5d8d2cdb29fe9e75e7beb1c0a2272d7a964ac86ee13cff6758028b5037a22f439a262a92fe2941dc2edf71f461b2b39176d61b2b768b9be5ecd1fcdaa8d6e2553462f41572006cf7fe06bb736c4c00c6f63071b7a1690a5009af0b003e1d2bf0b918d19188fc949e3b8ce5da2b3034482e6f1fd0d052bdbf9a83ac780c556936471d09d83179a24c5967fd13da0868aa47abaddac3056b2f1fb88321f81cedab1451e6604b1af32f62acc26e8990a4e52a05d7de8f84ec81fd40eafabbd8fa3aa892b343a23d5a58f34ba7871c54e852309f90879e178c78e78cf02942b0c92ea1c6393ef09b1bbf40bad6d64cf226b2b79ffc24cd4bb5bc0e9456f6d790873aafd478b3dc11f03d0cf3291ca5784528942f73abcce91adbefd592cec728557396daa3a861d70791b37331a387b81e3a447f83b16209e244ee4dce43bfed6a522f3821c7cee0005c203c31c2884780d59ac1ed742702a94c0380e9269f1562b467738c5dc667f126d7fe225b8a812e471c2ba6d2286d7f2b947673f6179fa7db3f53b45d41e74859ed42af979082de43a6f7d651c706e6fd31bab30bae48046bcad49b5c892255420b1738c5e72c3ae21666da3cb95dd7c31d5ba267be965f6f33f879b83e1d37156f62d1581327e19f74b843f0066b8a60c5eef04f75d08f54b5c2b8e25322efe7ebba43e66edc6657aa34d74c0c01749d0689fc2bd64861eaa13bf6c90fbcd6b3e438302b22784d50a7268e3f7d0c54274ec9df89b6fd95675c7008dc0dbdb957557952065def1330f2da94805d97238da2cc6019c055e1645e72f49b3d3bda94ca9f03786ef56602a7a64c6c05951cae9937ffaf7261ebdf3454f5bee18def136550b4aa8206e7368add49022345efa55e0eed461f3e51397f3079e89152205cdcb5b0e5e85eada0c2dcbde7b8cfbfebb264106bebcba237f42124d038570cdf797bf898f101c47511006d6019762336e802020ad1ad83035a49cdcf15fbc3ec1ad540c2c1b468529eadc15cefc2268ce7bd11dca14b0f298ff07ee2bb6ccbbc2f7818d85001cc361048b768377d49d42ccda9fafad20f9b84d276ad126c1e67bf9c20f56a3618845e3ce7ba42b67fdcc6ee400f5532c5af3c882974544e28ed6401a5aeb06665039ff81e29b6c12e4f585e81ecfb1f841dd11f3ce5101fcc2f4ae601259565c1df6eef19308c3333c81be21f870a109603b3cb8c422b805ef434136ca262cff2a78496daf011eaddbcd9c1eaf8748037e258c42709dacba8e677d0d24f3302a74eec69fc2be603ef87f3c7ab7bffb5979fe048504caa02e8933dead379f81e102cc4e5614b00e1a16b9c43d872462dda846e967e8478d5ce6e44b5c215750b4cfc408eda5ba82c9d8b9d0923a7b7311a3e80f35bcf794b81cd5d04a83a42732bdda5ea6b0a7cce04efd070ebf2940f62dfa7a818ef343299eaed3140e1ccc3749f4f834fad6cf76985e25387f0f3d6b3db8701d54a847125e4301bfb2b522de143ace9f23abf19d41b601302a1be59010bda50cbe9979da5bcf122fc58eaa822fb3eadf14fdaecbe67d993171eb4b234ae6ae7247bf24e2459942c1bd27aedd7299d66272a426b19007a3a3b9b66bc2ab01a2090516b62cb8673a2e521c07b99e073ae99afa0d5486445f492203b16b233de70f0602dfab9f0e67398254a94f1997f258667beac21f1cc30f6306d269184beee5d3fb77a292a3d1029227f3d5d2db96c5d7d82b8f03f37e2f66e0a937f24d8482138de8de0abc36d409c94415056962bc5c12c0475804282d3a4f4c929685bceba20c71e0ccbbf063980982d314b830b95a64cdee4b63d0a84be7af92f7a8decdd80ee5f7ecb09d7190c6a55598068bcdb45c6dbe3800aa1b1cc5c1525c0c6146f8422c434121061c3a2bdcd18e569efd859d5888db12358b905c2d7957173b98bf88708cfd3d5ab90cb1b6faf4bba5c00415dd9730291a9afbf46bbf9501454d64e932759cced3db72fdfdb55e5febcfd033856980ff6f9577aeeffc3d53f61d49d12614f868326179f3a24354a92cfab44a2e8735985d72bd495a90f919b623a9d223da2b155f744582f596c75e8571b53ce77ef4305585b93e7800f69e6869ead3782b7e5b3c586d8977b0dc6331a931d972e6c17a712c79f6811345bf0531fce195c699b832bd9611f8620ff0de38a372f7dbe00dc2205066eabd71e9d5810a7e2c404a53f44ede245ec9d492581afd81c152c0ea62660f92263c2ca667bf88001a64bedf5df26935fe4732e3cc6e1de36ef70374943d5cb831087dcda5087493abe71f147a09ba39466869e2b8837c6ab45bb516f2016f6634f7537976ecd92ca29224969b01a48e122aaecdba3f7b5fc950d1a58e78916697f9b1e5274cb91a84879e32613200515c7acd023f4a173fea56732c94a48ed0ec5ff3c5501e421097e0a92dc7ae367d66f48648f5ee46bda796a1d577b215fc708999efbbaa3bed77cd80b7b1b4aa39b313227cbc8a5ae2d9cb943d132957542f654b4b548c58b7ba65de98ab0f2bcafdd10fe3c1cfeef68e2c8f0d4abdc5beafd135508663f4dafb188aa23742a3c35047c30e0493b8511d87e5685a5de63625147ba8d96386f8351b8b1f22cf5ba71fd04670941dd6e815837889b6339ef48ecdd7ff0bc09fe5a7fc4443af60d5635e02cb33ffb9a4785bcc17e8fad40ce0e886da7f38142aceb79198cd00bdcfc158d69875b7259563d486115bacff887fba60a9669a1a6ce41bf09991e4a84b82da626bbfda3386920f2cd0c16981b0c288a57153bdc2cb2bb17305d22aad6bfc38fc2893d918757f6cec0097e5b1863843ced5366f8fffb0d8911ae6d7f5d68ee748e924344cd04dda22c948df10fb3d18259dffbbc7de63d63c44525a4ab2c9b43d1d861c5c15e461ed31874b5d74ba5fe1ab11ef63a76a736d8c30376a8aba5adc6c3db2350dbf522abe7f586fb9b6bf1a6200875fde0fad64da856d701a84d289b1e20719c99041cb29e69c7b7365f7b64ea050fbfa7395d985bfe2cb4094fef721813c5f956e1515518bb9ffdd79677b231779bb12bbb27a426725ecfdacb006244793959774b91798e6cbf7409f485df79d1f735e32b2bce38bbdb1148d11c759bf6ec3f0359e074788dd076c1340988ac9d03e2e6894fe6a37795eef246caa9761002d6a674851399c809102ee32bdc17785f83f428bb335dd801386de253f2962f9fd9b0590b959b575f53ec66d7126c11c0176faf866f40a219cc3630c6341df2efa2141840adce0b50c967f0bef0c02e46d15b1807c50b315a39bf91f54c937620be6b1739825248da87308d528d8ca72717e7b444d86070c618ed397607e4d165eaef104bb0cc04811dfc1acdefadeb5685d52566bdc6e3e362c531a2a55e92f526820f1247afcb4d1ea34ba9136473cceaa26243fea69fb9c3f3549963b584098fa7766dc917bdc94f22a42aea58dd864860b79d974fcdd69944523b66ff87e18785f97f2e050e04289b81505891cd84d648c306fbf32b4dfaacb02fceb98bbe9fe8a3afe25d8693d9d70ee5367c80cbff3a799e0fa80bb1ac43c6df2dc29ae89a40cfa9c4e7808c44ae4ff44feb4863fcb6201f2c69531e2dc2c07809d0cca972a12f5a274fec8c7f3e1a4d65138859d3e253471f14fb30ac089eeedd31515097c3c9f6d325ccb1f9b319852c8dbabd588802ad2a6c920a0c1834f618496b2ea20163f503dfbaa03de0c9b34b576aa32b166faae9163a50e6192b0a1c15719bef5b611067d4e17f72c07db460463926bc9e32dcd29c992c8656ff683f68cdf205750e482140fffbd56e5ca7fcc3dbb7aed53623366e244bebaeff12cb79ff8fe09750dfca446a43012b5f71a1541972d729b9a43fdd8fe0ca6150ce00e472d7b2add25c6d76090a445c547ac911cf81435c50c87320589f8a79ea260fec4030df46908b89085788a08adfeee100efb6304be13d185186c347609a691f27b2040196db7a117d6379ca622fbc483a7d3d1129a8f3b66eb3082b15ffa74a2bbbc2e474597c6ef3d3012db45e9853b592468ee0341f13c00bb1acba8eb89fdd3edc895e03317afedd33e775bbfc4a7a5a0681fc673b3ada518310968e3620cc33c825713d5b84164c09c9be7d226a0a16b6efb07903f299dac7ea141c7dc3eeb203217362325198816659cc6b0ce45c1b9238d2f5797926914ad7c228a47497af091acbae1018c4709cd1001f7ccc84d1dbb6dbbbe182f2f15f2e4177b70f85875de085529c83be9f7e20de06fb6865b5c91ee9fdc530540edbf5b79f3a69d673867a51ecc2b38f1e63e60f63d597fe57c84fbf43d21f878d18e8a20fa7460dcd0f1e816cb13b23c4277b604c1af4c55d025bc067775affa8f378770431621204863c0f18db2249ac28e7c2ac9dd3933ed38af999ab64b92be6c86295cd6b2f9b7e729689f8e4b8bb4ce94940f8bca4898e83165d2731a27a8cb1b4a9350415298c9755ad0370055ef9f32f9a86019b5d8e6e69a1c82c2c8999bd3cfc3ac2d7584cb431c33a54af941b2acf2167727dee2eb5e747af3206e2e32e641e2830ebce5c04b16221e715212169ab107fd5b346cf432b193f93c1a3dbf61673fbcc2da75ff901737ff67c9aff3d685477e10981d66173d02517d57d76be48342a0add80fb39f0d2dc140b4e2de8ce2db942b3d0aa90a0944bf59bb72de27c6d444f9d6edb9bf4320f75d05ca561cbf477994478498138e0e2db5229ff72bdfe9af675edad2c235623c1baa6e9506e54a4d4b6d0731b658361eb1c426c31a1b5444dd1d2242f39d972139da6fa1543a8f87067474c7bf4a07fbaff03d69749cc1a977fa2f617954717fa32cb60c0a025eff4175cbeee57af3bfee602b4d15feebb09b239de8d3d81dd791686281805cfca78eca444f7a57bd42f9e6826beb33088cf03f59b6f7cbe2309c83ae197bc828c5f6fc85f4d3a22d044dbf362f33696a9076ce2eecdaf85 dd8pe32_small 8b47b3c7549885b8d4b73ded824cd9ccfd94b0b58ee3474a013577923666cd2f1fdb7e1bf0e55199c8d5965b1ce9a6029572b17745bb20cc4e934f15707cb91807eac441980bc5f44409eec3a1bb37d6333d813bcdda7463f541e5b85c47ba8bf8baa2bfa2547ff45b865d1ea14bd8b76cd9620fcaa3c8632b2fc5abcee2ad77e80808aa7bbd8e9726766177b152756619167b956030c2f5ea3fdd4b9a2711c81202cfafb1f7b1af81f4cef069c0a1fd58cfd6bf3a4a2c14f04881839d1f0a41f54cb10d716a16e28b110fbe66d191e588ee601e8466f692bf136850b54460a154fe91986a2f81ab29d1a82949901fdf506ced49f0e031779e5eaec7c44a7e1137a213b8cf14d457422db38db5d4c9fd994f3375b476160a95ded20d0d13750ee839bb68589a190883110c5c5442b1a68e0ecc2689d2ffca742bb75e65bbf86af6353a3940f87d6d5b5e461ad2cd9d95a2993676adde6a70cb05a507d08c5e49357edf4cd218502900e8de5fe09df5da894f4a13e1d1faf0f2d5466ce508a425236fbe5bb2970701687704d9310bc9d83d07ea3f6b2f7714032aaa0399e56a53e4d8d0b146c83caf50c8bb47803fc946fa0ba6cf15ccca76da7b44567f0af35c4dfdf02e50b0aa79388bf18087354c2f4116132d2bc603871b327b05d095274ddc94e0459f0932ef6465d26a08ab4cf3d85c26577ff1558b2cadddc353d80c67b6c943fe87d4daa0dbee2804c7336544c880b3de68d7a19b363eb655785562c8463ca1f4df7acb346bb2fc5d8d2cdb297e9e75e7beb1c0a2272d7a964ac86ee13cff6758028b5037a29f439a262a92fe2941dc2edf71f461b2b39176d61b2b768b9be5ecd1fcdaa8d6e255f462f41572006cf7fe06bb736c4c00c6f63071b7a1690a5009af0b003e1d2bf0b918d19188fc949e3b8ce5da2b3034482e6f1fd0d052bdbf9a83ac780c556936471d09d83179a24c5967fd13da0868aa47abaddac30596d11fb88321f81cedab1451e6604b1af32f62acc26e8990a4428205d7de8f84ec81ac40eafaeed8fa3aa892b343a2c25a58f34ba7871c54e852309f6c879e178c78e78cf02952b0c92ea1c6393ef09b49bf40bad6d64cf226b2b79ffc24ad0bb5bc0e9456f6d790873aafd478b3dc11f03d0cf329f5a5784528942f731acce91adbefd592cec728557396daa3a861d70791b37331a387b81e3a647f83b16209e244ee4dce43bfed6a522f3821c7cee0005c203c31c2084780d59ac1ed742702a94c0380e9269f1562b467738c5dc667f126d7fe225b8a812e471c2ba6d2286d7f07b97673f6179fa7db3f53b45d41e74859ed42af979082de43a6f7d651c72ae6fd31bab30bae48046bcad49b5ca20f55420b1738c5e72c3ae21666da17b95dd7c31d5ba267be965f6f33d279943e1d37155d62d1581327e19f5eb843f0066bbb60c5eef04f75d08f7eb5c2b8e25322efe7ebba43e66edc6657ca34d74c0c01749d0689fc2bd60261eaa115f6c90fbcd6b3e438b02b22784d50a7268e3f7d0c54274ec9df89b6fd95675c70082c0dbdb957557952065def1330f2da94805d57238da2cc6019c055e1645e72f49b3d3bda94ca9f03786ef56602a7a64c6c05951cae9937ffaf7261ebdf3454f5bee18def136550b4aa8206e7368add49022345efa55e0eed461f3e51397f3079e89152205cdcb5b0e5e85eada0c2dcbde7b8cfbfebb26410f978cba237f42124d0386a0cdf797bf898f101c47511006d6025762336e802020ad1ad64035a4926cf15fbc37d1ad54057c1b468529eadc15cefc2268ce7bd11dca14b0f298f807ee2bb6ccbbc2f78eed8b801cc361048b768377d49d42ccde9fafad20f9b84d276ad126c1e67f99c20f56a361884203ce7ba42b67fdcc6ee400f5532c5af3c882974542e28ed6401a5aeb06665039ff81e29b6c12e4f585e81ecfb1f841dd11f3ce5101fcc2f4ae601259565c1df6eef99308c3333c81be21f870a109603b3cb8c422b805ef434136ca262cf30648496daf011eaddbcd9c1eaf8748037e258c42709dacba8e677d0d28ef102a74eec69fc2be603ef87f3076a7bffb5979fe048504caa02e893fdea1179f81e102cc4e5614b00e11e6b5d43d872462dda846e967e84786ace6e44b5c21575cc4cfc408eda5ba82c9d8b9d092361b7311a3e80f35bcfc66b81cd5d04a83a42732bdda5ea6b0a7ccec7efd070ebf2940f62dfa7a8c7ef343299eaed3140e1ccc3741f4f834fad6cf76985a58b87f0f3d6b3db8701d54a847125e4301bfb2b522de143ace8f03abf19d41b60130261be59010bda50cbe9979da5bcf122fc58eaa822fb3eadf14fdaecbe67d993171eb4b234ae6ae7247bf24e2459942c1bd27aedd7299d66272a426b19007a3a3b9b66bc2ab01a2090516b62cb8673a2e521c07b99e073ae99afa0d5486445f492203b16b233de58d9602dfab9f0e6734af64a94f1997f258667beac2171cc30f6306d269184beee5d43b77a292a3d102922593d5d2d936c5d7d82b8f00f37e2f66e0a937f24d8482138de8de0abc36d409c944150dd9656c5c12c0475804282d3a4f4c929285bceba20c71e18cbbf063980982ded4b830b95a64cdee4b63d0a84be7af92f7a8decdd80ee5f7ecb09d7790c6a55598068bcdb45c6dbe3800aa1b1cc5c1525c0c6146f8422c434921061c3a2bdcd18e569efd859d5888db12358b905c2d7957173b98bf88708cfd3d5ab90cb1b6faf4bba5c00415dd9730291a9afbf46bbf9501454d64e932759cced3db72fdfdb55e5a8ebfd033856980ff6f9577aeeffc3d53f61d49d12614f868326179f3a71351d92cfab44a2e8735985d72bd4c0a958919b623a9d223da2b155f7440d2f596c75e8571b0ece77ef4305580e93e7800f69e6da9ead3782b7e5b3c586f8977b0dc6331a931d972e6c17d212c79f3111345bf0531fce19dc699b832bd9611f8620ff0de38a372f7dbe00dc2205066eab671e9d5810a7e2c404a53f44ede245ec9d492581afd81c152c0ea62660f92263c2ca267bf88001a64bedf5df26935fe4732e3cc6e1de36ef70374943d5cb831087dcda5087493abe71f147a09ba39466869e2b8837c6ab45bb516f2016f6634f7537976ecd92ca29224969b01a48e122aaecdba3f7b5fc95b0a458e78916697f9b1e5274cb91a84879e32613200515c7acb74bf4a173fea56732d84a48ed1bc5ff3c5501e42109c10a92dc7ae367d66f48648f5e586bda796a1d577b215fd708999efbbaa3bed77cca0b7b1b4aa39b313227cbc8a5ae0d5cb943d132957542f654b4b548c58b7ba65de98ab0f215afdd10fe3c1cfe9e68e2c8f0d4abdc5beafd135508663f4dafb188aa23742a3c35047c30c0493b8511d87e5685a5de63625147ba8d96386f8351b8b1f22cf5baf1fd04670941dd6e815837889b6339ef48ecdd7ff0bc09fe5a7fc4443af60d5635e02cb33ffb9a4785bcc19262ad40ce0e886da7f38142aceb79198cd00bdcfc158d69875b7259563da46115bacff887fba60a9669a1a6ceaa5209991e4a84b82da626bbfda3388220f2cd0c16981b0c288a57153b362c5ebb17305dd0aad6bfc38fc289d7918757f6ce31097e5b1863843cedb966f8fffb0d8911ae6d7f5d68ee748e92a344cd04dda22c948df10fb3d18859dffb527de63d63c44525a42b2c9b43d1d861c5c15e461ed31874b5d74ba5fe1ab11ef63a06a736d8c30376a8aba5adc6c3db2350dbf562abe7f586fb9b6bf1a6200875fde0fad64da856d701a84d289b1e20719c99041cb29e69c7b7365f7b64ea050fbfa7395d985bfe2cb4094fef721813c5f956e1515518bb9ffdd79677b231779bb12bbb27a426725ecfdacb006244793959774b91798e6cbf745ba785df79d1f735e32bd6ce38bbdb1148d11c759bf6ec3f03a5e074788dd076c134092fac9d0349e6894fe6f27795eea746caa9761002d6a674851399c809102ee32bdc1778af83f428bb335dd8018e6d4a53f2962f9fd9b0590b959b575f93ec66d7126c11c0176faf866f40a419cc3630c6341dccefa2141840adce0b50c967f0bef0c02e46d15b18e7c50b315a39bf91f54c937620be6b1739825248da87308d528d8ca72717e7b444d86070c618ed397607e4d1656aef104bb0cc04811dfc1acdefadeb5685d52566bdc6e3e362c531a227dd92f526820f1247afcb4d1ea34ba9136473cceaa26243fea69fb9c372d69963b584098fa7766dc917bd49ce22a42aea58dd864860b79d974f4dd61b44523b66ff87e18785f97f51058f04289b81505891cd84d648c379fbf32b4dfaacb0a8ceb98bbe9fe8a3afe25d8693d9510ee5367c80cbff3a06be0fa80bb1ac43c6df2dc29ae89a40cfa947e7808c44ae4ff44feb486363b6201f2c69531e2dc2c0780950cca972a12f5a274feb147f3e1a4d65138859d3e253471f14fb30ac089eeedd31519155c3c9f6d325ccb1525f19852c8dbabd588802ad2a6c920a0c1834f618496b2ea294f5f503dfbaa03de0c9b34b576aa32b166faae9163a50e6192b0a1c15719bef5b611067d4e17f72c07db460463926bc9e32dcd29c992c8656ff683f68cdf205750e482140fffbd56e5ca7fcc3db5f47d53623366e244b793dff12cb79ff8fe09750dfca046a43012b5f71a1541972d715b9a43fdd8fe0ca61b6ce00e498d7b2add25c6d46090a445c547ac911cf81435c50c87320589f8a79ea260fa7400ddf46908b89085788a08adfeee1c0efb6304be13dcc5186c347609a698327b2040196db7a117d6379ca622fbc483a7d3d1129a8f3b66eb308cb15ffa74a2bbbc2e474597c6ef3d3012db45e9853b592468ee0341f13400bb1acba8eb89fdd3edc895e03317afedd33e775bbfc4a7a5a0681fc673b3ada518310968e3620cc33c825713d5b84164c09c9be7d226a0a16b6efb07903f299dac7ea141c7dc3eea414217362325198816659cc6b0ce45c1b9238d2f5797926914ad7c228b17480af091acbae1018c4709cd1000a7cdb84d1dbb6dbbbe182f2f15f2e5477b70f85875de098529c83be9f7e35de06fb6865b5d51ee9fdc530540edbf5979f3a69d673867a51ecc2b38f2b63e60f7ad597fe57c84fbf43521f878d18e8a20fa7460dcd0f1e816cb13b23c4277b604c1a44c55d025bc067775affa8f378770431621204863c0f18db2249ac28e7c2ac9dd393fed38af999ab64b92be6c86295cd6b2f9b7e729689f8e4b8bb4ce94940f8bca4898e83165d2731a27a8cb1b4a9350415298c9755ad0370055ef9f32f9a86019b5d8e6e69a1c82c2c8999bd3cfc3ac2d7584cb431c33a29d1941b2acf2167727dee2eb5e747af3206e2e32e641e2830cce65c04b16221e715f02169abc57fd5b346cf432b194093c1a3dbf61673fbcc2da75f8501737ff67c9aff3d684477e10981d66173d025c5d57d76be48342a0add80fb39f0329c140b4e2de8ce2db942b3d0aa90a0944bf59bb72de2156d444f9d6edb9bc5320f75d05ca561cbf477994478498138e0e2db5229ff72bdfe9af675cdad2c235623c1baa6e9506e54a4d4b6d0731b658361eb1c426c31a135444dd1d2242f39d972139da6fa1543a8f87067474c7bf4a07fbaff03d69749cc1a977fa2f617954717fa9e6660c0a025eff4175cbeee57af3bfee602b4d15feebb09b239de8d3d8171791686281805cfca78eca444f7a5d0792f9e6826beb33088cf03f59b6fd7be2309c83ae197bc828c5f6fc8f54d9622d044db4162f33696a9076c48eecdaf85 dd8pe32_big 8b47b3c7549885b8d4b73ded824cd9ccfdb4b0b58ee3474a013577923666cd2f1fdb5e1bf0e55199c8d5965b1ce9a6029572b17745bb20cc4e934f95707cb91807eac441180bc5f44409eec3a1bb37d6333d813bcdda7463f541e5b85c47ba8bf8baa2bfa2547ff45b865d1ea14bd8b76cd9620fcaa3c8632b2fc5abcee2ad77e80808aa7bbd8e9726766177b152756619167b956030c2f5ea3fdd4b9a2711c81202cfafb1f7b1af81f4cef069c0a1fd58cfd6bf3a4a2c14f04881839d1f0a41f54cb10d716a16e28b110fbe0eb891e588ee601e8474e592bf136850b54460a154fe51986a2f81ab29d1a8294990a3df506ced49f0e031119e5eaeadc44a7e1137a223b8cf14d457422db38db5d4c9fd994f3375b476160a95ded20d7d13750ee839bb68589a19088311cc5c5442b1a68e0ecc2689d2ffca746bb75e65bbf86af6353a3940f87d6d5b5e461ad2cd9d95a2993676adde6a70cb05a507d08c5e49357edf4cd218502900e8de5fe09df5da894f4a13e1d1faf0f2d5466ce508a425236fbe5bb2970701687704d9310bc9d83d07ea3f6b2f7714032aaa0399e56a53e4d8d0b146c83caf50c8bb47803fc946fa0ba6cf15ccca76da7b44c0e80af35c4dfdf02e50b0aa79388bf18087354c2f4116132d2bc603878e32ec05d095274ddc94e0459f09327a64f2d26a08ab4cf3d85c26577ff1c08b2cadddc353d89167b6c943fe8741daa0dbee2804c7ae6544c880b3de68d7819b363eb655785562c8463ca1f4df7acb146bb2fc5d8d2cdb29fe9e75e7beb1c0a2272d7a964ac86ee13cff6758028b5037a21f439a262a92fe2941dc2edf71f461b2b39176d61b2b768b9be5ecd1fcdaa8d6e255f462f41572006cf7fe06bb736c4c00c6f63071b7a1690a5009af0b003e1d2bf0b918d19188fc949e3b8ce5da2b3034482e6f1fd0d052bdbf9a83ac780c556936471d09d83179a24c5967fd13da0868aa47abaddac3056b2f1fb88321f81cedab1451e6604b1af32f62acc26e8990a4e52a05d7de8f84ec81fd40eafabbd8fa3aa892b343a2c25a58f34ba7871c54e852309f90879e178c78e78cf02942b0c92ea1c6393ef09b79bf40bad6d64cf226b2b79ffc24ad4bb5bc0e9456f6d790873aafd478b3dc11f03d0cf329f5a5784528942f735acce91adbefd592cec728557396daa3a861d70791b37331a387b81e3a647f83b16209e244ee4dce43bfed6a522f3821c7cee0005c203c31c2084780d59ac1ed742702a94c0380e9269f1562b467738c5dc667f126d7fe225b8a812e471c2ba6d2286d7f2b947673f6179fa7db3f53b45d41e74859ed42af979082de43a6f7d651c706e6fd31bab30bae48046bcad49b5c892255420b1738c5e72c3ae21666da3cb95dd7c31d5ba267be965f6f33f879b83e1d37156f62d1581327e19f74b843f0066bbb52c5eef04f75d08f54b5c2b8e25322efe7ebba43e66edc6657aa34d74c0c01749d0689fc2bd60261eaa175f6c90fbcd6b3e438302b22784d50a7268e3f7d0c54274ec9df89b6fd95675c7008ac0dbdb957557952065def1330f2da94805d57238da2cc6019c055e1645e72f49b3d3bda94ca9f03786ef56602a7a64c6c05951cae9937ffaf7261ebdf3454f5bee18def136550b4aa8206e7368add49022345efa55e0eed461f3e51397f3079e89152205cdcb5b0e5e85eada0c2dcbde7b8cfbfebb264106bebcba237f42124d038570cdf797bf898f101c47511006d6019762336e802020ad1ad83035a49cdcf15fbc3ec1ad540c2c1b468529eadc15cefc2268ce7bd11dca14b0f298ff07ee2bb6ccbbc2f78eed8a801cc361048b768377d49d42ccda9fafad20f9b84d276ad126c1e67399c20f56a361884203ce7ba42b67fdcc6ee400f5532c5af3c882974542e28ed6401a5aeb06665039ff81e29b6c12e4f585e81ecfb1f841dd11f3ce5101fcc2f4ae601259565c1df6eef99308c3333c81be21f870a109603b3cb8c422b805ef434136ca262cff2a78496daf011eaddbcd9c1eaf8748037e258c42709dacba8e677d0d24f3302a74eec69fc2be603ef87f3c7ab7bffb5979fe048504caa02e8933dead379f81e102cc4e5614b00e1a16b9c43d872462dda846e967e8478d5ce6e44b5c215750b4cfc408eda5ba82c9d8b9d09236170311a3e80f35bcf794b81cd5d04a83a42732bdda5ea6b0a7ccee7efd070ebf2940f62dfa7a8c7ef343299eaed3140e1ccc3749f4f834fad6cf76985f25387f0f3d6b3db8701d54a847125e4301bfb2b522de143ace9f23abf19d41b60130261be59010bda50cbe9979da5bcf122fc58eaa822fb3eadf14fdaecbe67d993171eb4b234ae6ae7247bf24e2459942c1bd27aedd7299d66272a426b19007a3a3b9b66bc2ab01a2090516b62cb8673a2e521c07b99e073ae99afa0d5486445f492203b16b233de70f0602dfab9f0e67398254a94f1997f258667beac21f1cc30f6306d269184beee5d3fb77a292a3d1029227f3d5d2db96c5d7d82b8f03f37e2f66e0a937f24d8482138de8de0abc36d409c944150dd96a6c5c12c0475804282d3a4f4c929685bceba20c71e18cbbf063980982d2d4b830b95a64cdee4b63d0a84be7af92f7a8decdd80ee5f7ecb09d7790c6a55598068bcdb45c6dbe3800aa1b1cc5c1525c0c6146f8422c434921061c3a2bdcd18e569efd859d5888db12358b905c2d7957173b98bf88708cfd3d5ab90cb1b6faf4bba5c00415dd9730291a9afbf46bbf9501454d64e932759cced3db72fdfdb55e5febcfd033856980ff6f9577aeeffc3d53f61d49d12614f868326179f3a24354a92cfab44a2e8735985d72bd495a90f919b623a9d223da2b155f744582f596c75e8571b53ce77ef4305585b93e7800f69e6dac3ad3782b7e5b3c586d8977b0dc6331a931d972e6c17d212c79f1111345bf0531fce195c699b832bd9611f8620ff0de38a372f7dbe00dc2205066eabe71e9d5810a7e2c404a53f44ede245ec9d492581afd81c152c0ea62660f92263c2ca267bf88001a64bedf5df26935fe4732e3cc6e1de36ef70374943d5cb831087dcda5087493abe71f147a09ba39466869e2b8837c6ab45bb516f2016f6634f7537976ecd92ca29224969b01a48e122aaecdba3f7b5fc950d1a58e78916697f9b1e5274cb91a84879e32613200515c7acd023f4a173fea56732c94a48ed0ec5ff3c5501e42109c1ca92dc7ae367d66f48648f5ee46bda796a1d577b215fc708999efbbaa3bed77cfa0b7b1b4aa39b313227cbc8a5ae0d9cb943d132957542f654b4b548c58b7ba65de98ab0f215afdd10fe3c1cfe5e68e2c8f0d4abdc5beafd135508663f4dafb188aa23742a3c35047c30c0493b8511d87e5685a5de63625147ba8d96386f8351b8b1f22cf5baf1fd04670941dd6e815837889b6339ef48ecdd7ff0bc09fe5a7fc4443af60d5635e02cb33ffb9a4785bcc17e8fad40ce0e886da7f38142aceb79198cd00bdcfc158d69875b7259563d486115bacff887fba60a9669a1a6ce41bf09991e4a84b82da626bbfda3386920f2cd0c16981b0c288a57153bdc2cb2bb17305d22aad6bfc38fc2893d918757f6ce31fb7e5b1863843ced5366f8fffb0d8911ae6d7f5d68ee748e924344cd04dda22c948df10fb3d18859dffbb27de63d63c44525a4ab2c9b43d1d861c5c15e461ed31874b5d74ba5fe1ab11ef63a86a736d8c30376a8aba5adc6c3db2350dbf562abe7f586fb9b6bf1a6200875fde0fad64da856d701a84d289b1e20719c99041cb29e69c7b7365f7b64ea050fbfa7395d985bfe2cb4094fef721813c5f956e1515518bb9ffdd79677b231779bb12bbb27a426725ecfdacb006244793959774b91798e6cbf7409f485df79d1f735e32b2bce38bbdb1148d11c759bf6ec3f0359e074788dd076c1340988ac9d03e2e6894fe6a37795eef246caa9761002d6a674851399c809102ee32bdc17785f83f428bb335dd8018e6d5a53f2962f9fd9b0590b959b575f53ec66d7126c11c0176faf866f40e419cc3630c6341dccefa2141840adce0b50c967f0bef0c02e46d15b18e7c50b315a39bf91f54c937620be6b1739825248da87308d528d8ca72717e7b444d86070c618ed397607e4d1656aef104bb0cc04811dfc1acdefadeb5685d52566bdc6e3e362c531a2a55e92f526820f1247afcb4d1ea34ba9136473cceaa26243fea69fb9c3f3549963b584098fa7766dc917bdc94f22a42aea58dd864860b79d974fcdd69944523b66ff87e18785f97f2e050e04289b81505891cd84d648c306fbf32b4dfaacb02fceb98bbe9fe8a3afe25d8693d95189e5367c80cbff3a799e0fa80bb1ac43c6df2dc29ae89a40cfa967e7808c44ae4ff44feb486363b6201f2c69531e2dc2c07809d0cca972a12f5a274ffc8c7f3e1a4d65138859d3e253471f14fb30ac089eeedd31515097c3c9f6d325ccb1b9b319852c8dbabd588802ad2a6c920a0c1834f618496b2ea20163f503dfbaa03de0c9b34b576aa32b166faae9163a50e6192b0a1c15719bef5b611067d4e17f72c07db460463926bc9e32dcd29c992c8656ff683f68cdf205750e482140fffbd56e5ca7fcc3dbb7aed53623366e244bebaeff12cb79ff8fe09750dfca446a43012b5f71a1541972d729b9a43fdd8fe0ca6150ce00e472d7b2add25c6d76090a445c547ac911cf81435c50c87320589f8a79ea260fa7407ddf46908b89085788a08adfeee100efb6304be13dcc5186c347609a69c327b2040196db7a117d6379ca622fbc483a7d3d1129a8f3b66eb308cb15ffa74a2bbbc2e474597c6ef3d3012db45e9853b592468ee0341f13400bb1acba8eb89fdd3edc895e03317afedd33e775bbfc4a7a5a0681fc673b3ada518310968e3620cc33c825713d5b84164c09c9be7d226a0a16b6efb07903f299dac7ea141c7dc3eeb203217362325198816659cc6b0ce45c1b9238d2f5797926914ad7c228a47497af091acbae1018c4709cd1001f7ccc84d1dbb6dbbbe182f2f15f2e4177b70f85875de085529c83be9f7e20de06fb6865b5d503e9fdc530540edbf5b79f3a69d673867a51ecc2b38f2b63e60f5ad597fe57c84fbf43d21f878d18e8a20fa7460dcd0f1e816cb13b23c4277b604c1ac4c55d025bc067775affa8f378770431621204863c0f18db2249ac28e7c2ac9dd393fed38af999ab64b92be6c86295cd6b2f9b7e729689f8e4b8bb4ce94940f8bca4898e83165d2731a27a8cb1b4a9350415298c9755ad0370055ef9f32f9a86019b5d8e6e69a1c82c2c8999bd3cfc3ac2d7584cb431c33a54af941b2acf2167727dee2eb5e747af3206e2e32e641e2830ebce5c04b16221e715212169ab107fd5b346cf432b194013c1a3dbf61673fbcc2da75ff901737ff67c9aff3d685477e10981d66173d025f5d57d76be48342a0add80fb39f032dc140b4e2de8ce2db942b3d0aa90a0944bf59bb72de2156d444f9d6edb9b85320f75d05ca561cbf477994478498138e0e2db5229ff72bdfe9af675cdad2c235623c1baa6e9506e54a4d4b6d0731b658361eb1c426c31a135444dd1d2242f39d972139da6fa1543a8f87067474c7bf4a07fbaff03d69749cc1a977fa2f617954717fa32cb60c0a025eff4175cbeee57af3bfee602b4d15feebb09b239de8d3d81dd791686281805cfca78eca444f7a57bd42f9e6826beb33088cf03f59b6f7cbe2309c83ae197bc828c5f6fc85f4d3a22d044dbf362f33696a9076ce2eecdaf85 aes_3blocks 4146515e10aa93a49d1a493158794739b144583e9885b4aa986e36a4d4aa5e5f495522e28b2bd443d1e1a47ee4fb4493 checksum 8a09eab5 huff_ok true huff_out 4869696969696969 bc_ops [Add(5), Xor(170), Rol(3), Inc] bc_lut256 7e666e161e060e363e262ed6dec6cef6fee6ee969e868eb6bea6ae555d454d757d656d151d050d353d252dd5ddc5cdf5fde5ed959d858db5bda5ad58604850788068701820081038402830d8e0c8d0f800e8f098a08890b8c0a8b0575f474f777f676f171f070f373f272fd7dfc7cff7ffe7ef979f878fb7bfa7af525a424a727a626a121a020a323a222ad2dac2caf2fae2ea929a828ab2baa2aa51594149717961691119010931392129d1d9c1c9f1f9e1e991998189b1b9a1a9545c444c747c646c141c040c343c242cd4dcc4ccf4fce4ec949c848cb4bca4ac535b434b737b636b131b030b333b232bd3dbc3cbf3fbe3eb939b838bb3bba3ab565e464e76 advance_key 00025e18 advance_key3 deaed18b [上一頁rust\_vectors.rs](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/rust_vectors.rs) [下一頁調試日誌示例](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/sample-debug-logs) 最後更新於 20 小時前 --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/primitives.py.md). # primitives.py 除分組密碼、解壓器與字節碼 VM 之外的全部數據變換——\[數據變換\](https://app.gitbook.com/s/sFi4W2Zr1UBoxZd5YI3A/shu-ju-bian-huan/data-transforms)中記載的各密碼與校驗和。 \`\`\`python """Reference implementations of the protection scheme's data transforms. Written for readability: every function mirrors the algorithm the loader executes at runtime, using plain Python with explicit 32-bit/8-bit wrapping (Python ints don't overflow, so masks are applied where the original uses fixed-width machine words). Conventions: - All buffers are bytearrays (mutable, like the loader's in-place passes). - get\_u32 / put\_u32 are little-endian, matching the x86 environment. """ # --------------------------------------------------------------------------- # Fixed-width helpers # --------------------------------------------------------------------------- MASK32 = 0xFFFFFFFF def get\_u16(d, off): return d\[off\] | (d\[off + 1\] << 8) def get\_u32(d, off): return d\[off\] | (d\[off + 1\] << 8) | (d\[off + 2\] << 16) | (d\[off + 3\] << 24) def put\_u32(d, off, value): value &= MASK32 d\[off:off + 4\] = value.to\_bytes(4, "little") def rol32(x, n): return ((x << n) | (x >> (32 - n))) & MASK32 def ror32(x, n): return ((x >> n) | (x << (32 - n))) & MASK32 def rol8(x, n): return ((x << n) | (x >> (8 - n))) & 0xFF def ror8(x, n): return ((x >> n) | (x << (8 - n))) & 0xFF # --------------------------------------------------------------------------- # Header key derivation (offset 4096 -> info\[8\]) # --------------------------------------------------------------------------- def header\_kdf(file\_data, offset=4096): """Derive the 8-dword info table from the encrypted header cells. info\[0\] is stored directly; every following cell is XORed with a rolling key that mixes in the cell value and the square of the index. """ info = \[0\] \* 8 info\[0\] = get\_u32(file\_data, offset) k = info\[0\] for i in range(7): cell = get\_u32(file\_data, offset + 4 + 4 \* i) info\[i + 1\] = k ^ cell k = (i \* i) ^ ((k + cell - i) & 0xFFFFFFFF) return info # --------------------------------------------------------------------------- # Rolling XOR chain over the payload body # --------------------------------------------------------------------------- def payload\_xor\_chain(file\_data, out, info, decrypt\_size): """Decrypt the bulk of the payload into the image buffer. Same rolling-key family as the header KDF, but the key is seeded from info\[0\] and the complement of the decrypted size, and advances with +i. """ base\_src = (info\[4\] + 4096) & MASK32 k = (info\[0\] + (~decrypt\_size & MASK32)) & MASK32 for i in range(decrypt\_size >> 2): cell = get\_u32(file\_data, (base\_src + 4 \* i) & MASK32) put\_u32(out, (info\[3\] + 4 \* i) & MASK32, k ^ cell) k = (i \* i) ^ ((k + cell + i) & MASK32) # --------------------------------------------------------------------------- # XOR + rotate-right dword cipher (rolling key), shift 19 or 21 # --------------------------------------------------------------------------- def xor\_ror\_dwords(d, pos, key, shift): """Decrypt a dword region described by the (addr, len) pair at \`pos\`. Used to unwrap each stage's pointer block. The key rolls forward by the loop index; the index is also subtracted after the rotation. """ base\_addr = get\_u32(d, pos) length = get\_u32(d, pos + 4) for i in range(length >> 2): off = (base\_addr + 4 \* i) & MASK32 v = get\_u32(d, off) ^ key key = (key + i) & MASK32 put\_u32(d, off, (ror32(v, shift) - i) & MASK32) # --------------------------------------------------------------------------- # Triple byte-rotate ciphers with two rolling keys # --------------------------------------------------------------------------- def byte\_rotate3(d, pos): """Descriptor-addressed variant: rotate by 3, keyed from the address.""" base\_addr = get\_u32(d, pos) length = get\_u32(d, pos + 4) b = ((base\_addr >> 8) + base\_addr) & 0xFF b2 = (b + 1) & 0xFF for i in range(length): idx = base\_addr + i x = rol8(d\[idx\], 3) ^ b2 x = rol8(x, 3) ^ b d\[idx\] = rol8(x, 3) b = (b + 1) & 0xFF b2 = (b2 + 1) & 0xFF def byte\_rotate2(d, va, size): """Position-keyed variant: rotate by 2, keyed from the address itself. Each output byte depends only on the input byte and the low 8 bits of its address, so any 4 bytes can be trial-decrypted without touching the rest of the buffer - a property the loader's table walks rely on. """ b = va & 0xFF b2 = (b + 1) & 0xFF for i in range(size): idx = va + i x = rol8(d\[idx\], 2) ^ b2 x = rol8(x, 2) ^ b d\[idx\] = rol8(x, 2) b = (b + 1) & 0xFF b2 = (b2 + 1) & 0xFF def trial\_byte\_rotate2(d, va): """Non-mutating 4-byte trial decrypt (relies on the no-cross-byte-state property of byte\_rotate2). Used to peek at encrypted descriptors.""" out = bytearray(4) for i in range(4): b = (va + i) & 0xFF x = rol8(d\[va + i\], 2) ^ ((b + 1) & 0xFF) x = rol8(x, 2) ^ b out\[i\] = rol8(x, 2) return get\_u32(out, 0) # --------------------------------------------------------------------------- # LFSR keystream (protects the embedded bytecode stubs) # --------------------------------------------------------------------------- def lfsr\_keystream(n): """n bytes of the LFSR keystream: seed 1, feedback 0x8003, 8 bits per output byte, LSB first. The stream is data-independent and can be replayed at any position.""" out = bytearray(n) state = 1 for i in range(n): b = 0 for k in range(8): b |= (state & 1) << k state = (state << 1) & MASK32 if state & 0x8000: state ^= 0x8003 out\[i\] = b return out def lfsr\_decrypt\_block(d, pos): """XOR a bytecode stub with the keystream. The block length is stored unencrypted at pos+95.""" length = d\[pos + 95\] ks = lfsr\_keystream(length) for i in range(length): d\[pos + i\] ^= ks\[i\] # --------------------------------------------------------------------------- # Import-name string cipher # --------------------------------------------------------------------------- def string\_cipher(d, pos, key): """Decrypt a NUL-terminated string in place: nibble swap, rolling subtract (step 67). The initial key is the low byte of the string RVA.""" i = 0 while d\[pos + i\] != 0: b = ror8(d\[pos + i\], 4) b = (b - key) & 0xFF if b == 0: b = (-key) & 0xFF d\[pos + i\] = b key = (key + 67) & 0xFF i += 1 # --------------------------------------------------------------------------- # Per-page .text scramble # --------------------------------------------------------------------------- def page\_scramble(d, va, size, key): """XOR one byte per 16-byte block across a page. Block 0 only advances the key. \`key\` is the page index shifted left by a build-specific amount (0 or 15).""" for i in range(size >> 4): mixed = (ror32(key, 15) + i) & MASK32 key = (mixed + i) & MASK32 if i == 0: continue d\[va + i \* 16 + (mixed & 0xF)\] ^= key & 0xFF def page\_scramble\_pe32(d, pa, page, big\_formula): """32-bit build variant. The page key is either (page+1) or 0x8000\*(page+1); the formula is not recorded anywhere in the file.""" key = (0x8000 \* (page + 1)) & MASK32 if big\_formula else page + 1 key = ror32(key, 15) for bi in range(1, 256): rk = ror32(key, 15) ri = (rk + bi) & MASK32 key = (ri + bi) & MASK32 d\[pa + bi \* 16 + (ri & 0xF)\] ^= key & 0xFF # --------------------------------------------------------------------------- # CRC-32 (standard reflected polynomial 0xEDB88320) # --------------------------------------------------------------------------- def \_build\_crc\_table(): table = \[\] for i in range(256): c = i for \_ in range(8): c = 0xEDB88320 ^ (c >> 1) if c & 1 else c >> 1 table.append(c) return table \_CRC\_TABLE = \_build\_crc\_table() def crc32\_append(initial, data): crc = ~initial & MASK32 for b in data: crc = \_CRC\_TABLE\[(crc ^ b) & 0xFF\] ^ (crc >> 8) return ~crc & MASK32 def crc32(data): return crc32\_append(0, data) def calculate\_checksum(d, pos): """crc32(region) ^ length, where (offset, length) is read from d\[pos\].""" offset = get\_u32(d, pos) length = get\_u32(d, pos + 4) return crc32(d\[offset:offset + length\]) ^ length # --------------------------------------------------------------------------- # Triangular-number key schedule (stage key "advance") # --------------------------------------------------------------------------- def advance\_key(key, iterations): """Roll a stage key forward: for m in 0..iterations, add every integer 1..(m+1)\*100. The constants make each stage's key depend on content that only exists after the previous stage decrypted correctly.""" for m in range(iterations): bound = ((m + 1) \* 25) << 2 for n in range(1, bound + 1): key = (key + n) & MASK32 return key \`\`\` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/primitives.py.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # vectors.txt | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/vectors.txt.md) . The expected outputs. Each line is `name hex-value`; the first two lines are the standard CRC-32 known answer (`crc32(b"123456789") == 0xCBF43926`) and its chained form — a cheap cross-check independent of the rest. GitBook Assistant GitBook AssistantAskCopy crc32_123456789 cbf43926 crc32_chain cbf43926 kdf_info a07f35c4 08c23441 788c7e3e e4fcee52 30c61262 a5f0b9a7 8d927c7a cd491cb3 dd3_shift19 6fa2a6a442b0c33a208e2427319316cebeaa48f9eccfe41b533a8d8f5d206d4b dd3_shift21 9ba829e90fecb0ce8623c989caa48533ac2a52bef733f946904ee3631248db12 dd4 154fe25134b3a830e267b8085ba330867daf4d3b03318746fee42c1d14766971 dd5 ae04d26a350937426de7e73c7d1fbabd432b327735f22eb57a8fb7e69f2427fd lfsr96 018000600028001e80086006a802fe8180606028281e9e886866aeaafc7f01e0004800368016e00ec80456837ee1e0484836b696f6eec6cc52d5fd9f01a8007e80206018280a9e8728629ea9a87efea0407830229419af4afc3701d6805ee038 dd6_len95 5ecf7642b0dc99bccc6aca4e29242cf04c3e3d06077f1a6248ff6d9297c8b10bc4c99fc54fc973b710e91462ebceccfed10ca234a18c8bb8b4954ffbda8641786025febcd0a19b36a034ebed2ef7fb42c25af0c9c80fda352a935161e249d6 dd7_cipher b88c817519bd507468ffa4d8 dd7_plain 4b45524e454c33322e646c6c dd8_shift0 8b47b3c7549885b8d4b73ded824cd9ccfdb6b0b58ee3474a013577923678cd2f1fdb7e1bf0e55199c8d5965b1ce9a6029572b17745bb20cc4e934fe5707cb91807eac441980bc5f44409eec3a1bb37d6333d813bcdda7463f541e5b85c07ba8bf8baa2bfa2547ff45b865d1ea14bd8b76cd9620fcaa3c8632b2fc5abcee2ad77e80808aa7bbd8e9726766177b152756619167b956030c2f5ea3fdd4b9a2711c81202cfafb1f7b1af81f4cef069c0a1fd58cfd6bf3a4a2c14f04881839d1f0a41f54cb10d716a16e28b110fbe66d191e588ee601e8466f692bf136850b54460a154fe91986a2f81ab29d1a82949901fdf506ced49f0e031779e5eaec7c44a7e1117a231b8cf14d457422db38db5d4c9fd994f3375b476160a95ded20d0d13750ee8391f68589a19088311a05c5442b1a68e0ecc2689d2ffca742bb75e65bbf86af6353a3940f87d0d5b5e461ad2cd9d95a2993676adde6a70cb05a507d08c5e49357edf4c5218502900e8de5fe09df5da894f4a13e1d1faf0f2d5466ce508a425236fbe5bb2970701687704d9310bc9d83d07ea3f6b2f7714032aaa0399e56a53e4d8d0b146c83caf50c8bb47803fc946fa0ba6cf15ccca76da7b44567f0af35c4dfdf02e50b0aa79388bf18087354c2f4116132d2bc603871b327b05d095274ddc94e0459f0932ef6465d26a08ab4cf3d85c26577ff1558b2cadddc353449167b6c943fe87d4daa0dbee2804c7336544c88000de68d7169b363eb655785562c8463ca1f4df7acb346bb2fc5d8d2cdb294e9e75e7beb1c0a2272d7a964ac86ee13cff6758028b5037a29f439a262a92fe29419c2edf71f461b2b39176d61b2b768b9be5ecd1fcdaa8d6e255f462f41572006cf7fe06bb736c4c00c6f63071b7a1690a5009af0b003e1d2bf0b918d19188fc949e3b8ce5da2b3034482e6f1fd0d052bdbf9a83ac780c556936471d09d83179a24c5967fd13da0868aa47abaddac30596d11fb88321f81cedab1451e6604b1af32f62acc26e8990a4428205d7de8f84ec81ac40eafaeed8fa3aa892b343a2c25a58f34ba7871c54e852309f6c879e178c78e78c4529e5b0c92ea1c6393ef09b49bf40bad6d64cf226b2b79ffc24ad49b5bc0e9456f6d7aa873aafd478b3dc11f03d0cf329f5a5784528942f731acce91adbefd592cec728557396faa3a861d70791b37331a387b81e3a647f83b16209e244ee4dce43bfedea522f3821c7cee0005c203c31c2084780d59ac1ed742702a94c0380e9269f1562b467738c5dc667f126d7fe225b8a812e471c2ba6d2286d7f07b97673f6179fa7db3f53b45d41e74859ed42af979082de43a6f7d651c72ae6fd31bab30bae48046bcad49b5ca22255420b1738c5e72c3ae21666da17955dd7c31d5ba267be965f6f33d279943e1d37246f62d1581327e19f5eb843f0066bbb60c5eef04f75d08f7eb5c2b8e25322efe7ebba43e626dc66578634d74c0c01749d0689fc2bd60261eaa115f6c90fbcd6b3e438a02b22784d50a7268e3f7d0c54274ec9df89b6fd95675c70082c0dbdb957557952061def1330f2da94805d57238da2cc6019c055e1645e72f49b3d3bda94ca9f03786ef56602a7a64c6c05951cae9937ffaf7261ebdf3454f5bee18def136550b4aa8206e7368add49022345efa55e0eed461f3e51397f3079e89152205cdcb5b0e5e85eada0c2dcbde7b8cfbfebb26410f978cba237f42124d0386a0cdf797bf898f101c47511006d6025762336e802020ad1ad64035aa3cdcf15fbc37d1ad54057c1b468529eadc15cefc2268ce7bd11dca14b0f638fcc7ee2bb6ccbbc2f78eed8b801cc361048b768377d49d42ccd3efafad20f9b84d2b9ad126c1e67f99c20f56a361884203ce7ba42b67f3cc6ee400f5532c5af3c882974542e28ed6401a5aeb06665039ff81e29b6c12e4f585e81ecfb1f841dd11f3c65101fcc2f4ae601259565c1df6eef99308c3333c81be21f870a109603b3cb8c422b805ef434136ca262cf30648496daf011eaddbcd9c1eaf8748037e258c42709dacba8e677d0d28ef102a74eec69fc2be603ef87f3076a7bffb5979fe048504caa02e893fdea1179f81e102cc4e5614b00e11e6b5d43d872462dda846e967e84786ace6e44b5c215b30b4cfc408eda5ba82c9d8b9d092361b7311a3e80f35bcfc68a81cd5d04a83a42732bdda5376b0a7ccec7efd070ebf2940f62dfa7a8c7ef343299eaed3140e1ccc3746f4f834fad6cf76985a58b87f0f3d6b3db8701d54a847125e4301bfb2b522de143ac28f03abf19d41b60130261be59010bda50cbe9979da5bcf122fc58eaa822fb3eadf14fdaecbe67d993171eb4b234ae6ae7247bf24e2459942c1bd27aedd7299d66272a426b19007a3a3b9b66bc2ab01a2090516b62cb8673a2e521c07b99e073ae99afa0d5486445f492203b16b233de58d9602dfab9f0e6734af64a94f1997f258667beac2171cc30f6306d269184beee5d43b77a292a3d102922593d5d2d936c5d7d8258f0ed37e2f66e0a937f24d8482138de8de0abc36d409c944150dd9656c5c12c0475e44282d3a4f4c929445bceba20c71e18cbbf063980982ded4b830b95a64cdee4b63d0a84be9af92f7a8decdd80ee5f7ecb09d7790c6a55598068bcdb45c6dbe3800a21b1cc5c1525c0c6146f8422c434921061c3a2bdcd18e569efd859d5888db12358b905c2d7957173b98bf88708cfd3d5ab90cb1b6faf4bba5c00415dd9730291a9afbf46bbf9501454d64e932759cced3db72fdfdb55e5a8ebfd033856980ff6f9577aeeffc3d53f61d49d12614f868326179f3a71351d92cfab44a2e8735985d72bd4c0a958919b623a9d223da2b155f7440d2f596c75e8574753ce77ef4305580e93e7800f69e6da9ead3782b796b3c5868f977b0dc6331a931d972e6c17d212c79f3111345bf0531fce19ec699b832bd9611f8620ff0de38a372f7dbe00dc2205066eab671e9d5810a7e2c404653f44ede245ec9d492581afd81c152c0ea62660f92263c2ca267bf88001a64bedf5df26935fe4732e3cc6e1de36ef70374943d5cb831087dcda5087493abe71f147a09ba39466869e2b8837c6ab45bb516f2016f6634f7537976ecd92ca29224969b01a48e122aaecdba3f7b5fc95b0a458e78916697f9b1e5274cb91a84879e32613200515c7acb74bf4a173fea56732d84a48ed1bc5ff3c5501e42109c10a92dc7ae367d66f48648f5e586bda796a1d577b545fa008999efbbaa3bed77cca0b7b1b4aa39b313227cbc8a5ae0d5eb943d1329575420c54b4b548c58b7ba65de98ab0f215afdd10fe3c1cfe9e68e2c8f0d4abdc5beafd135508463f4dafb188aa23742a3c35047c30c0493b8511d87e5685a5de636251c7ba8d96386f8351b8b1f22cf5baf1fd04670941dd6e815837889b6339ef48ecdd7ff0bc09fe5a7fc4443af60d5635e02cb33ffb9a4785bcc19262ad40ce0e886da7f38142aceb79198cd00bdcfc158d69875b7259563da46115bacff887fba60a9669a1a6ceaabf09991e4a84b82da626bbfda33882ccf2cd0c16981b0c288a57153b362c5ebb1730ac22aad6bfc38fc289d7918757f6ce31097e5b1863843cedb966f8fffb0d8911ae6d7f5d68e6748e92af44cd04dda22c948df10fb3d18859dffb527de63d63c44525a43b2c9b43d1d861c5c15e461ed31874b5d74ba5fe1ab11ef63a06a736d8c30376a8ab65adc6c3db2350dbf562abe7f586fb9b6bf1a6200875fde0fad64da856d701a84d289b1e20719c99041cb29e69c7b7365f7b64ea050fbfa7395d985bfe2cb4094fef721813c5f956e1515518bb9ffdd79677b231779bb12bbb27a426725ecfdacb006244793959774b91798e6cbf745ba785df79d1f735e32bd6ce38bbdb1148d11c759bf6ec3f03a5e074788dd076c134092fac9da9e2e6894fe6f27795eea746caa9761002d6a674851399c809102ee32bdc1d78a383f428bb335dd8018e6d4a53f2962f9fd9b0590b959b575f04ec66d7126c11c0986faf866f40a419cc3630c6341dccefa2141840adae0b50c967f0bef0c02e46d15b18e7c50b315a39bf91f54c937620be6b1739825248da87308d528d8ca7271767b444d86070c618ed397607e4d1656aef104bb0cc04811dfc1acdefadeb5685d52566bdc6e3e362c531a227dd92f526820f1247afcb4d1ea34ba9136473cceaa26243fea69fb9c372d69963b584098fa7766dc917bd49ce22a42aea58dd864860b79d974f4dd61b44523b66ff87e18785f97f51058f04289b81505891cd84d648c379fbf32b4dfaac362fceb98bbe9fe8a3afe25d8693d9510ee5367c80cbff3a061f0fa80bb1ac43c6df2dc29a759a40cfa947e7808c44ae4ff44feb486363b6201f2c69531e2dc2c07809a0cca972a12f5a274f7c8c7f3e1a4d65138859d3e253471f14fb30ac089eeedd3151d155c3c9f6d325ccb1525f19852c8dbabd588802ad2a6c920a0c1834f618496b2ea294f5f503dfbaa03de0c9b34b576aa32b166faae9163a50e6192b0a1c15719bef5b611067d4e17f72c07db460463926bc9e32dcd29c992c8656ff683f68cdf205750e482140fffbd56e5ca7fcc3db5f47d53623366e244b793dff12cb79ff8fe09750dfca046a43012b5f71a1541972d715b9a43fdd8fe0ca61b6ce00e498d7b2add2fc6de4090a445c547ac911cf81435c50c87320589f8a79ea260fa7400ddf46908b892c5788a08adfeee1ecefb6304be13dcc5186c347609a698327b2040196db7a117d6379ca624fbc483a7d3d1129a8f3b66eb308cb15ffa74a2bbbc2e474597c6ef3d3812db45e9853b592468ee0341f13400bb1acba8eb89fdd3edc895e03317afedd33e775bbfc4a7a5a0681fc673b3ada518310968e3620cc33c825713d5b84164c09c9be7d226a0a16b6efb07903f299dac7ea141c7dc3eea414217362325198816659cc6b0ce45c1b9238d2f5797926914ad7c228b17480af091acbae1018c4709cd1000a7cdb84d1dbb6dbbbe182f2f15f2e5477b70f85875dfc85529c83be9f7e35de06fb6865b5d51ee9fdc530670edbf5a09f3a69d673867a51ecc2b38f2b63e60f7ad597fe57c84fbf43621f878d18e8a20fa7460dcd0f1e816cb13b23c4277b604c1a44c55d025bc067775abfa8f378770431621204863c0f18db2249ac28e7c2ac9dd393fed38af999ab64b92be6c86295cd6b2f9b7e729689f8e4b8bb4ce94940f8bca4898e83165d2731a27a8cb1b4a9350415298c9755ad0370055ef9f32f9a86019b5d8e6e69a1c82c2c8999bd3cfc3ac2d7584cb431c33a29d1941b2acf2167727dee2eb5e747af3206e2e32e641e2830cce65c04b16221e715f02169abc57fd5b346cf432b194093c1a3dbf61673fbcc2da75f8501737ff67c9aff08687377e10981d66173d025c5d57d76be48342a0add80fb39f0325e140b4e2de8ce2d0342b3d0aa90a0944bf59bb72de2156d444f9d6edb9bc5320f75d05ca561cbf477994478698138e0e2db5229ff72bdfe9af675cdad2c235623c1baa6e9506e54a454b6d0731b658361eb1c426c31a135444dd1d2242f39d972139da6fa1543a8f87067474c7bf4a07fbaff03d69749cc1a977fa2f617954717fa9e6660c0a025eff4175cbeee57af3bfee602b4d15feebb09b239de8d3d8171791686281805cfca78eca444f7a5d0d42f9e6826beb33088cf03f59b6fd7122309c83ae197bc828c5f6fc8f54d9622d0446af362f33696a9076c48eecdaf85 dd8_shift15 8b47b3c7549885b8d4b73ded824cd9ccfdb4b0b58ee3474a013577923666cd2f1fdb7a1bf0e55199c8d5965b1ce986029572b17745bb20cc4e934f95707cb91807eac441080bc5f44409eec3a1bb37d6333d813bcdda7463f541e5b85c47ba8bf8baa2bfa2543ff45b865d1ea14bd8b76cd9620fcaa3c8632b2fc5abcee2ad77e80808aa7bbd8e9726766177b152756619167b956030c2f5ea3fdd4b9a2711c81202cfafb1f7b1af81f4cef069c0a1fd58cfd6bf3a4a2c14f04881839d1f0a41f54cb10d716a16e28b110fbe0eb891e588ee601e8474e592bf136850b54460a154fe51986a2f81ab29d1a8294990a3df506ced49f0e031119e5eaeadc44a7e1137a223b8cf14d457422db38db5d4c9fd994f3375b476160a95de190db013750ee839bb68589a19088311cc5c5442b1a68e5acc2689d2ffca7437b75e65bbf86af6353a3940f87d6d5b5e461ad2cd9d95a2993676ad3e6a70cb05a507d08c5e49357edf4cd218502900e8de5fe09df5da894fca13e1d1faf0f2d5466ce508a425236fbe5bb2970701687704d9310bc9d83d07ea3f6b2f7714032aaa0399e56a53e4d8d0b146c83caf50c8bb47803fc946fa0ba6cf15ccca76da7b44c0e80af35c4dfdf02e50b0aa79388bf18087354c2f4116132d2bc603878e32ec05d095274ddc94e0459f09327a64f2d26a08ab4cf3d85c26577ff1c08b2cadddc353d89167b6c943fe8741daa0dbee28045b336544c880b3de68d7819b363eb655785562c8463ca141df7acbad6bb2fc5d8d2cdb29fe9e75e7beb1c0a2272d7a964ac86ee13cff6758028b5037a22f439a262a92fe2941dc2edf71f461b2b39176d61b2b768b9be5ecd1fcdaa8d6e2553462f41572006cf7fe06bb736c4c00c6f63071b7a1690a5009af0b003e1d2bf0b918d19188fc949e3b8ce5da2b3034482e6f1fd0d052bdbf9a83ac780c556936471d09d83179a24c5967fd13da0868aa47abaddac3056b2f1fb88321f81cedab1451e6604b1af32f62acc26e8990a4e52a05d7de8f84ec81fd40eafabbd8fa3aa892b343a23d5a58f34ba7871c54e852309f90879e178c78e78cf02942b0c92ea1c6393ef09b1bbf40bad6d64cf226b2b79ffc24cd4bb5bc0e9456f6d790873aafd478b3dc11f03d0cf3291ca5784528942f73abcce91adbefd592cec728557396daa3a861d70791b37331a387b81e3a447f83b16209e244ee4dce43bfed6a522f3821c7cee0005c203c31c2884780d59ac1ed742702a94c0380e9269f1562b467738c5dc667f126d7fe225b8a812e471c2ba6d2286d7f2b947673f6179fa7db3f53b45d41e74859ed42af979082de43a6f7d651c706e6fd31bab30bae48046bcad49b5c892255420b1738c5e72c3ae21666da3cb95dd7c31d5ba267be965f6f33f879b83e1d37156f62d1581327e19f74b843f0066b8a60c5eef04f75d08f54b5c2b8e25322efe7ebba43e66edc6657aa34d74c0c01749d0689fc2bd64861eaa13bf6c90fbcd6b3e438302b22784d50a7268e3f7d0c54274ec9df89b6fd95675c7008dc0dbdb957557952065def1330f2da94805d97238da2cc6019c055e1645e72f49b3d3bda94ca9f03786ef56602a7a64c6c05951cae9937ffaf7261ebdf3454f5bee18def136550b4aa8206e7368add49022345efa55e0eed461f3e51397f3079e89152205cdcb5b0e5e85eada0c2dcbde7b8cfbfebb264106bebcba237f42124d038570cdf797bf898f101c47511006d6019762336e802020ad1ad83035a49cdcf15fbc3ec1ad540c2c1b468529eadc15cefc2268ce7bd11dca14b0f298ff07ee2bb6ccbbc2f7818d85001cc361048b768377d49d42ccda9fafad20f9b84d276ad126c1e67bf9c20f56a3618845e3ce7ba42b67fdcc6ee400f5532c5af3c882974544e28ed6401a5aeb06665039ff81e29b6c12e4f585e81ecfb1f841dd11f3ce5101fcc2f4ae601259565c1df6eef19308c3333c81be21f870a109603b3cb8c422b805ef434136ca262cff2a78496daf011eaddbcd9c1eaf8748037e258c42709dacba8e677d0d24f3302a74eec69fc2be603ef87f3c7ab7bffb5979fe048504caa02e8933dead379f81e102cc4e5614b00e1a16b9c43d872462dda846e967e8478d5ce6e44b5c215750b4cfc408eda5ba82c9d8b9d0923a7b7311a3e80f35bcf794b81cd5d04a83a42732bdda5ea6b0a7cce04efd070ebf2940f62dfa7a818ef343299eaed3140e1ccc3749f4f834fad6cf76985e25387f0f3d6b3db8701d54a847125e4301bfb2b522de143ace9f23abf19d41b601302a1be59010bda50cbe9979da5bcf122fc58eaa822fb3eadf14fdaecbe67d993171eb4b234ae6ae7247bf24e2459942c1bd27aedd7299d66272a426b19007a3a3b9b66bc2ab01a2090516b62cb8673a2e521c07b99e073ae99afa0d5486445f492203b16b233de70f0602dfab9f0e67398254a94f1997f258667beac21f1cc30f6306d269184beee5d3fb77a292a3d1029227f3d5d2db96c5d7d82b8f03f37e2f66e0a937f24d8482138de8de0abc36d409c94415056962bc5c12c0475804282d3a4f4c929685bceba20c71e0ccbbf063980982d314b830b95a64cdee4b63d0a84be7af92f7a8decdd80ee5f7ecb09d7190c6a55598068bcdb45c6dbe3800aa1b1cc5c1525c0c6146f8422c434121061c3a2bdcd18e569efd859d5888db12358b905c2d7957173b98bf88708cfd3d5ab90cb1b6faf4bba5c00415dd9730291a9afbf46bbf9501454d64e932759cced3db72fdfdb55e5febcfd033856980ff6f9577aeeffc3d53f61d49d12614f868326179f3a24354a92cfab44a2e8735985d72bd495a90f919b623a9d223da2b155f744582f596c75e8571b53ce77ef4305585b93e7800f69e6869ead3782b7e5b3c586d8977b0dc6331a931d972e6c17a712c79f6811345bf0531fce195c699b832bd9611f8620ff0de38a372f7dbe00dc2205066eabd71e9d5810a7e2c404a53f44ede245ec9d492581afd81c152c0ea62660f92263c2ca667bf88001a64bedf5df26935fe4732e3cc6e1de36ef70374943d5cb831087dcda5087493abe71f147a09ba39466869e2b8837c6ab45bb516f2016f6634f7537976ecd92ca29224969b01a48e122aaecdba3f7b5fc950d1a58e78916697f9b1e5274cb91a84879e32613200515c7acd023f4a173fea56732c94a48ed0ec5ff3c5501e421097e0a92dc7ae367d66f48648f5ee46bda796a1d577b215fc708999efbbaa3bed77cd80b7b1b4aa39b313227cbc8a5ae2d9cb943d132957542f654b4b548c58b7ba65de98ab0f2bcafdd10fe3c1cfeef68e2c8f0d4abdc5beafd135508663f4dafb188aa23742a3c35047c30e0493b8511d87e5685a5de63625147ba8d96386f8351b8b1f22cf5ba71fd04670941dd6e815837889b6339ef48ecdd7ff0bc09fe5a7fc4443af60d5635e02cb33ffb9a4785bcc17e8fad40ce0e886da7f38142aceb79198cd00bdcfc158d69875b7259563d486115bacff887fba60a9669a1a6ce41bf09991e4a84b82da626bbfda3386920f2cd0c16981b0c288a57153bdc2cb2bb17305d22aad6bfc38fc2893d918757f6cec0097e5b1863843ced5366f8fffb0d8911ae6d7f5d68ee748e924344cd04dda22c948df10fb3d18259dffbbc7de63d63c44525a4ab2c9b43d1d861c5c15e461ed31874b5d74ba5fe1ab11ef63a76a736d8c30376a8aba5adc6c3db2350dbf522abe7f586fb9b6bf1a6200875fde0fad64da856d701a84d289b1e20719c99041cb29e69c7b7365f7b64ea050fbfa7395d985bfe2cb4094fef721813c5f956e1515518bb9ffdd79677b231779bb12bbb27a426725ecfdacb006244793959774b91798e6cbf7409f485df79d1f735e32b2bce38bbdb1148d11c759bf6ec3f0359e074788dd076c1340988ac9d03e2e6894fe6a37795eef246caa9761002d6a674851399c809102ee32bdc17785f83f428bb335dd801386de253f2962f9fd9b0590b959b575f53ec66d7126c11c0176faf866f40a219cc3630c6341df2efa2141840adce0b50c967f0bef0c02e46d15b1807c50b315a39bf91f54c937620be6b1739825248da87308d528d8ca72717e7b444d86070c618ed397607e4d165eaef104bb0cc04811dfc1acdefadeb5685d52566bdc6e3e362c531a2a55e92f526820f1247afcb4d1ea34ba9136473cceaa26243fea69fb9c3f3549963b584098fa7766dc917bdc94f22a42aea58dd864860b79d974fcdd69944523b66ff87e18785f97f2e050e04289b81505891cd84d648c306fbf32b4dfaacb02fceb98bbe9fe8a3afe25d8693d9d70ee5367c80cbff3a799e0fa80bb1ac43c6df2dc29ae89a40cfa9c4e7808c44ae4ff44feb4863fcb6201f2c69531e2dc2c07809d0cca972a12f5a274fec8c7f3e1a4d65138859d3e253471f14fb30ac089eeedd31515097c3c9f6d325ccb1f9b319852c8dbabd588802ad2a6c920a0c1834f618496b2ea20163f503dfbaa03de0c9b34b576aa32b166faae9163a50e6192b0a1c15719bef5b611067d4e17f72c07db460463926bc9e32dcd29c992c8656ff683f68cdf205750e482140fffbd56e5ca7fcc3dbb7aed53623366e244bebaeff12cb79ff8fe09750dfca446a43012b5f71a1541972d729b9a43fdd8fe0ca6150ce00e472d7b2add25c6d76090a445c547ac911cf81435c50c87320589f8a79ea260fec4030df46908b89085788a08adfeee100efb6304be13d185186c347609a691f27b2040196db7a117d6379ca622fbc483a7d3d1129a8f3b66eb3082b15ffa74a2bbbc2e474597c6ef3d3012db45e9853b592468ee0341f13c00bb1acba8eb89fdd3edc895e03317afedd33e775bbfc4a7a5a0681fc673b3ada518310968e3620cc33c825713d5b84164c09c9be7d226a0a16b6efb07903f299dac7ea141c7dc3eeb203217362325198816659cc6b0ce45c1b9238d2f5797926914ad7c228a47497af091acbae1018c4709cd1001f7ccc84d1dbb6dbbbe182f2f15f2e4177b70f85875de085529c83be9f7e20de06fb6865b5c91ee9fdc530540edbf5b79f3a69d673867a51ecc2b38f1e63e60f63d597fe57c84fbf43d21f878d18e8a20fa7460dcd0f1e816cb13b23c4277b604c1af4c55d025bc067775affa8f378770431621204863c0f18db2249ac28e7c2ac9dd3933ed38af999ab64b92be6c86295cd6b2f9b7e729689f8e4b8bb4ce94940f8bca4898e83165d2731a27a8cb1b4a9350415298c9755ad0370055ef9f32f9a86019b5d8e6e69a1c82c2c8999bd3cfc3ac2d7584cb431c33a54af941b2acf2167727dee2eb5e747af3206e2e32e641e2830ebce5c04b16221e715212169ab107fd5b346cf432b193f93c1a3dbf61673fbcc2da75ff901737ff67c9aff3d685477e10981d66173d02517d57d76be48342a0add80fb39f0d2dc140b4e2de8ce2db942b3d0aa90a0944bf59bb72de27c6d444f9d6edb9bf4320f75d05ca561cbf477994478498138e0e2db5229ff72bdfe9af675edad2c235623c1baa6e9506e54a4d4b6d0731b658361eb1c426c31a1b5444dd1d2242f39d972139da6fa1543a8f87067474c7bf4a07fbaff03d69749cc1a977fa2f617954717fa32cb60c0a025eff4175cbeee57af3bfee602b4d15feebb09b239de8d3d81dd791686281805cfca78eca444f7a57bd42f9e6826beb33088cf03f59b6f7cbe2309c83ae197bc828c5f6fc85f4d3a22d044dbf362f33696a9076ce2eecdaf85 dd8pe32_small 8b47b3c7549885b8d4b73ded824cd9ccfd94b0b58ee3474a013577923666cd2f1fdb7e1bf0e55199c8d5965b1ce9a6029572b17745bb20cc4e934f15707cb91807eac441980bc5f44409eec3a1bb37d6333d813bcdda7463f541e5b85c47ba8bf8baa2bfa2547ff45b865d1ea14bd8b76cd9620fcaa3c8632b2fc5abcee2ad77e80808aa7bbd8e9726766177b152756619167b956030c2f5ea3fdd4b9a2711c81202cfafb1f7b1af81f4cef069c0a1fd58cfd6bf3a4a2c14f04881839d1f0a41f54cb10d716a16e28b110fbe66d191e588ee601e8466f692bf136850b54460a154fe91986a2f81ab29d1a82949901fdf506ced49f0e031779e5eaec7c44a7e1137a213b8cf14d457422db38db5d4c9fd994f3375b476160a95ded20d0d13750ee839bb68589a190883110c5c5442b1a68e0ecc2689d2ffca742bb75e65bbf86af6353a3940f87d6d5b5e461ad2cd9d95a2993676adde6a70cb05a507d08c5e49357edf4cd218502900e8de5fe09df5da894f4a13e1d1faf0f2d5466ce508a425236fbe5bb2970701687704d9310bc9d83d07ea3f6b2f7714032aaa0399e56a53e4d8d0b146c83caf50c8bb47803fc946fa0ba6cf15ccca76da7b44567f0af35c4dfdf02e50b0aa79388bf18087354c2f4116132d2bc603871b327b05d095274ddc94e0459f0932ef6465d26a08ab4cf3d85c26577ff1558b2cadddc353d80c67b6c943fe87d4daa0dbee2804c7336544c880b3de68d7a19b363eb655785562c8463ca1f4df7acb346bb2fc5d8d2cdb297e9e75e7beb1c0a2272d7a964ac86ee13cff6758028b5037a29f439a262a92fe2941dc2edf71f461b2b39176d61b2b768b9be5ecd1fcdaa8d6e255f462f41572006cf7fe06bb736c4c00c6f63071b7a1690a5009af0b003e1d2bf0b918d19188fc949e3b8ce5da2b3034482e6f1fd0d052bdbf9a83ac780c556936471d09d83179a24c5967fd13da0868aa47abaddac30596d11fb88321f81cedab1451e6604b1af32f62acc26e8990a4428205d7de8f84ec81ac40eafaeed8fa3aa892b343a2c25a58f34ba7871c54e852309f6c879e178c78e78cf02952b0c92ea1c6393ef09b49bf40bad6d64cf226b2b79ffc24ad0bb5bc0e9456f6d790873aafd478b3dc11f03d0cf329f5a5784528942f731acce91adbefd592cec728557396daa3a861d70791b37331a387b81e3a647f83b16209e244ee4dce43bfed6a522f3821c7cee0005c203c31c2084780d59ac1ed742702a94c0380e9269f1562b467738c5dc667f126d7fe225b8a812e471c2ba6d2286d7f07b97673f6179fa7db3f53b45d41e74859ed42af979082de43a6f7d651c72ae6fd31bab30bae48046bcad49b5ca20f55420b1738c5e72c3ae21666da17b95dd7c31d5ba267be965f6f33d279943e1d37155d62d1581327e19f5eb843f0066bbb60c5eef04f75d08f7eb5c2b8e25322efe7ebba43e66edc6657ca34d74c0c01749d0689fc2bd60261eaa115f6c90fbcd6b3e438b02b22784d50a7268e3f7d0c54274ec9df89b6fd95675c70082c0dbdb957557952065def1330f2da94805d57238da2cc6019c055e1645e72f49b3d3bda94ca9f03786ef56602a7a64c6c05951cae9937ffaf7261ebdf3454f5bee18def136550b4aa8206e7368add49022345efa55e0eed461f3e51397f3079e89152205cdcb5b0e5e85eada0c2dcbde7b8cfbfebb26410f978cba237f42124d0386a0cdf797bf898f101c47511006d6025762336e802020ad1ad64035a4926cf15fbc37d1ad54057c1b468529eadc15cefc2268ce7bd11dca14b0f298f807ee2bb6ccbbc2f78eed8b801cc361048b768377d49d42ccde9fafad20f9b84d276ad126c1e67f99c20f56a361884203ce7ba42b67fdcc6ee400f5532c5af3c882974542e28ed6401a5aeb06665039ff81e29b6c12e4f585e81ecfb1f841dd11f3ce5101fcc2f4ae601259565c1df6eef99308c3333c81be21f870a109603b3cb8c422b805ef434136ca262cf30648496daf011eaddbcd9c1eaf8748037e258c42709dacba8e677d0d28ef102a74eec69fc2be603ef87f3076a7bffb5979fe048504caa02e893fdea1179f81e102cc4e5614b00e11e6b5d43d872462dda846e967e84786ace6e44b5c21575cc4cfc408eda5ba82c9d8b9d092361b7311a3e80f35bcfc66b81cd5d04a83a42732bdda5ea6b0a7ccec7efd070ebf2940f62dfa7a8c7ef343299eaed3140e1ccc3741f4f834fad6cf76985a58b87f0f3d6b3db8701d54a847125e4301bfb2b522de143ace8f03abf19d41b60130261be59010bda50cbe9979da5bcf122fc58eaa822fb3eadf14fdaecbe67d993171eb4b234ae6ae7247bf24e2459942c1bd27aedd7299d66272a426b19007a3a3b9b66bc2ab01a2090516b62cb8673a2e521c07b99e073ae99afa0d5486445f492203b16b233de58d9602dfab9f0e6734af64a94f1997f258667beac2171cc30f6306d269184beee5d43b77a292a3d102922593d5d2d936c5d7d82b8f00f37e2f66e0a937f24d8482138de8de0abc36d409c944150dd9656c5c12c0475804282d3a4f4c929285bceba20c71e18cbbf063980982ded4b830b95a64cdee4b63d0a84be7af92f7a8decdd80ee5f7ecb09d7790c6a55598068bcdb45c6dbe3800aa1b1cc5c1525c0c6146f8422c434921061c3a2bdcd18e569efd859d5888db12358b905c2d7957173b98bf88708cfd3d5ab90cb1b6faf4bba5c00415dd9730291a9afbf46bbf9501454d64e932759cced3db72fdfdb55e5a8ebfd033856980ff6f9577aeeffc3d53f61d49d12614f868326179f3a71351d92cfab44a2e8735985d72bd4c0a958919b623a9d223da2b155f7440d2f596c75e8571b0ece77ef4305580e93e7800f69e6da9ead3782b7e5b3c586f8977b0dc6331a931d972e6c17d212c79f3111345bf0531fce19dc699b832bd9611f8620ff0de38a372f7dbe00dc2205066eab671e9d5810a7e2c404a53f44ede245ec9d492581afd81c152c0ea62660f92263c2ca267bf88001a64bedf5df26935fe4732e3cc6e1de36ef70374943d5cb831087dcda5087493abe71f147a09ba39466869e2b8837c6ab45bb516f2016f6634f7537976ecd92ca29224969b01a48e122aaecdba3f7b5fc95b0a458e78916697f9b1e5274cb91a84879e32613200515c7acb74bf4a173fea56732d84a48ed1bc5ff3c5501e42109c10a92dc7ae367d66f48648f5e586bda796a1d577b215fd708999efbbaa3bed77cca0b7b1b4aa39b313227cbc8a5ae0d5cb943d132957542f654b4b548c58b7ba65de98ab0f215afdd10fe3c1cfe9e68e2c8f0d4abdc5beafd135508663f4dafb188aa23742a3c35047c30c0493b8511d87e5685a5de63625147ba8d96386f8351b8b1f22cf5baf1fd04670941dd6e815837889b6339ef48ecdd7ff0bc09fe5a7fc4443af60d5635e02cb33ffb9a4785bcc19262ad40ce0e886da7f38142aceb79198cd00bdcfc158d69875b7259563da46115bacff887fba60a9669a1a6ceaa5209991e4a84b82da626bbfda3388220f2cd0c16981b0c288a57153b362c5ebb17305dd0aad6bfc38fc289d7918757f6ce31097e5b1863843cedb966f8fffb0d8911ae6d7f5d68ee748e92a344cd04dda22c948df10fb3d18859dffb527de63d63c44525a42b2c9b43d1d861c5c15e461ed31874b5d74ba5fe1ab11ef63a06a736d8c30376a8aba5adc6c3db2350dbf562abe7f586fb9b6bf1a6200875fde0fad64da856d701a84d289b1e20719c99041cb29e69c7b7365f7b64ea050fbfa7395d985bfe2cb4094fef721813c5f956e1515518bb9ffdd79677b231779bb12bbb27a426725ecfdacb006244793959774b91798e6cbf745ba785df79d1f735e32bd6ce38bbdb1148d11c759bf6ec3f03a5e074788dd076c134092fac9d0349e6894fe6f27795eea746caa9761002d6a674851399c809102ee32bdc1778af83f428bb335dd8018e6d4a53f2962f9fd9b0590b959b575f93ec66d7126c11c0176faf866f40a419cc3630c6341dccefa2141840adce0b50c967f0bef0c02e46d15b18e7c50b315a39bf91f54c937620be6b1739825248da87308d528d8ca72717e7b444d86070c618ed397607e4d1656aef104bb0cc04811dfc1acdefadeb5685d52566bdc6e3e362c531a227dd92f526820f1247afcb4d1ea34ba9136473cceaa26243fea69fb9c372d69963b584098fa7766dc917bd49ce22a42aea58dd864860b79d974f4dd61b44523b66ff87e18785f97f51058f04289b81505891cd84d648c379fbf32b4dfaacb0a8ceb98bbe9fe8a3afe25d8693d9510ee5367c80cbff3a06be0fa80bb1ac43c6df2dc29ae89a40cfa947e7808c44ae4ff44feb486363b6201f2c69531e2dc2c0780950cca972a12f5a274feb147f3e1a4d65138859d3e253471f14fb30ac089eeedd31519155c3c9f6d325ccb1525f19852c8dbabd588802ad2a6c920a0c1834f618496b2ea294f5f503dfbaa03de0c9b34b576aa32b166faae9163a50e6192b0a1c15719bef5b611067d4e17f72c07db460463926bc9e32dcd29c992c8656ff683f68cdf205750e482140fffbd56e5ca7fcc3db5f47d53623366e244b793dff12cb79ff8fe09750dfca046a43012b5f71a1541972d715b9a43fdd8fe0ca61b6ce00e498d7b2add25c6d46090a445c547ac911cf81435c50c87320589f8a79ea260fa7400ddf46908b89085788a08adfeee1c0efb6304be13dcc5186c347609a698327b2040196db7a117d6379ca622fbc483a7d3d1129a8f3b66eb308cb15ffa74a2bbbc2e474597c6ef3d3012db45e9853b592468ee0341f13400bb1acba8eb89fdd3edc895e03317afedd33e775bbfc4a7a5a0681fc673b3ada518310968e3620cc33c825713d5b84164c09c9be7d226a0a16b6efb07903f299dac7ea141c7dc3eea414217362325198816659cc6b0ce45c1b9238d2f5797926914ad7c228b17480af091acbae1018c4709cd1000a7cdb84d1dbb6dbbbe182f2f15f2e5477b70f85875de098529c83be9f7e35de06fb6865b5d51ee9fdc530540edbf5979f3a69d673867a51ecc2b38f2b63e60f7ad597fe57c84fbf43521f878d18e8a20fa7460dcd0f1e816cb13b23c4277b604c1a44c55d025bc067775affa8f378770431621204863c0f18db2249ac28e7c2ac9dd393fed38af999ab64b92be6c86295cd6b2f9b7e729689f8e4b8bb4ce94940f8bca4898e83165d2731a27a8cb1b4a9350415298c9755ad0370055ef9f32f9a86019b5d8e6e69a1c82c2c8999bd3cfc3ac2d7584cb431c33a29d1941b2acf2167727dee2eb5e747af3206e2e32e641e2830cce65c04b16221e715f02169abc57fd5b346cf432b194093c1a3dbf61673fbcc2da75f8501737ff67c9aff3d684477e10981d66173d025c5d57d76be48342a0add80fb39f0329c140b4e2de8ce2db942b3d0aa90a0944bf59bb72de2156d444f9d6edb9bc5320f75d05ca561cbf477994478498138e0e2db5229ff72bdfe9af675cdad2c235623c1baa6e9506e54a4d4b6d0731b658361eb1c426c31a135444dd1d2242f39d972139da6fa1543a8f87067474c7bf4a07fbaff03d69749cc1a977fa2f617954717fa9e6660c0a025eff4175cbeee57af3bfee602b4d15feebb09b239de8d3d8171791686281805cfca78eca444f7a5d0792f9e6826beb33088cf03f59b6fd7be2309c83ae197bc828c5f6fc8f54d9622d044db4162f33696a9076c48eecdaf85 dd8pe32_big 8b47b3c7549885b8d4b73ded824cd9ccfdb4b0b58ee3474a013577923666cd2f1fdb5e1bf0e55199c8d5965b1ce9a6029572b17745bb20cc4e934f95707cb91807eac441180bc5f44409eec3a1bb37d6333d813bcdda7463f541e5b85c47ba8bf8baa2bfa2547ff45b865d1ea14bd8b76cd9620fcaa3c8632b2fc5abcee2ad77e80808aa7bbd8e9726766177b152756619167b956030c2f5ea3fdd4b9a2711c81202cfafb1f7b1af81f4cef069c0a1fd58cfd6bf3a4a2c14f04881839d1f0a41f54cb10d716a16e28b110fbe0eb891e588ee601e8474e592bf136850b54460a154fe51986a2f81ab29d1a8294990a3df506ced49f0e031119e5eaeadc44a7e1137a223b8cf14d457422db38db5d4c9fd994f3375b476160a95ded20d7d13750ee839bb68589a19088311cc5c5442b1a68e0ecc2689d2ffca746bb75e65bbf86af6353a3940f87d6d5b5e461ad2cd9d95a2993676adde6a70cb05a507d08c5e49357edf4cd218502900e8de5fe09df5da894f4a13e1d1faf0f2d5466ce508a425236fbe5bb2970701687704d9310bc9d83d07ea3f6b2f7714032aaa0399e56a53e4d8d0b146c83caf50c8bb47803fc946fa0ba6cf15ccca76da7b44c0e80af35c4dfdf02e50b0aa79388bf18087354c2f4116132d2bc603878e32ec05d095274ddc94e0459f09327a64f2d26a08ab4cf3d85c26577ff1c08b2cadddc353d89167b6c943fe8741daa0dbee2804c7ae6544c880b3de68d7819b363eb655785562c8463ca1f4df7acb146bb2fc5d8d2cdb29fe9e75e7beb1c0a2272d7a964ac86ee13cff6758028b5037a21f439a262a92fe2941dc2edf71f461b2b39176d61b2b768b9be5ecd1fcdaa8d6e255f462f41572006cf7fe06bb736c4c00c6f63071b7a1690a5009af0b003e1d2bf0b918d19188fc949e3b8ce5da2b3034482e6f1fd0d052bdbf9a83ac780c556936471d09d83179a24c5967fd13da0868aa47abaddac3056b2f1fb88321f81cedab1451e6604b1af32f62acc26e8990a4e52a05d7de8f84ec81fd40eafabbd8fa3aa892b343a2c25a58f34ba7871c54e852309f90879e178c78e78cf02942b0c92ea1c6393ef09b79bf40bad6d64cf226b2b79ffc24ad4bb5bc0e9456f6d790873aafd478b3dc11f03d0cf329f5a5784528942f735acce91adbefd592cec728557396daa3a861d70791b37331a387b81e3a647f83b16209e244ee4dce43bfed6a522f3821c7cee0005c203c31c2084780d59ac1ed742702a94c0380e9269f1562b467738c5dc667f126d7fe225b8a812e471c2ba6d2286d7f2b947673f6179fa7db3f53b45d41e74859ed42af979082de43a6f7d651c706e6fd31bab30bae48046bcad49b5c892255420b1738c5e72c3ae21666da3cb95dd7c31d5ba267be965f6f33f879b83e1d37156f62d1581327e19f74b843f0066bbb52c5eef04f75d08f54b5c2b8e25322efe7ebba43e66edc6657aa34d74c0c01749d0689fc2bd60261eaa175f6c90fbcd6b3e438302b22784d50a7268e3f7d0c54274ec9df89b6fd95675c7008ac0dbdb957557952065def1330f2da94805d57238da2cc6019c055e1645e72f49b3d3bda94ca9f03786ef56602a7a64c6c05951cae9937ffaf7261ebdf3454f5bee18def136550b4aa8206e7368add49022345efa55e0eed461f3e51397f3079e89152205cdcb5b0e5e85eada0c2dcbde7b8cfbfebb264106bebcba237f42124d038570cdf797bf898f101c47511006d6019762336e802020ad1ad83035a49cdcf15fbc3ec1ad540c2c1b468529eadc15cefc2268ce7bd11dca14b0f298ff07ee2bb6ccbbc2f78eed8a801cc361048b768377d49d42ccda9fafad20f9b84d276ad126c1e67399c20f56a361884203ce7ba42b67fdcc6ee400f5532c5af3c882974542e28ed6401a5aeb06665039ff81e29b6c12e4f585e81ecfb1f841dd11f3ce5101fcc2f4ae601259565c1df6eef99308c3333c81be21f870a109603b3cb8c422b805ef434136ca262cff2a78496daf011eaddbcd9c1eaf8748037e258c42709dacba8e677d0d24f3302a74eec69fc2be603ef87f3c7ab7bffb5979fe048504caa02e8933dead379f81e102cc4e5614b00e1a16b9c43d872462dda846e967e8478d5ce6e44b5c215750b4cfc408eda5ba82c9d8b9d09236170311a3e80f35bcf794b81cd5d04a83a42732bdda5ea6b0a7ccee7efd070ebf2940f62dfa7a8c7ef343299eaed3140e1ccc3749f4f834fad6cf76985f25387f0f3d6b3db8701d54a847125e4301bfb2b522de143ace9f23abf19d41b60130261be59010bda50cbe9979da5bcf122fc58eaa822fb3eadf14fdaecbe67d993171eb4b234ae6ae7247bf24e2459942c1bd27aedd7299d66272a426b19007a3a3b9b66bc2ab01a2090516b62cb8673a2e521c07b99e073ae99afa0d5486445f492203b16b233de70f0602dfab9f0e67398254a94f1997f258667beac21f1cc30f6306d269184beee5d3fb77a292a3d1029227f3d5d2db96c5d7d82b8f03f37e2f66e0a937f24d8482138de8de0abc36d409c944150dd96a6c5c12c0475804282d3a4f4c929685bceba20c71e18cbbf063980982d2d4b830b95a64cdee4b63d0a84be7af92f7a8decdd80ee5f7ecb09d7790c6a55598068bcdb45c6dbe3800aa1b1cc5c1525c0c6146f8422c434921061c3a2bdcd18e569efd859d5888db12358b905c2d7957173b98bf88708cfd3d5ab90cb1b6faf4bba5c00415dd9730291a9afbf46bbf9501454d64e932759cced3db72fdfdb55e5febcfd033856980ff6f9577aeeffc3d53f61d49d12614f868326179f3a24354a92cfab44a2e8735985d72bd495a90f919b623a9d223da2b155f744582f596c75e8571b53ce77ef4305585b93e7800f69e6dac3ad3782b7e5b3c586d8977b0dc6331a931d972e6c17d212c79f1111345bf0531fce195c699b832bd9611f8620ff0de38a372f7dbe00dc2205066eabe71e9d5810a7e2c404a53f44ede245ec9d492581afd81c152c0ea62660f92263c2ca267bf88001a64bedf5df26935fe4732e3cc6e1de36ef70374943d5cb831087dcda5087493abe71f147a09ba39466869e2b8837c6ab45bb516f2016f6634f7537976ecd92ca29224969b01a48e122aaecdba3f7b5fc950d1a58e78916697f9b1e5274cb91a84879e32613200515c7acd023f4a173fea56732c94a48ed0ec5ff3c5501e42109c1ca92dc7ae367d66f48648f5ee46bda796a1d577b215fc708999efbbaa3bed77cfa0b7b1b4aa39b313227cbc8a5ae0d9cb943d132957542f654b4b548c58b7ba65de98ab0f215afdd10fe3c1cfe5e68e2c8f0d4abdc5beafd135508663f4dafb188aa23742a3c35047c30c0493b8511d87e5685a5de63625147ba8d96386f8351b8b1f22cf5baf1fd04670941dd6e815837889b6339ef48ecdd7ff0bc09fe5a7fc4443af60d5635e02cb33ffb9a4785bcc17e8fad40ce0e886da7f38142aceb79198cd00bdcfc158d69875b7259563d486115bacff887fba60a9669a1a6ce41bf09991e4a84b82da626bbfda3386920f2cd0c16981b0c288a57153bdc2cb2bb17305d22aad6bfc38fc2893d918757f6ce31fb7e5b1863843ced5366f8fffb0d8911ae6d7f5d68ee748e924344cd04dda22c948df10fb3d18859dffbb27de63d63c44525a4ab2c9b43d1d861c5c15e461ed31874b5d74ba5fe1ab11ef63a86a736d8c30376a8aba5adc6c3db2350dbf562abe7f586fb9b6bf1a6200875fde0fad64da856d701a84d289b1e20719c99041cb29e69c7b7365f7b64ea050fbfa7395d985bfe2cb4094fef721813c5f956e1515518bb9ffdd79677b231779bb12bbb27a426725ecfdacb006244793959774b91798e6cbf7409f485df79d1f735e32b2bce38bbdb1148d11c759bf6ec3f0359e074788dd076c1340988ac9d03e2e6894fe6a37795eef246caa9761002d6a674851399c809102ee32bdc17785f83f428bb335dd8018e6d5a53f2962f9fd9b0590b959b575f53ec66d7126c11c0176faf866f40e419cc3630c6341dccefa2141840adce0b50c967f0bef0c02e46d15b18e7c50b315a39bf91f54c937620be6b1739825248da87308d528d8ca72717e7b444d86070c618ed397607e4d1656aef104bb0cc04811dfc1acdefadeb5685d52566bdc6e3e362c531a2a55e92f526820f1247afcb4d1ea34ba9136473cceaa26243fea69fb9c3f3549963b584098fa7766dc917bdc94f22a42aea58dd864860b79d974fcdd69944523b66ff87e18785f97f2e050e04289b81505891cd84d648c306fbf32b4dfaacb02fceb98bbe9fe8a3afe25d8693d95189e5367c80cbff3a799e0fa80bb1ac43c6df2dc29ae89a40cfa967e7808c44ae4ff44feb486363b6201f2c69531e2dc2c07809d0cca972a12f5a274ffc8c7f3e1a4d65138859d3e253471f14fb30ac089eeedd31515097c3c9f6d325ccb1b9b319852c8dbabd588802ad2a6c920a0c1834f618496b2ea20163f503dfbaa03de0c9b34b576aa32b166faae9163a50e6192b0a1c15719bef5b611067d4e17f72c07db460463926bc9e32dcd29c992c8656ff683f68cdf205750e482140fffbd56e5ca7fcc3dbb7aed53623366e244bebaeff12cb79ff8fe09750dfca446a43012b5f71a1541972d729b9a43fdd8fe0ca6150ce00e472d7b2add25c6d76090a445c547ac911cf81435c50c87320589f8a79ea260fa7407ddf46908b89085788a08adfeee100efb6304be13dcc5186c347609a69c327b2040196db7a117d6379ca622fbc483a7d3d1129a8f3b66eb308cb15ffa74a2bbbc2e474597c6ef3d3012db45e9853b592468ee0341f13400bb1acba8eb89fdd3edc895e03317afedd33e775bbfc4a7a5a0681fc673b3ada518310968e3620cc33c825713d5b84164c09c9be7d226a0a16b6efb07903f299dac7ea141c7dc3eeb203217362325198816659cc6b0ce45c1b9238d2f5797926914ad7c228a47497af091acbae1018c4709cd1001f7ccc84d1dbb6dbbbe182f2f15f2e4177b70f85875de085529c83be9f7e20de06fb6865b5d503e9fdc530540edbf5b79f3a69d673867a51ecc2b38f2b63e60f5ad597fe57c84fbf43d21f878d18e8a20fa7460dcd0f1e816cb13b23c4277b604c1ac4c55d025bc067775affa8f378770431621204863c0f18db2249ac28e7c2ac9dd393fed38af999ab64b92be6c86295cd6b2f9b7e729689f8e4b8bb4ce94940f8bca4898e83165d2731a27a8cb1b4a9350415298c9755ad0370055ef9f32f9a86019b5d8e6e69a1c82c2c8999bd3cfc3ac2d7584cb431c33a54af941b2acf2167727dee2eb5e747af3206e2e32e641e2830ebce5c04b16221e715212169ab107fd5b346cf432b194013c1a3dbf61673fbcc2da75ff901737ff67c9aff3d685477e10981d66173d025f5d57d76be48342a0add80fb39f032dc140b4e2de8ce2db942b3d0aa90a0944bf59bb72de2156d444f9d6edb9b85320f75d05ca561cbf477994478498138e0e2db5229ff72bdfe9af675cdad2c235623c1baa6e9506e54a4d4b6d0731b658361eb1c426c31a135444dd1d2242f39d972139da6fa1543a8f87067474c7bf4a07fbaff03d69749cc1a977fa2f617954717fa32cb60c0a025eff4175cbeee57af3bfee602b4d15feebb09b239de8d3d81dd791686281805cfca78eca444f7a57bd42f9e6826beb33088cf03f59b6f7cbe2309c83ae197bc828c5f6fc85f4d3a22d044dbf362f33696a9076ce2eecdaf85 aes_3blocks 4146515e10aa93a49d1a493158794739b144583e9885b4aa986e36a4d4aa5e5f495522e28b2bd443d1e1a47ee4fb4493 checksum 8a09eab5 huff_ok true huff_out 4869696969696969 bc_ops [Add(5), Xor(170), Rol(3), Inc] bc_lut256 7e666e161e060e363e262ed6dec6cef6fee6ee969e868eb6bea6ae555d454d757d656d151d050d353d252dd5ddc5cdf5fde5ed959d858db5bda5ad58604850788068701820081038402830d8e0c8d0f800e8f098a08890b8c0a8b0575f474f777f676f171f070f373f272fd7dfc7cff7ffe7ef979f878fb7bfa7af525a424a727a626a121a020a323a222ad2dac2caf2fae2ea929a828ab2baa2aa51594149717961691119010931392129d1d9c1c9f1f9e1e991998189b1b9a1a9545c444c747c646c141c040c343c242cd4dcc4ccf4fce4ec949c848cb4bca4ac535b434b737b636b131b030b333b232bd3dbc3cbf3fbe3eb939b838bb3bba3ab565e464e76 advance_key 00025e18 advance_key3 deaed18b [Previousrust\_vectors.rs](https://xn--ri8h.gitbook.io/crackproof-research/reference/rust_vectors.rs) [NextSample debug logs](https://xn--ri8h.gitbook.io/crackproof-research/reference/sample-debug-logs) Last updated 1 day ago --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/detect.py.md). # detect.py \[識別與構建家族\](/crackproof-research/windows/zh-tw/file-structure/recognition.md)中記載的識別與分類邏輯。 \`\`\`python """Content-based detection and classification of a protected PE file. A protected file is recognized by content, never by name or extension: derive the 8-dword info table from offset 4096 and check the magic in info\[1\]. The PE header stays plaintext, so the usual PE fields classify the file further. """ MAGIC\_KONN = 0x4E4E4F4B # the shell stamp def get\_u16(d, off): return d\[off\] | (d\[off + 1\] << 8) def get\_u32(d, off): return d\[off\] | (d\[off + 1\] << 8) | (d\[off + 2\] << 16) | (d\[off + 3\] << 24) def header\_kdf(file\_data, offset=4096): info = \[0\] \* 8 info\[0\] = get\_u32(file\_data, offset) k = info\[0\] for i in range(7): cell = get\_u32(file\_data, offset + 4 + 4 \* i) info\[i + 1\] = k ^ cell k = (i \* i) ^ ((k + cell - i) & 0xFFFFFFFF) return info def detect(file\_data): """Return ("native-exe" | "managed-exe" | "native-dll" | "managed-dll", magic) for a protected file, or None when the file is not protected by this scheme.""" if len(file\_data) < 4128: return None pe\_off = get\_u32(file\_data, 0x3C) if file\_data\[pe\_off:pe\_off + 4\] != b"PE\\0\\0": return None info = header\_kdf(file\_data) if info\[1\] != MAGIC\_KONN: return None characteristics = get\_u16(file\_data, pe\_off + 4 + 18) # IMAGE\_FILE\_HEADER is\_dll = bool(characteristics & 0x2000) # IMAGE\_FILE\_DLL # COM descriptor (CLR) data directory: managed vs native, EXE and DLL alike. # Data directories start at optional-header +96 on PE32, +112 on PE32+. opt\_magic = get\_u16(file\_data, pe\_off + 24) # 0x10B / 0x20B dd\_base = 112 if opt\_magic == 0x20B else 96 clr\_rva = get\_u32(file\_data, pe\_off + 24 + dd\_base + 14 \* 8) managed = bool(clr\_rva) if is\_dll: return ("managed-dll" if managed else "native-dll", info\[1\]) return ("managed-exe" if managed else "native-exe", info\[1\]) \`\`\` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/detect.py.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/huffman.py.md). # huffman.py 用於 stage 與節數據塊的解壓器，見 \[Huffman 與 LZ 壓縮\](https://app.gitbook.com/s/sFi4W2Zr1UBoxZd5YI3A/shu-ju-bian-huan/compression)。 \`\`\`python """The Huffman/LZ hybrid decompressor. Compressed blocks carry their own decoding table at \`key\_offset\` in the same buffer. The table is a forest of 3-byte entries: +0 u16 symbol / child index +2 u8 accumulated code length in bits Root selection reads 8 bits (entry index = next 8 bits of input). An entry with the top bit (0x8000) set is a leaf: the low 15 bits are the token. A clear top bit means an internal node: the low 15 bits are the index of the first of a sibling pair, and one more input bit picks between them. The stored length byte counts the bits consumed so far (8 for a root), so a leaf reached after walking N internal levels has a total code length of 8 + N bits. Each token has a mode in its bits 8-9 and a payload in bits 0-7: 0x000 literal: emit the payload byte 0x100 count accumulator: append the payload to a big-endian pending value (emits nothing by itself) 0x200 run fill: repeat the previously written 1/2/4-byte unit pending \* payload times 0x300 LZ back-reference: copy \`payload\` bytes from (pending + payload) bytes behind the output cursor """ def get\_u16(d, off): return d\[off\] | (d\[off + 1\] << 8) def get\_u32(d, off): return d\[off\] | (d\[off + 1\] << 8) | (d\[off + 2\] << 16) | (d\[off + 3\] << 24) def put\_u16(d, off, value): d\[off:off + 2\] = (value & 0xFFFF).to\_bytes(2, "little") def put\_u32(d, off, value): d\[off:off + 4\] = (value & 0xFFFFFFFF).to\_bytes(4, "little") def decompress(d, src, dest, key\_offset, s\_size, d\_size): """Decompress s\_size bytes at \`src\` into d\_size bytes at \`dest\`, in place within buffer \`d\`. Returns True when exactly d\_size bytes were produced.""" bit\_pos = 0 buf = bytearray(d\[src:src + s\_size\]) + bytearray(3) # 3 bytes of slack buf\_off = 0 src\_consumed = 0 pending = 0 written = 0 while src\_consumed < s\_size and written < d\_size: word = get\_u32(buf, buf\_off) >> bit\_pos tab\_addr = key\_offset + (word & 0xFF) \* 3 tab = get\_u16(d, tab\_addr) if tab & 0x8000: # leaf: token is in the low 15 bits tab &= 0x7FFF bits = d\[tab\_addr + 2\] else: # internal node: walk down one bit per level bits = d\[tab\_addr + 2\] if bits >= 32: return False mask = 1 << bits bits += 1 idx = (tab & 0x7FFF) + (1 if word & mask else 0) t2 = get\_u16(d, key\_offset + idx \* 3) depth = 0 while not (t2 & 0x8000): depth += 1 if depth > 64: return False mask <<= 1 bits += 1 idx = (t2 & 0x7FFF) + (1 if word & mask else 0) t2 = get\_u16(d, key\_offset + idx \* 3) tab = t2 & 0x7FFF bit\_pos += bits advance = bit\_pos // 8 buf\_off += advance src\_consumed += advance bit\_pos %= 8 mode = tab & 0x300 payload = tab & 0xFF if mode == 0x000: # literal step = 1 d\[dest\] = payload elif mode == 0x100: # count accumulator step = 0 if pending >= 256: return False pending = payload if pending == 0 else (pending << 8) | payload elif mode == 0x200: # run fill if pending == 0: pending = 1 step = pending \* payload if step + written > d\_size: return False if payload == 1: if dest < 1: return False v = d\[dest - 1\] for k in range(pending): d\[dest + k\] = v elif payload == 2: if dest < 2: return False v = get\_u16(d, dest - 2) for k in range(pending): put\_u16(d, dest + k \* 2, v) elif payload == 4: if dest < 4: return False v = get\_u32(d, dest - 4) for k in range(pending): put\_u32(d, dest + k \* 4, v) else: return False pending = 0 else: # 0x300: LZ back-reference step = payload if written + payload > d\_size or pending + payload > written: return False back = pending + payload for k in range(payload): d\[dest + k\] = d\[dest + k - back\] pending = 0 dest += step written += step if bits == 0 and step == 0: return False return written == d\_size \`\`\` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/huffman.py.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # 验证与参考 | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/readme.md) . 本栏目以完整、可运行的形式发布 [CrackProof 内部机制](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/) 背后的参考材料。 GitBook Assistant 验证套件[](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn#yan-zheng-tao-jian) ------------------------------------------------------------------------------------------- 主文档中的每个 Python 片段在发布前都经过验证：每个函数的输出在相同输入上与算法的独立参考移植逐字节比对。完整套件——每个文件一页： GitBook Assistant 文件 作用 `primitives.py` GitBook Assistant 滚动密钥密码、字节旋转、LFSR、字符串密码、页置乱、CRC-32、校验和、三角调度 GitBook Assistant `aes_impl.py` GitBook Assistant 带缓冲区内置密钥调度的 AES-CBC 解密 GitBook Assistant `huffman.py` GitBook Assistant Huffman/LZ 混合解压器 GitBook Assistant `bytecode_vm.py` GitBook Assistant 逐构建字节码桩解码器/解释器及其逆变换 GitBook Assistant `detect.py` GitBook Assistant 基于内容的识别与分类 GitBook Assistant `run_tests.py` GitBook Assistant 比对工具（30 个向量） GitBook Assistant `rust_vectors.rs` GitBook Assistant 打印基准真值的独立参考移植 GitBook Assistant `vectors.txt` GitBook Assistant 比对工具所对照的期望输出 GitBook Assistant 要重跑全部比对，下载这些文件并执行 `python run_tests.py`。预期结果：`all vectors match`。 GitBook Assistant 参考捕获[](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn#can-kao-bu-huo) --------------------------------------------------------------------------------------- 调试日志示例——从受保护进程捕获的真实 CrackProof 调试日志，已脱敏：一个功能完整的宿主 EXE（页加密）、一个原生插件 DLL（仅整体解密）与一个托管 DLL。 GitBook Assistant [下一页primitives.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/primitives.py) 最后更新于 14小时前 * [验证套件](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn#yan-zheng-tao-jian) * [参考捕获](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn#can-kao-bu-huo) --- # 調試日誌示例 | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/sample-debug-logs.md) . 這些是真實的 CrackProof 調試日誌，捕獲方式是在 `%temp%` 下創建該可執行文件對應的 12 位十六進制字符文件夾並啟動受保護程序（見[調試日誌](https://app.gitbook.com/s/sFi4W2Zr1UBoxZd5YI3A/yun-xing-shi/startup-status) ）。路徑與產品名已替換為通用佔位符；其餘一切——選項標誌、狀態碼、地址、hook 列表——均為原文。 GitBook Assistant 如何閱讀日誌[](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/sample-debug-logs#ru-he-yue-du-ri-zhi) ---------------------------------------------------------------------------------------------------------------- * **第 1 行**——受保護模塊的路徑。 GitBook Assistant * **第 2 行**——該構建打包時使用的保護選項標誌（每個 `-XX` 記號對應一個打包器選項）。 GitBook Assistant * **第 3/4 行**——時間戳與模塊的加載基址。 GitBook Assistant * **後續行**——12 位[狀態碼](https://app.gitbook.com/s/sFi4W2Zr1UBoxZd5YI3A/yun-xing-shi/startup-status) ，每個 stage 一行；縮進的 `000`–`00N` 行攜帶 stage 特定的細節（地址、計數、被 hook 的函數）。 GitBook Assistant * **最後幾行**——完成時間戳與 9 位錯誤碼（`000-000-000` = 成功）。 GitBook Assistant 宿主 EXE——功能完整，頁加密[](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/sample-debug-logs#su-zhu-exe-gong-neng-wan-zheng-ye-jia-mi) ----------------------------------------------------------------------------------------------------------------------------------------------- GitBook Assistant詢問複製 E:\Package\app.exe -CF -CP -C2 -E2 -CC -T12 -RC3 -GWH -DA -DD -PP -I -EL5 -CK2 -CD1 -CD2 -CD3 -CD4 -EUT64 -DE -NCP2 -NC -NE -NCC2 -NRC -NDA3 -NEL -NEL2 -NEL3 -NEL4 -NELA -NEVS -NERR -NWEB -NEUT32 -NDEP1 -NDC -NPD 2026/05/15 04:55:07.178 00007FF7`B2850000 200 000 00001000 00000000 410 510 520 540 560 A03 561 C00 001 01A065F4 01A037AB C01 C02 C03 001 Htsysm7679 005 E0ED7281 FFFFF806 386C0000 A6D4B2B6 C04 004 05F8 00220000 003 03 00007FF9`2F7BAA40 kernel32.dll!CreateProcessInternalA 003 03 00007FF9`2DB4DCD0 kernelbase.dll!CreateProcessInternalA 003 03 00007FF9`2F7BAAC0 kernel32.dll!CreateProcessInternalW 003 03 00007FF9`2DB4E320 kernelbase.dll!CreateProcessInternalW 003 03 00007FF9`2F7A2E20 kernel32.dll!CreateRemoteThread 003 03 00007FF9`2DB6E050 kernelbase.dll!CreateRemoteThreadEx 003 03 00007FF9`304BF7C0 ntdll.dll!LdrLoadDll 003 03 00007FF9`305E2430 ntdll.dll!NtCreateSection 003 03 00007FF9`305E2CA0 ntdll.dll!NtAlpcSendWaitReceivePort 003 03 00007FF9`2F7A49A0 kernel32.dll!CreateActCtxW 003 03 00007FF9`2DBA1160 kernelbase.dll!CreateActCtxW 003 03 00007FF9`305E2270 ntdll.dll!NtDuplicateObject 003 03 00007FF9`305E2F60 ntdll.dll!NtConnectPort 003 03 00007FF9`305E1FB0 ntdll.dll!NtOpenProcess 003 03 00007FF9`305E4200 ntdll.dll!NtOpenThread A09 A0F A08 A07 002 01 00 5D0 552 570 001 00007FF9`2F79F7D0 00007FF7`B2933A50 00007FF7`B2933560 00007FF7`B2933740 00C 001F 00D 0000 0000 0000 0000 0000 0000 590 5B0 598 5A0 A06 003 23 00007FF9`2F9C3420 user32.dll!!SetFocus 003 03 00007FF9`2DA71C20 win32u.dll!NtUserSetFocus 003 03 00007FF9`26F25580 uxtheme.dll!!ThemeInitApiHook 003 03 00007FF9`2F97D310 user32.dll!CreateWindowExA 003 03 00007FF9`2F97D920 user32.dll!CreateWindowExW 5C0 5E1 610 640 655 6E1 800 001 00007FF7`B294DC00 810 820 840 002 00007FF7`B28F3010 00007FF7`B294B950 00007FF7`B294B820 001 04F0 660 280 2026/05/15 04:55:07.278 000-000-000 值得注意的點： GitBook Assistant * `C03` 給出驅動代際：`Htsysm7679`——第二代 Htsysm（見[內核驅動與子模塊](https://app.gitbook.com/s/sFi4W2Zr1UBoxZd5YI3A/yun-xing-shi/kernel-components) ）。 GitBook Assistant * `C04` 列出為 Protected-Process 開關 hook 的全部 API（`NtCreateSection`、`NtAlpcSendWaitReceivePort`、`NtDuplicateObject`、`NtConnectPort`、`NtOpenProcess`、`NtOpenThread`……）以及加載器攔截 hook（`CreateProcessInternal*`、`CreateRemoteThread*`、`LdrLoadDll`、`CreateActCtxW`）。 GitBook Assistant * `640 … 840`——該模塊是**頁加密**的：先整體解密，隨後重新加密並安裝異常處理 hook。`840` 之後的 `002` 行攜帶三個地址（重新加密的區間與處理程序數據）。 GitBook Assistant * `570` 與 `A06` 在啟動後期 hook 更多 API（`user32!SetFocus`、`CreateWindowExA/W`、`uxtheme!ThemeInitApiHook`）。 GitBook Assistant * `660` 是一個不在公開狀態表中的 stage——在此處出現於 `840` 與最終的 `280`（跳轉 OEP）之間。 GitBook Assistant 原生插件 DLL——僅整體解密[](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/sample-debug-logs#yuan-sheng-cha-jian-dll-jin-zheng-ti-jie-mi) ------------------------------------------------------------------------------------------------------------------------------------------------- 值得注意的點： GitBook Assistant * `A11`——DLL 的宿主進程檢查，僅存在於受保護 DLL。 GitBook Assistant * **沒有** `**640**`**/**`**840**`——該構建只整體解密一次（`610`），從不做頁加密；對比上面的宿主 EXE。頁加密是逐模塊的選項。 GitBook Assistant * `800` 攜帶單個地址——新填充的映像區域。 GitBook Assistant 託管 DLL——最簡序列[](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/sample-debug-logs#tuo-guan-dll-zui-jian-xu-lie) ------------------------------------------------------------------------------------------------------------------------------- 託管構建運行最短的流水線：環境檢查、節解密（`610`），然後直達 OEP（`280`）——無驅動初始化、無頁加密、無重定位 stage。 GitBook Assistant [上一頁vectors.txt](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/vectors.txt) 最後更新於 20 小時前 * [如何閱讀日誌](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/sample-debug-logs#ru-he-yue-du-ri-zhi) * [宿主 EXE——功能完整，頁加密](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/sample-debug-logs#su-zhu-exe-gong-neng-wan-zheng-ye-jia-mi) * [原生插件 DLL——僅整體解密](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/sample-debug-logs#yuan-sheng-cha-jian-dll-jin-zheng-ti-jie-mi) * [託管 DLL——最簡序列](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-tw/sample-debug-logs#tuo-guan-dll-zui-jian-xu-lie) GitBook Assistant詢問複製 E:\Package\app_Data\Plugins\native_plugin.dll -CF -C2 -E2 -CC -T12 -RC3 -GWH -DA -DD -PP -I -EL5 -CK2 -CD1 -CD2 -CD3 -CD4 -DE -NCP -NCP2 -NC -NE -NCC2 -NRC -NDA3 -NEL -NEL2 -NEL3 -NEL4 -NELA -NEVS -NERR -NWEB -NEUT32 -NEUT64 -NDEP1 -NDC -NPD 2026/05/15 04:55:14.518 00007FF8`31480000 200 000 00001000 00000000 510 540 560 A09 A11 5D0 A15 590 5B0 5A0 5C0 5E1 610 655 6E1 800 001 00007FF8`317C4000 830 280 2026/05/15 04:55:14.619 000-000-000 GitBook Assistant詢問複製 E:\Package\app_Data\Managed\Assembly-CSharp.dll -CF -CP -C2 -E2 -CC -T12 -RC3 -GWH -DA -DD -PP -I -EL5 -CK2 -CD1 -CD2 -CD3 -CD4 -EUT64 -DE -NCP2 -NC -NE -NCC2 -NRC -NDA3 -NEL -NEL2 -NEL3 -NEL4 -NELA -NEVS -NERR -NWEB -NEUT32 -NDEP1 -NDC -NPD 2026/05/15 04:55:09.342 00000174`0D290000 200 000 00001000 00000000 510 560 A09 A11 5D0 590 5B0 5A0 610 280 2026/05/15 04:55:09.368 000-000-000 --- # detect.py | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/detect.py.md) . [识别与构建家族](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/file-structure/recognition) 中记载的识别与分类逻辑。 GitBook Assistant GitBook Assistant询问复制 """Content-based detection and classification of a protected PE file. A protected file is recognized by content, never by name or extension: derive the 8-dword info table from offset 4096 and check the magic in info[1]. The PE header stays plaintext, so the usual PE fields classify the file further. """ MAGIC_KONN = 0x4E4E4F4B # the shell stamp def get_u16(d, off): return d[off] | (d[off + 1] << 8) def get_u32(d, off): return d[off] | (d[off + 1] << 8) | (d[off + 2] << 16) | (d[off + 3] << 24) def header_kdf(file_data, offset=4096): info = [0] * 8 info[0] = get_u32(file_data, offset) k = info[0] for i in range(7): cell = get_u32(file_data, offset + 4 + 4 * i) info[i + 1] = k ^ cell k = (i * i) ^ ((k + cell - i) & 0xFFFFFFFF) return info def detect(file_data): """Return ("native-exe" | "managed-exe" | "native-dll" | "managed-dll", magic) for a protected file, or None when the file is not protected by this scheme.""" if len(file_data) < 4128: return None pe_off = get_u32(file_data, 0x3C) if file_data[pe_off:pe_off + 4] != b"PE\0\0": return None info = header_kdf(file_data) if info[1] != MAGIC_KONN: return None characteristics = get_u16(file_data, pe_off + 4 + 18) # IMAGE_FILE_HEADER is_dll = bool(characteristics & 0x2000) # IMAGE_FILE_DLL # COM descriptor (CLR) data directory: managed vs native, EXE and DLL alike. # Data directories start at optional-header +96 on PE32, +112 on PE32+. opt_magic = get_u16(file_data, pe_off + 24) # 0x10B / 0x20B dd_base = 112 if opt_magic == 0x20B else 96 clr_rva = get_u32(file_data, pe_off + 24 + dd_base + 14 * 8) managed = bool(clr_rva) if is_dll: return ("managed-dll" if managed else "native-dll", info[1]) return ("managed-exe" if managed else "native-exe", info[1]) [上一页bytecode\_vm.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/bytecode_vm.py) [下一页run\_tests.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/run_tests.py) 最后更新于 21小时前 --- # detect.py | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/detect.py.md) . The detection and classification logic documented in [Recognition and build families](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/recognition) . GitBook Assistant GitBook AssistantAskCopy """Content-based detection and classification of a protected PE file. A protected file is recognized by content, never by name or extension: derive the 8-dword info table from offset 4096 and check the magic in info[1]. The PE header stays plaintext, so the usual PE fields classify the file further. """ MAGIC_KONN = 0x4E4E4F4B # the shell stamp def get_u16(d, off): return d[off] | (d[off + 1] << 8) def get_u32(d, off): return d[off] | (d[off + 1] << 8) | (d[off + 2] << 16) | (d[off + 3] << 24) def header_kdf(file_data, offset=4096): info = [0] * 8 info[0] = get_u32(file_data, offset) k = info[0] for i in range(7): cell = get_u32(file_data, offset + 4 + 4 * i) info[i + 1] = k ^ cell k = (i * i) ^ ((k + cell - i) & 0xFFFFFFFF) return info def detect(file_data): """Return ("native-exe" | "managed-exe" | "native-dll" | "managed-dll", magic) for a protected file, or None when the file is not protected by this scheme.""" if len(file_data) < 4128: return None pe_off = get_u32(file_data, 0x3C) if file_data[pe_off:pe_off + 4] != b"PE\0\0": return None info = header_kdf(file_data) if info[1] != MAGIC_KONN: return None characteristics = get_u16(file_data, pe_off + 4 + 18) # IMAGE_FILE_HEADER is_dll = bool(characteristics & 0x2000) # IMAGE_FILE_DLL # COM descriptor (CLR) data directory: managed vs native, EXE and DLL alike. # Data directories start at optional-header +96 on PE32, +112 on PE32+. opt_magic = get_u16(file_data, pe_off + 24) # 0x10B / 0x20B dd_base = 112 if opt_magic == 0x20B else 96 clr_rva = get_u32(file_data, pe_off + 24 + dd_base + 14 * 8) managed = bool(clr_rva) if is_dll: return ("managed-dll" if managed else "native-dll", info[1]) return ("managed-exe" if managed else "native-exe", info[1]) [Previousbytecode\_vm.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/bytecode_vm.py) [Nextrun\_tests.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/run_tests.py) Last updated 21 hours ago --- # Verification & reference | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/readme.md) . This section publishes the reference material behind [CrackProof internals](https://xn--ri8h.gitbook.io/crackproof-research/windows/) in its complete, runnable form. GitBook Assistant Verification suite[](https://xn--ri8h.gitbook.io/crackproof-research/reference#verification-suite) --------------------------------------------------------------------------------------------------- Every Python snippet in the main document was verified before publication: each function's output was compared byte-for-byte against an independent reference port of the algorithms on identical inputs. The full suite — one page per file: GitBook Assistant File Role `primitives.py` GitBook Assistant Rolling-key ciphers, byte rotations, LFSR, string cipher, page scramble, CRC-32, checksums, triangular schedule GitBook Assistant `aes_impl.py` GitBook Assistant AES-CBC decryption with the in-buffer key schedule GitBook Assistant `huffman.py` GitBook Assistant Huffman/LZ hybrid decompressor GitBook Assistant `bytecode_vm.py` GitBook Assistant Per-build bytecode stub decoder/interpreter and inverse GitBook Assistant `detect.py` GitBook Assistant Content-based detection and classification GitBook Assistant `run_tests.py` GitBook Assistant The comparison harness (30 vectors) GitBook Assistant `rust_vectors.rs` GitBook Assistant The independent reference port that prints ground truth GitBook Assistant `vectors.txt` GitBook Assistant The expected outputs the harness compares against GitBook Assistant To re-run the full comparison, download the files and execute `python run_tests.py`. Expected result: `all vectors match`. GitBook Assistant Reference captures[](https://xn--ri8h.gitbook.io/crackproof-research/reference#reference-captures) --------------------------------------------------------------------------------------------------- Sample debug logs — real CrackProof debug logs captured from a protected process, desensitized: a fully featured host EXE (page-encrypted), a native plugin DLL (bulk-decrypted only), and a managed DLL. GitBook Assistant [Nextprimitives.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/primitives.py) Last updated 14 hours ago * [Verification suite](https://xn--ri8h.gitbook.io/crackproof-research/reference#verification-suite) * [Reference captures](https://xn--ri8h.gitbook.io/crackproof-research/reference#reference-captures) --- # Sample debug logs | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/sample-debug-logs.md) . These are genuine CrackProof debug logs, captured by creating the per-executable 12-hex-character folder under `%temp%` and launching a protected title (see [Debug logging](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/startup-status#debug-logging) ). Paths and product names are replaced with generic placeholders; everything else — option flags, status codes, addresses, hook lists — is verbatim. GitBook Assistant Reading a log[](https://xn--ri8h.gitbook.io/crackproof-research/reference/sample-debug-logs#reading-a-log) ----------------------------------------------------------------------------------------------------------- * **Line 1** — the protected module's path. GitBook Assistant * **Line 2** — the protection option flags the build was packed with (each `-XX` token is one packer option). GitBook Assistant * **Line 3/4** — timestamp and the module's load base. GitBook Assistant * **Following lines** — 12-bit [status codes](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/startup-status#the-boot-sequence-and-status-codes) , one per stage; indented `000`– `00N` lines carry stage-specific detail (addresses, counts, hooked functions). GitBook Assistant * **Final lines** — completion timestamp and the 9-digit error code (`000-000-000` = success). GitBook Assistant Host EXE — fully featured, page-encrypted[](https://xn--ri8h.gitbook.io/crackproof-research/reference/sample-debug-logs#host-exe-fully-featured-page-encrypted) ---------------------------------------------------------------------------------------------------------------------------------------------------------------- GitBook AssistantAskCopy E:\Package\app.exe -CF -CP -C2 -E2 -CC -T12 -RC3 -GWH -DA -DD -PP -I -EL5 -CK2 -CD1 -CD2 -CD3 -CD4 -EUT64 -DE -NCP2 -NC -NE -NCC2 -NRC -NDA3 -NEL -NEL2 -NEL3 -NEL4 -NELA -NEVS -NERR -NWEB -NEUT32 -NDEP1 -NDC -NPD 2026/05/15 04:55:07.178 00007FF7`B2850000 200 000 00001000 00000000 410 510 520 540 560 A03 561 C00 001 01A065F4 01A037AB C01 C02 C03 001 Htsysm7679 005 E0ED7281 FFFFF806 386C0000 A6D4B2B6 C04 004 05F8 00220000 003 03 00007FF9`2F7BAA40 kernel32.dll!CreateProcessInternalA 003 03 00007FF9`2DB4DCD0 kernelbase.dll!CreateProcessInternalA 003 03 00007FF9`2F7BAAC0 kernel32.dll!CreateProcessInternalW 003 03 00007FF9`2DB4E320 kernelbase.dll!CreateProcessInternalW 003 03 00007FF9`2F7A2E20 kernel32.dll!CreateRemoteThread 003 03 00007FF9`2DB6E050 kernelbase.dll!CreateRemoteThreadEx 003 03 00007FF9`304BF7C0 ntdll.dll!LdrLoadDll 003 03 00007FF9`305E2430 ntdll.dll!NtCreateSection 003 03 00007FF9`305E2CA0 ntdll.dll!NtAlpcSendWaitReceivePort 003 03 00007FF9`2F7A49A0 kernel32.dll!CreateActCtxW 003 03 00007FF9`2DBA1160 kernelbase.dll!CreateActCtxW 003 03 00007FF9`305E2270 ntdll.dll!NtDuplicateObject 003 03 00007FF9`305E2F60 ntdll.dll!NtConnectPort 003 03 00007FF9`305E1FB0 ntdll.dll!NtOpenProcess 003 03 00007FF9`305E4200 ntdll.dll!NtOpenThread A09 A0F A08 A07 002 01 00 5D0 552 570 001 00007FF9`2F79F7D0 00007FF7`B2933A50 00007FF7`B2933560 00007FF7`B2933740 00C 001F 00D 0000 0000 0000 0000 0000 0000 590 5B0 598 5A0 A06 003 23 00007FF9`2F9C3420 user32.dll!!SetFocus 003 03 00007FF9`2DA71C20 win32u.dll!NtUserSetFocus 003 03 00007FF9`26F25580 uxtheme.dll!!ThemeInitApiHook 003 03 00007FF9`2F97D310 user32.dll!CreateWindowExA 003 03 00007FF9`2F97D920 user32.dll!CreateWindowExW 5C0 5E1 610 640 655 6E1 800 001 00007FF7`B294DC00 810 820 840 002 00007FF7`B28F3010 00007FF7`B294B950 00007FF7`B294B820 001 04F0 660 280 2026/05/15 04:55:07.278 000-000-000 Points of interest: GitBook Assistant * `C03` names the driver generation: `Htsysm7679` — the second-generation Htsysm (see [Kernel drivers and submodules](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/kernel-components) ). GitBook Assistant * `C04` lists every API hooked for the Protected-Process toggle (`NtCreateSection`, `NtAlpcSendWaitReceivePort`, `NtDuplicateObject`, `NtConnectPort`, `NtOpenProcess`, `NtOpenThread`, …) plus loader-interception hooks (`CreateProcessInternal*`, `CreateRemoteThread*`, `LdrLoadDll`, `CreateActCtxW`). GitBook Assistant * `640 … 840` — this module is **page-encrypted**: bulk decrypt, then re-encrypt with the exception-handler hook installed. The `002` line after `840` carries three addresses (the re-encrypted range and handler data). GitBook Assistant * `570` and `A06` hook additional APIs late in the boot (`user32!SetFocus`, `CreateWindowExA/W`, `uxtheme!ThemeInitApiHook`). GitBook Assistant * `660` is a stage not in the public status table — present here between `840` and the final `280` (jump to OEP). GitBook Assistant Native plugin DLL — bulk-decrypted only[](https://xn--ri8h.gitbook.io/crackproof-research/reference/sample-debug-logs#native-plugin-dll-bulk-decrypted-only) ------------------------------------------------------------------------------------------------------------------------------------------------------------- Points of interest: GitBook Assistant * `A11` — the DLL host-process check, present only for protected DLLs. GitBook Assistant * **No** `**640**`**/**`**840**` — this build is bulk-decrypted once (`610`) and never page-encrypted; compare the host EXE above. Page encryption is a per-module option. GitBook Assistant * `800` carries a single address — the freshly populated image region. GitBook Assistant Managed DLL — minimal sequence[](https://xn--ri8h.gitbook.io/crackproof-research/reference/sample-debug-logs#managed-dll-minimal-sequence) ------------------------------------------------------------------------------------------------------------------------------------------- The managed build runs the shortest pipeline: environment checks, section decryption (`610`), then straight to the OEP (`280`) — no driver init, no page encryption, no relocation stage. GitBook Assistant [Previousvectors.txt](https://xn--ri8h.gitbook.io/crackproof-research/reference/vectors.txt) Last updated 1 day ago * [Reading a log](https://xn--ri8h.gitbook.io/crackproof-research/reference/sample-debug-logs#reading-a-log) * [Host EXE — fully featured, page-encrypted](https://xn--ri8h.gitbook.io/crackproof-research/reference/sample-debug-logs#host-exe-fully-featured-page-encrypted) * [Native plugin DLL — bulk-decrypted only](https://xn--ri8h.gitbook.io/crackproof-research/reference/sample-debug-logs#native-plugin-dll-bulk-decrypted-only) * [Managed DLL — minimal sequence](https://xn--ri8h.gitbook.io/crackproof-research/reference/sample-debug-logs#managed-dll-minimal-sequence) GitBook AssistantAskCopy E:\Package\app_Data\Plugins\native_plugin.dll -CF -C2 -E2 -CC -T12 -RC3 -GWH -DA -DD -PP -I -EL5 -CK2 -CD1 -CD2 -CD3 -CD4 -DE -NCP -NCP2 -NC -NE -NCC2 -NRC -NDA3 -NEL -NEL2 -NEL3 -NEL4 -NELA -NEVS -NERR -NWEB -NEUT32 -NEUT64 -NDEP1 -NDC -NPD 2026/05/15 04:55:14.518 00007FF8`31480000 200 000 00001000 00000000 510 540 560 A09 A11 5D0 A15 590 5B0 5A0 5C0 5E1 610 655 6E1 800 001 00007FF8`317C4000 830 280 2026/05/15 04:55:14.619 000-000-000 GitBook AssistantAskCopy E:\Package\app_Data\Managed\Assembly-CSharp.dll -CF -CP -C2 -E2 -CC -T12 -RC3 -GWH -DA -DD -PP -I -EL5 -CK2 -CD1 -CD2 -CD3 -CD4 -EUT64 -DE -NCP2 -NC -NE -NCC2 -NRC -NDA3 -NEL -NEL2 -NEL3 -NEL4 -NELA -NEVS -NERR -NWEB -NEUT32 -NDEP1 -NDC -NPD 2026/05/15 04:55:09.342 00000174`0D290000 200 000 00001000 00000000 510 560 A09 A11 5D0 590 5B0 5A0 610 280 2026/05/15 04:55:09.368 000-000-000 --- # 调试日志示例 | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/sample-debug-logs.md) . 这些是真实的 CrackProof 调试日志，捕获方式是在 `%temp%` 下创建该可执行文件对应的 12 位十六进制字符文件夹并启动受保护程序（见[调试日志](https://app.gitbook.com/s/fEb9nKPvKsjkPAHMUbOt/yun-xing-shi/startup-status) ）。路径与产品名已替换为通用占位符；其余一切——选项标志、状态码、地址、hook 列表——均为原文。 GitBook Assistant 如何阅读日志[](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/sample-debug-logs#ru-he-yue-du-ri-zhi) ---------------------------------------------------------------------------------------------------------------- * **第 1 行**——受保护模块的路径。 GitBook Assistant * **第 2 行**——该构建打包时使用的保护选项标志（每个 `-XX` 记号对应一个打包器选项）。 GitBook Assistant * **第 3/4 行**——时间戳与模块的加载基址。 GitBook Assistant * **后续行**——12 位[状态码](https://app.gitbook.com/s/fEb9nKPvKsjkPAHMUbOt/yun-xing-shi/startup-status) ，每个 stage 一行；缩进的 `000`–`00N` 行携带 stage 特定的细节（地址、计数、被 hook 的函数）。 GitBook Assistant * **最后几行**——完成时间戳与 9 位错误码（`000-000-000` = 成功）。 GitBook Assistant 宿主 EXE——功能完整，页加密[](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/sample-debug-logs#su-zhu-exe-gong-neng-wan-zheng-ye-jia-mi) ----------------------------------------------------------------------------------------------------------------------------------------------- GitBook Assistant询问复制 E:\Package\app.exe -CF -CP -C2 -E2 -CC -T12 -RC3 -GWH -DA -DD -PP -I -EL5 -CK2 -CD1 -CD2 -CD3 -CD4 -EUT64 -DE -NCP2 -NC -NE -NCC2 -NRC -NDA3 -NEL -NEL2 -NEL3 -NEL4 -NELA -NEVS -NERR -NWEB -NEUT32 -NDEP1 -NDC -NPD 2026/05/15 04:55:07.178 00007FF7`B2850000 200 000 00001000 00000000 410 510 520 540 560 A03 561 C00 001 01A065F4 01A037AB C01 C02 C03 001 Htsysm7679 005 E0ED7281 FFFFF806 386C0000 A6D4B2B6 C04 004 05F8 00220000 003 03 00007FF9`2F7BAA40 kernel32.dll!CreateProcessInternalA 003 03 00007FF9`2DB4DCD0 kernelbase.dll!CreateProcessInternalA 003 03 00007FF9`2F7BAAC0 kernel32.dll!CreateProcessInternalW 003 03 00007FF9`2DB4E320 kernelbase.dll!CreateProcessInternalW 003 03 00007FF9`2F7A2E20 kernel32.dll!CreateRemoteThread 003 03 00007FF9`2DB6E050 kernelbase.dll!CreateRemoteThreadEx 003 03 00007FF9`304BF7C0 ntdll.dll!LdrLoadDll 003 03 00007FF9`305E2430 ntdll.dll!NtCreateSection 003 03 00007FF9`305E2CA0 ntdll.dll!NtAlpcSendWaitReceivePort 003 03 00007FF9`2F7A49A0 kernel32.dll!CreateActCtxW 003 03 00007FF9`2DBA1160 kernelbase.dll!CreateActCtxW 003 03 00007FF9`305E2270 ntdll.dll!NtDuplicateObject 003 03 00007FF9`305E2F60 ntdll.dll!NtConnectPort 003 03 00007FF9`305E1FB0 ntdll.dll!NtOpenProcess 003 03 00007FF9`305E4200 ntdll.dll!NtOpenThread A09 A0F A08 A07 002 01 00 5D0 552 570 001 00007FF9`2F79F7D0 00007FF7`B2933A50 00007FF7`B2933560 00007FF7`B2933740 00C 001F 00D 0000 0000 0000 0000 0000 0000 590 5B0 598 5A0 A06 003 23 00007FF9`2F9C3420 user32.dll!!SetFocus 003 03 00007FF9`2DA71C20 win32u.dll!NtUserSetFocus 003 03 00007FF9`26F25580 uxtheme.dll!!ThemeInitApiHook 003 03 00007FF9`2F97D310 user32.dll!CreateWindowExA 003 03 00007FF9`2F97D920 user32.dll!CreateWindowExW 5C0 5E1 610 640 655 6E1 800 001 00007FF7`B294DC00 810 820 840 002 00007FF7`B28F3010 00007FF7`B294B950 00007FF7`B294B820 001 04F0 660 280 2026/05/15 04:55:07.278 000-000-000 值得注意的点： GitBook Assistant * `C03` 给出驱动代际：`Htsysm7679`——第二代 Htsysm（见[内核驱动与子模块](https://app.gitbook.com/s/fEb9nKPvKsjkPAHMUbOt/yun-xing-shi/kernel-components) ）。 GitBook Assistant * `C04` 列出为 Protected-Process 开关 hook 的全部 API（`NtCreateSection`、`NtAlpcSendWaitReceivePort`、`NtDuplicateObject`、`NtConnectPort`、`NtOpenProcess`、`NtOpenThread`……）以及加载器拦截 hook（`CreateProcessInternal*`、`CreateRemoteThread*`、`LdrLoadDll`、`CreateActCtxW`）。 GitBook Assistant * `640 … 840`——该模块是**页加密**的：先整体解密，随后重新加密并安装异常处理 hook。`840` 之后的 `002` 行携带三个地址（重新加密的区间与处理程序数据）。 GitBook Assistant * `570` 与 `A06` 在启动后期 hook 更多 API（`user32!SetFocus`、`CreateWindowExA/W`、`uxtheme!ThemeInitApiHook`）。 GitBook Assistant * `660` 是一个不在公开状态表中的 stage——在此处出现于 `840` 与最终的 `280`（跳转 OEP）之间。 GitBook Assistant 原生插件 DLL——仅整体解密[](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/sample-debug-logs#yuan-sheng-cha-jian-dll-jin-zheng-ti-jie-mi) ------------------------------------------------------------------------------------------------------------------------------------------------- 值得注意的点： GitBook Assistant * `A11`——DLL 的宿主进程检查，仅存在于受保护 DLL。 GitBook Assistant * **没有** `**640**`**/**`**840**`——该构建只整体解密一次（`610`），从不做页加密；对比上面的宿主 EXE。页加密是逐模块的选项。 GitBook Assistant * `800` 携带单个地址——新填充的映像区域。 GitBook Assistant 托管 DLL——最简序列[](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/sample-debug-logs#tuo-guan-dll-zui-jian-xu-lie) ------------------------------------------------------------------------------------------------------------------------------- 托管构建运行最短的流水线：环境检查、节解密（`610`），然后直达 OEP（`280`）——无驱动初始化、无页加密、无重定位 stage。 GitBook Assistant [上一页vectors.txt](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/vectors.txt) 最后更新于 12小时前 * [如何阅读日志](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/sample-debug-logs#ru-he-yue-du-ri-zhi) * [宿主 EXE——功能完整，页加密](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/sample-debug-logs#su-zhu-exe-gong-neng-wan-zheng-ye-jia-mi) * [原生插件 DLL——仅整体解密](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/sample-debug-logs#yuan-sheng-cha-jian-dll-jin-zheng-ti-jie-mi) * [托管 DLL——最简序列](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/sample-debug-logs#tuo-guan-dll-zui-jian-xu-lie) GitBook Assistant询问复制 E:\Package\app_Data\Plugins\native_plugin.dll -CF -C2 -E2 -CC -T12 -RC3 -GWH -DA -DD -PP -I -EL5 -CK2 -CD1 -CD2 -CD3 -CD4 -DE -NCP -NCP2 -NC -NE -NCC2 -NRC -NDA3 -NEL -NEL2 -NEL3 -NEL4 -NELA -NEVS -NERR -NWEB -NEUT32 -NEUT64 -NDEP1 -NDC -NPD 2026/05/15 04:55:14.518 00007FF8`31480000 200 000 00001000 00000000 510 540 560 A09 A11 5D0 A15 590 5B0 5A0 5C0 5E1 610 655 6E1 800 001 00007FF8`317C4000 830 280 2026/05/15 04:55:14.619 000-000-000 GitBook Assistant询问复制 E:\Package\app_Data\Managed\Assembly-CSharp.dll -CF -CP -C2 -E2 -CC -T12 -RC3 -GWH -DA -DD -PP -I -EL5 -CK2 -CD1 -CD2 -CD3 -CD4 -EUT64 -DE -NCP2 -NC -NE -NCC2 -NRC -NDA3 -NEL -NEL2 -NEL3 -NEL4 -NELA -NEVS -NERR -NWEB -NEUT32 -NDEP1 -NDC -NPD 2026/05/15 04:55:09.342 00000174`0D290000 200 000 00001000 00000000 510 560 A09 A11 5D0 590 5B0 5A0 610 280 2026/05/15 04:55:09.368 000-000-000 --- # huffman.py | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/huffman.py.md) . 用于 stage 与节数据块的解压器，见 [Huffman 与 LZ 压缩](https://app.gitbook.com/s/fEb9nKPvKsjkPAHMUbOt/shu-ju-bian-huan/compression) 。 GitBook Assistant GitBook Assistant询问复制 """The Huffman/LZ hybrid decompressor. Compressed blocks carry their own decoding table at `key_offset` in the same buffer. The table is a forest of 3-byte entries: +0 u16 symbol / child index +2 u8 accumulated code length in bits Root selection reads 8 bits (entry index = next 8 bits of input). An entry with the top bit (0x8000) set is a leaf: the low 15 bits are the token. A clear top bit means an internal node: the low 15 bits are the index of the first of a sibling pair, and one more input bit picks between them. The stored length byte counts the bits consumed so far (8 for a root), so a leaf reached after walking N internal levels has a total code length of 8 + N bits. Each token has a mode in its bits 8-9 and a payload in bits 0-7: 0x000 literal: emit the payload byte 0x100 count accumulator: append the payload to a big-endian pending value (emits nothing by itself) 0x200 run fill: repeat the previously written 1/2/4-byte unit pending * payload times 0x300 LZ back-reference: copy `payload` bytes from (pending + payload) bytes behind the output cursor """ def get_u16(d, off): return d[off] | (d[off + 1] << 8) def get_u32(d, off): return d[off] | (d[off + 1] << 8) | (d[off + 2] << 16) | (d[off + 3] << 24) def put_u16(d, off, value): d[off:off + 2] = (value & 0xFFFF).to_bytes(2, "little") def put_u32(d, off, value): d[off:off + 4] = (value & 0xFFFFFFFF).to_bytes(4, "little") def decompress(d, src, dest, key_offset, s_size, d_size): """Decompress s_size bytes at `src` into d_size bytes at `dest`, in place within buffer `d`. Returns True when exactly d_size bytes were produced.""" bit_pos = 0 buf = bytearray(d[src:src + s_size]) + bytearray(3) # 3 bytes of slack buf_off = 0 src_consumed = 0 pending = 0 written = 0 while src_consumed < s_size and written < d_size: word = get_u32(buf, buf_off) >> bit_pos tab_addr = key_offset + (word & 0xFF) * 3 tab = get_u16(d, tab_addr) if tab & 0x8000: # leaf: token is in the low 15 bits tab &= 0x7FFF bits = d[tab_addr + 2] else: # internal node: walk down one bit per level bits = d[tab_addr + 2] if bits >= 32: return False mask = 1 << bits bits += 1 idx = (tab & 0x7FFF) + (1 if word & mask else 0) t2 = get_u16(d, key_offset + idx * 3) depth = 0 while not (t2 & 0x8000): depth += 1 if depth > 64: return False mask <<= 1 bits += 1 idx = (t2 & 0x7FFF) + (1 if word & mask else 0) t2 = get_u16(d, key_offset + idx * 3) tab = t2 & 0x7FFF bit_pos += bits advance = bit_pos // 8 buf_off += advance src_consumed += advance bit_pos %= 8 mode = tab & 0x300 payload = tab & 0xFF if mode == 0x000: # literal step = 1 d[dest] = payload elif mode == 0x100: # count accumulator step = 0 if pending >= 256: return False pending = payload if pending == 0 else (pending << 8) | payload elif mode == 0x200: # run fill if pending == 0: pending = 1 step = pending * payload if step + written > d_size: return False if payload == 1: if dest < 1: return False v = d[dest - 1] for k in range(pending): d[dest + k] = v elif payload == 2: if dest < 2: return False v = get_u16(d, dest - 2) for k in range(pending): put_u16(d, dest + k * 2, v) elif payload == 4: if dest < 4: return False v = get_u32(d, dest - 4) for k in range(pending): put_u32(d, dest + k * 4, v) else: return False pending = 0 else: # 0x300: LZ back-reference step = payload if written + payload > d_size or pending + payload > written: return False back = pending + payload for k in range(payload): d[dest + k] = d[dest + k - back] pending = 0 dest += step written += step if bits == 0 and step == 0: return False return written == d_size [上一页aes\_impl.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/aes_impl.py) [下一页bytecode\_vm.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/bytecode_vm.py) 最后更新于 1天前 --- # 存儲佈局 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/metadata/storage-layouts.md) . 部署中可以看到兩種存儲方式： GitBook Assistant 方式 字節位置 識別方式 外置 GitBook Assistant 運行時加載的獨立元數據文件 GitBook Assistant 文件以 IL2CPP 魔數開頭，版本和表佈局有效 GitBook Assistant 嵌入式 GitBook Assistant 原生庫容器中的受保護記錄 GitBook Assistant 記錄解碼後具有相同魔數、版本和表關係 GitBook Assistant 存儲位置會改變字節的定位方式，但不會改變元數據表的解釋方式。提取時保留源位置記錄，再把字節範圍交給同一個元數據校驗器。只有魔數而沒有一致偏移的候選不會接受。 GitBook Assistant [上一頁方法令牌](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/metadata/method-tokens) [下一頁概覽](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/analysis/analysis) 最後更新於 20 小時前 --- # CrackProof for Android SO internals | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/readme.md) . This Space describes the Android native-library format used by CrackProof. It focuses on ELF64 little-endian AArch64 files, the private protection section, the staged record streams, and the information needed to reconstruct a usable ELF image. GitBook Assistant The format is related to the Windows family but is not a PE variant. Android-specific checks, section names, stream records, and metadata rules are therefore documented separately. GitBook Assistant Contents[](https://xn--ri8h.gitbook.io/crackproof-research/android-so#contents) -------------------------------------------------------------------------------- Area What it covers [File format](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/file-format) GitBook Assistant ELF recognition, the protected section, and the two-stage stream layout GitBook Assistant [Data transforms](https://xn--ri8h.gitbook.io/crackproof-research/android-so/data-transforms/data-transforms) GitBook Assistant Header arithmetic, module configuration, container transforms, and compression GitBook Assistant [Restoration](https://xn--ri8h.gitbook.io/crackproof-research/android-so/restoration/restoration) GitBook Assistant Stream dispatch, dynamic linking, and ELF output reconstruction GitBook Assistant [Metadata](https://xn--ri8h.gitbook.io/crackproof-research/android-so/metadata/metadata) GitBook Assistant IL2CPP method tokens and metadata storage variants GitBook Assistant [Analysis](https://xn--ri8h.gitbook.io/crackproof-research/android-so/analysis/analysis) GitBook Assistant Validation rules, failure handling, and observed constants GitBook Assistant For the Windows PE format, see the [Windows internals Space](https://xn--ri8h.gitbook.io/crackproof-research/windows/) . GitBook Assistant This is a research reference. It records observed structures and validation behavior; it does not document a product workflow or a general-purpose unpacking procedure. GitBook Assistant [NextOverview](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/file-format) Last updated 14 hours ago --- # CrackProof for Android SO 內部機制 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/readme.md) . 本 Space 記錄 CrackProof Android 原生庫格式，範圍包括 ELF64 小端 AArch64 文件、私有保護節、分階段記錄流，以及重建可用 ELF 鏡像所需的結構。 GitBook Assistant 它與 Windows 版本屬於同一產品家族，但不是 PE 格式的變體。Android 的識別條件、節佈局、記錄流和元數據規則單獨說明。 GitBook Assistant 內容導航[](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw#nei-rong-dao-hang) ------------------------------------------------------------------------------------------- 分區 內容 [文件格式](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/file-format/file-format) GitBook Assistant ELF 識別、私有節和兩階段記錄流 GitBook Assistant [數據變換](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/data-transforms/data-transforms) GitBook Assistant 外層首部、模塊配置、容器變換和壓縮 GitBook Assistant [恢復](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/restoration/restoration) GitBook Assistant 記錄分發、動態鏈接和 ELF 輸出 GitBook Assistant [元數據](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/metadata/metadata) GitBook Assistant IL2CPP 方法令牌和元數據存儲方式 GitBook Assistant [分析](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/analysis/analysis) GitBook Assistant 校驗規則、失敗處理和已觀察常量 GitBook Assistant Windows PE 格式請參閱 [Windows internals Space](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/) 。 GitBook Assistant 本文檔是研究參考，記錄已觀察到的結構和校驗行為，不提供產品操作流程或通用解包步驟。 GitBook Assistant [下一頁概覽](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/file-format/file-format) 最後更新於 20 小時前 --- # 常量 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/analysis/constants.md) . 以下值来自当前 Android SO 样本。它们可用于识别构建家族，但不能替代结构检查。 GitBook Assistant 值 范围 ELF64、小端、AArch64 GitBook Assistant 文件架构 GitBook Assistant 一个 `SHT_LOUSER` 节 GitBook Assistant 私有节识别 GitBook Assistant `0x23c` GitBook Assistant 已观察的第一阶段外层大小 GitBook Assistant `0xbf20165d` GitBook Assistant 已观察的第一阶段字常量 GitBook Assistant `0xE2` GitBook Assistant 第二阶段初始流标识 GitBook Assistant `0x5c` GitBook Assistant 第二阶段记录和受保护描述符大小 GitBook Assistant `0x9B`、`0x9D`、`0x9E` GitBook Assistant 恢复所需模块 GitBook Assistant `0xFAB11BAF`、版本 `31` GitBook Assistant 识别的 IL2CPP 元数据 GitBook Assistant 样本出现差异时，记录新值及其来源，并重新运行所有范围和关系检查。不要为了适配孤立常量而放宽解析器。 GitBook Assistant [上一页校验清单](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/analysis/validation) 最后更新于 1天前 --- # Validation checklist | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/analysis/validation.md) . 1. Confirm ELF64 little-endian AArch64 and the expected dynamic sections. GitBook Assistant 2. Locate exactly one private `SHT_LOUSER` section and bound its file range. GitBook Assistant 3. Decode stage 1 and check reserved fields, alignment, copied sizes, and image ranges. GitBook Assistant 4. Parse stage 2 descriptors without crossing a parent stream boundary. GitBook Assistant 5. Load modules `0x9B`, `0x9D`, and `0x9E`; reject missing or duplicate definitions. GitBook Assistant 6. Require exact source consumption and target length for every raw or compressed write. GitBook Assistant 7. Rebuild dynamic-linking tables and verify counts, versions, hashes, and relocations. GitBook Assistant 8. Validate the entry point, `PT_LOAD` ranges, and section relationships from disk. GitBook Assistant 9. When metadata is present, check magic, version 31, table offsets, RID intervals, and idempotent cleanup. GitBook Assistant Any failed item leaves the candidate in an unknown state. It must not be reported as a partially restored library. GitBook Assistant [PreviousOverview](https://xn--ri8h.gitbook.io/crackproof-research/android-so/analysis/analysis) [NextConstants](https://xn--ri8h.gitbook.io/crackproof-research/android-so/analysis/constants) Last updated 1 day ago --- # Huffman and LZ compression | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/data-transforms/compression.md) . Compressed writer blocks use a compact Huffman table followed by an LZ-style stream. Huffman nodes are three bytes each; the high bit distinguishes a leaf from a child index. A 16-bit lookup table accelerates the first bits of a code, then the tree is followed for longer codes. GitBook Assistant Decoded symbols are either literals or length/distance pairs. A pair copies already-produced bytes from the output window. The decoder checks that the distance is non-zero, does not point before the beginning of output, and does not make the requested length exceed the declared target. GitBook Assistant The block is valid only when the bit reader consumes the permitted input and the output reaches the exact declared size. An early end marker, a dangling tree index, or trailing bytes outside the documented padding is a format error rather than a partial success. GitBook Assistant [PreviousContainer transforms](https://xn--ri8h.gitbook.io/crackproof-research/android-so/data-transforms/container) [NextOverview](https://xn--ri8h.gitbook.io/crackproof-research/android-so/restoration/restoration) Last updated 1 day ago --- # Constants | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/analysis/constants.md) . These values are observations from the current Android SO samples. They help identify a build family but do not replace structural checks. GitBook Assistant Value Scope ELF64, little-endian, AArch64 GitBook Assistant File architecture GitBook Assistant One `SHT_LOUSER` section GitBook Assistant Private-section recognition GitBook Assistant `0x23c` GitBook Assistant Observed stage 1 outer size GitBook Assistant `0xbf20165d` GitBook Assistant Observed stage 1 word constant GitBook Assistant `0xE2` GitBook Assistant Initial stage 2 stream identifier GitBook Assistant `0x5c` GitBook Assistant Stage 2 record and protected descriptor size GitBook Assistant `0x9B`, `0x9D`, `0x9E` GitBook Assistant Required restoration modules GitBook Assistant `0xFAB11BAF`, version `31` GitBook Assistant Recognized IL2CPP metadata GitBook Assistant When a sample differs, record the new value with its source and re-run all range and relationship checks. Do not widen a parser merely to make an isolated constant fit. GitBook Assistant [PreviousValidation checklist](https://xn--ri8h.gitbook.io/crackproof-research/android-so/analysis/validation) Last updated 1 day ago --- # 常量 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/analysis/constants.md) . 以下值來自當前 Android SO 樣本。它們可用於識別構建家族，但不能替代結構檢查。 GitBook Assistant 值 範圍 ELF64、小端、AArch64 GitBook Assistant 文件架構 GitBook Assistant 一個 `SHT_LOUSER` 節 GitBook Assistant 私有節識別 GitBook Assistant `0x23c` GitBook Assistant 已觀察的第一階段外層大小 GitBook Assistant `0xbf20165d` GitBook Assistant 已觀察的第一階段字常量 GitBook Assistant `0xE2` GitBook Assistant 第二階段初始流標識 GitBook Assistant `0x5c` GitBook Assistant 第二階段記錄和受保護描述符大小 GitBook Assistant `0x9B`、`0x9D`、`0x9E` GitBook Assistant 恢復所需模塊 GitBook Assistant `0xFAB11BAF`、版本 `31` GitBook Assistant 識別的 IL2CPP 元數據 GitBook Assistant 樣本出現差異時，記錄新值及其來源，並重新運行所有範圍和關係檢查。不要為了適配孤立常量而放寬解析器。 GitBook Assistant [上一頁校驗清單](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/analysis/validation) 最後更新於 20 小時前 --- # 概覽 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/analysis/analysis.md) . 格式中存在許多容易被誤認為表或變換程序的字節序列。因此，可靠分析必須把結構發現與範圍、校驗和、解壓結果、PE 關係及預期指令形態的獨立驗證結合起來。 GitBook Assistant * [分析流程](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/analysis/workflow) GitBook Assistant * [已觀察到的侷限](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/analysis/observed-limitations) GitBook Assistant * [il2cpp 元數據混淆](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/analysis/il2cpp-metadata) GitBook Assistant * [常量與偏移](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/analysis/constants) GitBook Assistant [上一頁Htsysm 內核組件](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/kernel-components) [下一頁分析流程](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/analysis/workflow) 最後更新於 20 小時前 --- # 第一階段首部 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/file-format/stage1.md) . 第一階段使用固定大小的參數區。當前觀察到的外層默認大小為 `0x23c` 字節，字變換使用常量 `0xbf20165d`。如果某個構建提供了不同大小，實現應從私有節讀取該值；默認值只是識別線索，不是所有構建的硬編碼條件。 GitBook Assistant 首部字段[](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/file-format/stage1#shou-bu-zi-duan) ------------------------------------------------------------------------------------------------------------ 解密後的字首部包含八個 32 位值： GitBook Assistant 字段 含義 必須滿足的關係 `key` GitBook Assistant 文件級算術密鑰 GitBook Assistant 已觀察文件中非零 GitBook Assistant `reserved` GitBook Assistant 保留字 GitBook Assistant 必須為零 GitBook Assistant `payload_offset` GitBook Assistant 載荷的文件偏移 GitBook Assistant 對齊且位於私有節內 GitBook Assistant `payload_size` GitBook Assistant 受保護載荷長度 GitBook Assistant 非零且位於私有節內 GitBook Assistant `payload_key` GitBook Assistant 傳給下一階段的密鑰 GitBook Assistant 保留給第二階段 GitBook Assistant `entry_offset` GitBook Assistant 受保護入口偏移 GitBook Assistant 位於恢復鏡像範圍內 GitBook Assistant `protect_size` GitBook Assistant 保護覆蓋範圍 GitBook Assistant 不超過鏡像範圍 GitBook Assistant `size_copy` GitBook Assistant 載荷長度副本 GitBook Assistant 必須等於 `payload_size` GitBook Assistant 字使用無符號 32 位算術恢復。對字索引 `i`，觀察到的形式為： GitBook Assistant GitBook Assistant詢問複製 plain[i] = (cipher[i] + (i + 3) * key) XOR (0xbf20165d * (i + 1)) 所有中間結果按 32 位迴繞。第一個字提供 `key`；應恢復完整首部後再進行字段檢查，不能只相信一個解碼值。 GitBook Assistant 失敗即停止[](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/file-format/stage1#shi-bai-ji-ting-zhi) ----------------------------------------------------------------------------------------------------------------- 首部截斷、保留字非零、副本長度不一致、載荷未對齊或越界，以及入口或保護範圍不在鏡像內時，都應拒絕。這樣可以避免把隨機節數據誤認為有效記錄流。 GitBook Assistant [上一頁受保護 ELF](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/file-format/protected-elf) [下一頁第二階段記錄流](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/file-format/stage2-streams) 最後更新於 20 小時前 * [首部字段](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/file-format/stage1#shou-bu-zi-duan) * [失敗即停止](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/file-format/stage1#shi-bai-ji-ting-zhi) --- # 加载与节恢复 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/loading.md) . 自举代码没有在固定偏移公开一张稳定表。它会依次解密多个阶段，后续阶段包含恢复原始节所需的记录与变换程序。 GitBook Assistant * [阶段链与标记布局](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/loading/stage-chain) 按顺序说明常见的 64 位流程。 GitBook Assistant * [PE32、DLL 与无标记布局](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/loading/layout-variants) 记录主要结构差异。 GitBook Assistant * [结构发现与验证](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/loading/discovery-validation) 说明固定标记缺失时如何选择候选，以及如何通过试解码排除误匹配。 GitBook Assistant [上一页按构建定制的字节变换](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/data-transforms/bytecode-transform) [下一页阶段链与标记布局](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/loading/stage-chain) 最后更新于 15小时前 --- # 加載與節恢復 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/loading.md) . 自舉代碼沒有在固定偏移公開一張穩定表。它會依次解密多個階段，後續階段包含恢復原始節所需的記錄與變換程序。 GitBook Assistant * [階段鏈與標記佈局](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/loading/stage-chain) 按順序說明常見的 64 位流程。 GitBook Assistant * [PE32、DLL 與無標記佈局](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/loading/layout-variants) 記錄主要結構差異。 GitBook Assistant * [結構發現與驗證](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/loading/discovery-validation) 說明固定標記缺失時如何選擇候選，以及如何通過試解碼排除誤匹配。 GitBook Assistant [上一頁按構建定製的字節變換](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/bytecode-transform) [下一頁階段鏈與標記佈局](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/loading/stage-chain) 最後更新於 20 小時前 --- # Overview | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/data-transforms.md) . CrackProof layers several small transforms rather than relying on one container-wide cipher. Their inputs, address dependence, and order matter: applying the correct transform to the wrong range can still produce plausible bytes. GitBook Assistant The pages separate the transforms by role: GitBook Assistant * [Rolling-key and rotation ciphers](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/rolling-and-rotation) cover the early stage and small-record operations. GitBook Assistant * [LFSR, string, and page transforms](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/lfsr-strings-pages) cover embedded instruction streams, import names, and sparse code-page changes. GitBook Assistant * [Checksums and key progression](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/checksums) explain record validation and how one result advances the next key. GitBook Assistant * [AES-CBC](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/aes) , [Huffman/LZ compression](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/compression) , and the [per-build byte transform](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/bytecode-transform) form the main section-data path. GitBook Assistant [PreviousSection data and companion files](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/companion-layout) [NextRolling-key and rotation ciphers](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/rolling-and-rotation) Last updated 14 hours ago --- # Observed limitations | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/observed-limitations.md) . Observed weaknesses[](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/observed-limitations#observed-weaknesses) --------------------------------------------------------------------------------------------------------------------------------- For completeness and future research, the mechanisms that demonstrably fall short: GitBook Assistant **The VM checks are bypassable by configuration alone.** The registry check matches vendor strings only at the _start_ of the BIOS/product values, while at least one major hypervisor places its marker at the _end_ of its BIOS version — setting `SMBIOS.reflectHost = "TRUE"` hides it entirely. The VMware backdoor probe is neutralized by `monitor_control.restrict_backdoor = "TRUE"` (and by not installing guest tools), and other hypervisors allow overriding SMBIOS strings directly. GitBook Assistant **The debug log is a self-documenting loader.** The status-code design that helps the vendor's support also hands the analyst a stage-by-stage execution trace and a 2-byte search pattern per stage. The mailslot channel is encrypted, but the file log is not. GitBook Assistant **Page encryption yields to in-process readers.** The demand-decrypt handler services faults from any thread in the same process, so a helper inside the process can touch every page and copy the decrypted bytes. The anti-dump scribble is reversible, and on builds where it is disabled the pages are clean. GitBook Assistant **The kernel drivers weaken the host.** Generation 1 exposes unauthenticated kernel shellcode execution to any process. Generation 2's PID-encryption "authentication" grants its `EPROCESS`\-write primitive to any program that reproduces it — a signed BYOVD — and the Protected Process flag it sets can be toggled off with kernel-level access or absorbed by injecting before it is set. Only generation 3 avoids granting attackers new powers. GitBook Assistant **The tamper-evidence chain is fully recomputable.** Every transform in the container is reversible (XOR chains, rotations, a permutation bytecode, CBC-mode AES with an embedded schedule) and every checksum is a standard CRC-32 over knowable bytes. Nothing in the design requires a secret held outside the file. Consequently the checksum chain detects naive patching but cannot prevent it: an analyst who modifies the payload can recompute every chained key and re-embed the result, and the loader will accept it. The chain raises the cost of modification; it does not bound it. GitBook Assistant **Process-policy checks are coarse.** The parent-process policy (`A03`) is satisfied by launching from an approved parent, and the DLL host check (`A11`) keys on artifacts (a `peC` section, mixed-case `KeRnEl32.dLl` imports) that identify only unmodified hosts. GitBook Assistant None of these make the protection trivial — the layered design still costs real effort to analyze end-to-end — but each is a documented, reproducible gap rather than a theoretical one. GitBook Assistant [PreviousAnalysis workflow](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/workflow) [Nextil2cpp metadata obfuscation](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/il2cpp-metadata) Last updated 14 hours ago --- # Overview | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/file-format.md) . The Windows format keeps a valid PE-facing outer image but places the original image and loader data in a separate address-oriented container. The first step in analysis is to distinguish that container from ordinary overlay data and to identify which layout family is present. GitBook Assistant Topic What it establishes [Container and encrypted header](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/container-layout) GitBook Assistant The large offset ranges, the eight-dword `info` table, and its key derivation GitBook Assistant [Recognition and build families](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/recognition) GitBook Assistant Evidence used to classify PE32, PE32+, native/managed EXE, and native/managed DLL GitBook Assistant [Section data and companion files](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/companion-layout) GitBook Assistant How section records map into the payload and how external `._` data is joined to a stub GitBook Assistant [PreviousCrackProof for Windows internals](https://xn--ri8h.gitbook.io/crackproof-research/windows) [NextContainer and encrypted header](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/container-layout) Last updated 6 hours ago --- # 第一阶段首部 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/stage1.md) . 第一阶段使用固定大小的参数区。当前观察到的外层默认大小为 `0x23c` 字节，字变换使用常量 `0xbf20165d`。如果某个构建提供了不同大小，实现应从私有节读取该值；默认值只是识别线索，不是所有构建的硬编码条件。 GitBook Assistant 首部字段[](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/stage1#shou-bu-zi-duan) ------------------------------------------------------------------------------------------------------------ 解密后的字首部包含八个 32 位值： GitBook Assistant 字段 含义 必须满足的关系 `key` GitBook Assistant 文件级算术密钥 GitBook Assistant 已观察文件中非零 GitBook Assistant `reserved` GitBook Assistant 保留字 GitBook Assistant 必须为零 GitBook Assistant `payload_offset` GitBook Assistant 载荷的文件偏移 GitBook Assistant 对齐且位于私有节内 GitBook Assistant `payload_size` GitBook Assistant 受保护载荷长度 GitBook Assistant 非零且位于私有节内 GitBook Assistant `payload_key` GitBook Assistant 传给下一阶段的密钥 GitBook Assistant 保留给第二阶段 GitBook Assistant `entry_offset` GitBook Assistant 受保护入口偏移 GitBook Assistant 位于恢复镜像范围内 GitBook Assistant `protect_size` GitBook Assistant 保护覆盖范围 GitBook Assistant 不超过镜像范围 GitBook Assistant `size_copy` GitBook Assistant 载荷长度副本 GitBook Assistant 必须等于 `payload_size` GitBook Assistant 字使用无符号 32 位算术恢复。对字索引 `i`，观察到的形式为： GitBook Assistant GitBook Assistant询问复制 plain[i] = (cipher[i] + (i + 3) * key) XOR (0xbf20165d * (i + 1)) 所有中间结果按 32 位回绕。第一个字提供 `key`；应恢复完整首部后再进行字段检查，不能只相信一个解码值。 GitBook Assistant 失败即停止[](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/stage1#shi-bai-ji-ting-zhi) ----------------------------------------------------------------------------------------------------------------- 首部截断、保留字非零、副本长度不一致、载荷未对齐或越界，以及入口或保护范围不在镜像内时，都应拒绝。这样可以避免把随机节数据误认为有效记录流。 GitBook Assistant [上一页受保护 ELF](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/protected-elf) [下一页第二阶段记录流](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/stage2-streams) 最后更新于 1天前 * [首部字段](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/stage1#shou-bu-zi-duan) * [失败即停止](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/stage1#shi-bai-ji-ting-zhi) --- # PE 重建 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction.md) . 节恢复得到的是按 RVA 组织的内存映像。要形成可用的 PE 文件，还需要协调头、文件偏移、数据目录、导入、TLS 状态、导出、重定位；托管映像还需要恢复 CLR 结构。 GitBook Assistant * [头、节与零填充范围](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction/memory-image) GitBook Assistant * [导入、TLS 与导出](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction/imports-tls-exports) GitBook Assistant * [重定位、页变换与 CLR 数据](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction/relocations-managed) GitBook Assistant 这些步骤依赖具体布局。旧版固定基址可执行文件、需要重定基址的 DLL、外置伴生映像与 CLR 映像不能使用同一种数据目录处理策略。 GitBook Assistant [上一页结构发现与验证](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/loading/discovery-validation) [下一页头、节与零填充范围](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction/memory-image) 最后更新于 15小时前 --- # vectors.txt | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/vectors.txt.md) . 期望输出。每行为 `名称 十六进制值`；前两行是标准的 CRC-32 已知答案（`crc32(b"123456789") == 0xCBF43926`）及其链式形式——一个独立于其余向量的廉价交叉校验。 GitBook Assistant GitBook Assistant询问复制 crc32_123456789 cbf43926 crc32_chain cbf43926 kdf_info a07f35c4 08c23441 788c7e3e e4fcee52 30c61262 a5f0b9a7 8d927c7a cd491cb3 dd3_shift19 6fa2a6a442b0c33a208e2427319316cebeaa48f9eccfe41b533a8d8f5d206d4b dd3_shift21 9ba829e90fecb0ce8623c989caa48533ac2a52bef733f946904ee3631248db12 dd4 154fe25134b3a830e267b8085ba330867daf4d3b03318746fee42c1d14766971 dd5 ae04d26a350937426de7e73c7d1fbabd432b327735f22eb57a8fb7e69f2427fd lfsr96 018000600028001e80086006a802fe8180606028281e9e886866aeaafc7f01e0004800368016e00ec80456837ee1e0484836b696f6eec6cc52d5fd9f01a8007e80206018280a9e8728629ea9a87efea0407830229419af4afc3701d6805ee038 dd6_len95 5ecf7642b0dc99bccc6aca4e29242cf04c3e3d06077f1a6248ff6d9297c8b10bc4c99fc54fc973b710e91462ebceccfed10ca234a18c8bb8b4954ffbda8641786025febcd0a19b36a034ebed2ef7fb42c25af0c9c80fda352a935161e249d6 dd7_cipher b88c817519bd507468ffa4d8 dd7_plain 4b45524e454c33322e646c6c dd8_shift0 8b47b3c7549885b8d4b73ded824cd9ccfdb6b0b58ee3474a013577923678cd2f1fdb7e1bf0e55199c8d5965b1ce9a6029572b17745bb20cc4e934fe5707cb91807eac441980bc5f44409eec3a1bb37d6333d813bcdda7463f541e5b85c07ba8bf8baa2bfa2547ff45b865d1ea14bd8b76cd9620fcaa3c8632b2fc5abcee2ad77e80808aa7bbd8e9726766177b152756619167b956030c2f5ea3fdd4b9a2711c81202cfafb1f7b1af81f4cef069c0a1fd58cfd6bf3a4a2c14f04881839d1f0a41f54cb10d716a16e28b110fbe66d191e588ee601e8466f692bf136850b54460a154fe91986a2f81ab29d1a82949901fdf506ced49f0e031779e5eaec7c44a7e1117a231b8cf14d457422db38db5d4c9fd994f3375b476160a95ded20d0d13750ee8391f68589a19088311a05c5442b1a68e0ecc2689d2ffca742bb75e65bbf86af6353a3940f87d0d5b5e461ad2cd9d95a2993676adde6a70cb05a507d08c5e49357edf4c5218502900e8de5fe09df5da894f4a13e1d1faf0f2d5466ce508a425236fbe5bb2970701687704d9310bc9d83d07ea3f6b2f7714032aaa0399e56a53e4d8d0b146c83caf50c8bb47803fc946fa0ba6cf15ccca76da7b44567f0af35c4dfdf02e50b0aa79388bf18087354c2f4116132d2bc603871b327b05d095274ddc94e0459f0932ef6465d26a08ab4cf3d85c26577ff1558b2cadddc353449167b6c943fe87d4daa0dbee2804c7336544c88000de68d7169b363eb655785562c8463ca1f4df7acb346bb2fc5d8d2cdb294e9e75e7beb1c0a2272d7a964ac86ee13cff6758028b5037a29f439a262a92fe29419c2edf71f461b2b39176d61b2b768b9be5ecd1fcdaa8d6e255f462f41572006cf7fe06bb736c4c00c6f63071b7a1690a5009af0b003e1d2bf0b918d19188fc949e3b8ce5da2b3034482e6f1fd0d052bdbf9a83ac780c556936471d09d83179a24c5967fd13da0868aa47abaddac30596d11fb88321f81cedab1451e6604b1af32f62acc26e8990a4428205d7de8f84ec81ac40eafaeed8fa3aa892b343a2c25a58f34ba7871c54e852309f6c879e178c78e78c4529e5b0c92ea1c6393ef09b49bf40bad6d64cf226b2b79ffc24ad49b5bc0e9456f6d7aa873aafd478b3dc11f03d0cf329f5a5784528942f731acce91adbefd592cec728557396faa3a861d70791b37331a387b81e3a647f83b16209e244ee4dce43bfedea522f3821c7cee0005c203c31c2084780d59ac1ed742702a94c0380e9269f1562b467738c5dc667f126d7fe225b8a812e471c2ba6d2286d7f07b97673f6179fa7db3f53b45d41e74859ed42af979082de43a6f7d651c72ae6fd31bab30bae48046bcad49b5ca22255420b1738c5e72c3ae21666da17955dd7c31d5ba267be965f6f33d279943e1d37246f62d1581327e19f5eb843f0066bbb60c5eef04f75d08f7eb5c2b8e25322efe7ebba43e626dc66578634d74c0c01749d0689fc2bd60261eaa115f6c90fbcd6b3e438a02b22784d50a7268e3f7d0c54274ec9df89b6fd95675c70082c0dbdb957557952061def1330f2da94805d57238da2cc6019c055e1645e72f49b3d3bda94ca9f03786ef56602a7a64c6c05951cae9937ffaf7261ebdf3454f5bee18def136550b4aa8206e7368add49022345efa55e0eed461f3e51397f3079e89152205cdcb5b0e5e85eada0c2dcbde7b8cfbfebb26410f978cba237f42124d0386a0cdf797bf898f101c47511006d6025762336e802020ad1ad64035aa3cdcf15fbc37d1ad54057c1b468529eadc15cefc2268ce7bd11dca14b0f638fcc7ee2bb6ccbbc2f78eed8b801cc361048b768377d49d42ccd3efafad20f9b84d2b9ad126c1e67f99c20f56a361884203ce7ba42b67f3cc6ee400f5532c5af3c882974542e28ed6401a5aeb06665039ff81e29b6c12e4f585e81ecfb1f841dd11f3c65101fcc2f4ae601259565c1df6eef99308c3333c81be21f870a109603b3cb8c422b805ef434136ca262cf30648496daf011eaddbcd9c1eaf8748037e258c42709dacba8e677d0d28ef102a74eec69fc2be603ef87f3076a7bffb5979fe048504caa02e893fdea1179f81e102cc4e5614b00e11e6b5d43d872462dda846e967e84786ace6e44b5c215b30b4cfc408eda5ba82c9d8b9d092361b7311a3e80f35bcfc68a81cd5d04a83a42732bdda5376b0a7ccec7efd070ebf2940f62dfa7a8c7ef343299eaed3140e1ccc3746f4f834fad6cf76985a58b87f0f3d6b3db8701d54a847125e4301bfb2b522de143ac28f03abf19d41b60130261be59010bda50cbe9979da5bcf122fc58eaa822fb3eadf14fdaecbe67d993171eb4b234ae6ae7247bf24e2459942c1bd27aedd7299d66272a426b19007a3a3b9b66bc2ab01a2090516b62cb8673a2e521c07b99e073ae99afa0d5486445f492203b16b233de58d9602dfab9f0e6734af64a94f1997f258667beac2171cc30f6306d269184beee5d43b77a292a3d102922593d5d2d936c5d7d8258f0ed37e2f66e0a937f24d8482138de8de0abc36d409c944150dd9656c5c12c0475e44282d3a4f4c929445bceba20c71e18cbbf063980982ded4b830b95a64cdee4b63d0a84be9af92f7a8decdd80ee5f7ecb09d7790c6a55598068bcdb45c6dbe3800a21b1cc5c1525c0c6146f8422c434921061c3a2bdcd18e569efd859d5888db12358b905c2d7957173b98bf88708cfd3d5ab90cb1b6faf4bba5c00415dd9730291a9afbf46bbf9501454d64e932759cced3db72fdfdb55e5a8ebfd033856980ff6f9577aeeffc3d53f61d49d12614f868326179f3a71351d92cfab44a2e8735985d72bd4c0a958919b623a9d223da2b155f7440d2f596c75e8574753ce77ef4305580e93e7800f69e6da9ead3782b796b3c5868f977b0dc6331a931d972e6c17d212c79f3111345bf0531fce19ec699b832bd9611f8620ff0de38a372f7dbe00dc2205066eab671e9d5810a7e2c404653f44ede245ec9d492581afd81c152c0ea62660f92263c2ca267bf88001a64bedf5df26935fe4732e3cc6e1de36ef70374943d5cb831087dcda5087493abe71f147a09ba39466869e2b8837c6ab45bb516f2016f6634f7537976ecd92ca29224969b01a48e122aaecdba3f7b5fc95b0a458e78916697f9b1e5274cb91a84879e32613200515c7acb74bf4a173fea56732d84a48ed1bc5ff3c5501e42109c10a92dc7ae367d66f48648f5e586bda796a1d577b545fa008999efbbaa3bed77cca0b7b1b4aa39b313227cbc8a5ae0d5eb943d1329575420c54b4b548c58b7ba65de98ab0f215afdd10fe3c1cfe9e68e2c8f0d4abdc5beafd135508463f4dafb188aa23742a3c35047c30c0493b8511d87e5685a5de636251c7ba8d96386f8351b8b1f22cf5baf1fd04670941dd6e815837889b6339ef48ecdd7ff0bc09fe5a7fc4443af60d5635e02cb33ffb9a4785bcc19262ad40ce0e886da7f38142aceb79198cd00bdcfc158d69875b7259563da46115bacff887fba60a9669a1a6ceaabf09991e4a84b82da626bbfda33882ccf2cd0c16981b0c288a57153b362c5ebb1730ac22aad6bfc38fc289d7918757f6ce31097e5b1863843cedb966f8fffb0d8911ae6d7f5d68e6748e92af44cd04dda22c948df10fb3d18859dffb527de63d63c44525a43b2c9b43d1d861c5c15e461ed31874b5d74ba5fe1ab11ef63a06a736d8c30376a8ab65adc6c3db2350dbf562abe7f586fb9b6bf1a6200875fde0fad64da856d701a84d289b1e20719c99041cb29e69c7b7365f7b64ea050fbfa7395d985bfe2cb4094fef721813c5f956e1515518bb9ffdd79677b231779bb12bbb27a426725ecfdacb006244793959774b91798e6cbf745ba785df79d1f735e32bd6ce38bbdb1148d11c759bf6ec3f03a5e074788dd076c134092fac9da9e2e6894fe6f27795eea746caa9761002d6a674851399c809102ee32bdc1d78a383f428bb335dd8018e6d4a53f2962f9fd9b0590b959b575f04ec66d7126c11c0986faf866f40a419cc3630c6341dccefa2141840adae0b50c967f0bef0c02e46d15b18e7c50b315a39bf91f54c937620be6b1739825248da87308d528d8ca7271767b444d86070c618ed397607e4d1656aef104bb0cc04811dfc1acdefadeb5685d52566bdc6e3e362c531a227dd92f526820f1247afcb4d1ea34ba9136473cceaa26243fea69fb9c372d69963b584098fa7766dc917bd49ce22a42aea58dd864860b79d974f4dd61b44523b66ff87e18785f97f51058f04289b81505891cd84d648c379fbf32b4dfaac362fceb98bbe9fe8a3afe25d8693d9510ee5367c80cbff3a061f0fa80bb1ac43c6df2dc29a759a40cfa947e7808c44ae4ff44feb486363b6201f2c69531e2dc2c07809a0cca972a12f5a274f7c8c7f3e1a4d65138859d3e253471f14fb30ac089eeedd3151d155c3c9f6d325ccb1525f19852c8dbabd588802ad2a6c920a0c1834f618496b2ea294f5f503dfbaa03de0c9b34b576aa32b166faae9163a50e6192b0a1c15719bef5b611067d4e17f72c07db460463926bc9e32dcd29c992c8656ff683f68cdf205750e482140fffbd56e5ca7fcc3db5f47d53623366e244b793dff12cb79ff8fe09750dfca046a43012b5f71a1541972d715b9a43fdd8fe0ca61b6ce00e498d7b2add2fc6de4090a445c547ac911cf81435c50c87320589f8a79ea260fa7400ddf46908b892c5788a08adfeee1ecefb6304be13dcc5186c347609a698327b2040196db7a117d6379ca624fbc483a7d3d1129a8f3b66eb308cb15ffa74a2bbbc2e474597c6ef3d3812db45e9853b592468ee0341f13400bb1acba8eb89fdd3edc895e03317afedd33e775bbfc4a7a5a0681fc673b3ada518310968e3620cc33c825713d5b84164c09c9be7d226a0a16b6efb07903f299dac7ea141c7dc3eea414217362325198816659cc6b0ce45c1b9238d2f5797926914ad7c228b17480af091acbae1018c4709cd1000a7cdb84d1dbb6dbbbe182f2f15f2e5477b70f85875dfc85529c83be9f7e35de06fb6865b5d51ee9fdc530670edbf5a09f3a69d673867a51ecc2b38f2b63e60f7ad597fe57c84fbf43621f878d18e8a20fa7460dcd0f1e816cb13b23c4277b604c1a44c55d025bc067775abfa8f378770431621204863c0f18db2249ac28e7c2ac9dd393fed38af999ab64b92be6c86295cd6b2f9b7e729689f8e4b8bb4ce94940f8bca4898e83165d2731a27a8cb1b4a9350415298c9755ad0370055ef9f32f9a86019b5d8e6e69a1c82c2c8999bd3cfc3ac2d7584cb431c33a29d1941b2acf2167727dee2eb5e747af3206e2e32e641e2830cce65c04b16221e715f02169abc57fd5b346cf432b194093c1a3dbf61673fbcc2da75f8501737ff67c9aff08687377e10981d66173d025c5d57d76be48342a0add80fb39f0325e140b4e2de8ce2d0342b3d0aa90a0944bf59bb72de2156d444f9d6edb9bc5320f75d05ca561cbf477994478698138e0e2db5229ff72bdfe9af675cdad2c235623c1baa6e9506e54a454b6d0731b658361eb1c426c31a135444dd1d2242f39d972139da6fa1543a8f87067474c7bf4a07fbaff03d69749cc1a977fa2f617954717fa9e6660c0a025eff4175cbeee57af3bfee602b4d15feebb09b239de8d3d8171791686281805cfca78eca444f7a5d0d42f9e6826beb33088cf03f59b6fd7122309c83ae197bc828c5f6fc8f54d9622d0446af362f33696a9076c48eecdaf85 dd8_shift15 8b47b3c7549885b8d4b73ded824cd9ccfdb4b0b58ee3474a013577923666cd2f1fdb7a1bf0e55199c8d5965b1ce986029572b17745bb20cc4e934f95707cb91807eac441080bc5f44409eec3a1bb37d6333d813bcdda7463f541e5b85c47ba8bf8baa2bfa2543ff45b865d1ea14bd8b76cd9620fcaa3c8632b2fc5abcee2ad77e80808aa7bbd8e9726766177b152756619167b956030c2f5ea3fdd4b9a2711c81202cfafb1f7b1af81f4cef069c0a1fd58cfd6bf3a4a2c14f04881839d1f0a41f54cb10d716a16e28b110fbe0eb891e588ee601e8474e592bf136850b54460a154fe51986a2f81ab29d1a8294990a3df506ced49f0e031119e5eaeadc44a7e1137a223b8cf14d457422db38db5d4c9fd994f3375b476160a95de190db013750ee839bb68589a19088311cc5c5442b1a68e5acc2689d2ffca7437b75e65bbf86af6353a3940f87d6d5b5e461ad2cd9d95a2993676ad3e6a70cb05a507d08c5e49357edf4cd218502900e8de5fe09df5da894fca13e1d1faf0f2d5466ce508a425236fbe5bb2970701687704d9310bc9d83d07ea3f6b2f7714032aaa0399e56a53e4d8d0b146c83caf50c8bb47803fc946fa0ba6cf15ccca76da7b44c0e80af35c4dfdf02e50b0aa79388bf18087354c2f4116132d2bc603878e32ec05d095274ddc94e0459f09327a64f2d26a08ab4cf3d85c26577ff1c08b2cadddc353d89167b6c943fe8741daa0dbee28045b336544c880b3de68d7819b363eb655785562c8463ca141df7acbad6bb2fc5d8d2cdb29fe9e75e7beb1c0a2272d7a964ac86ee13cff6758028b5037a22f439a262a92fe2941dc2edf71f461b2b39176d61b2b768b9be5ecd1fcdaa8d6e2553462f41572006cf7fe06bb736c4c00c6f63071b7a1690a5009af0b003e1d2bf0b918d19188fc949e3b8ce5da2b3034482e6f1fd0d052bdbf9a83ac780c556936471d09d83179a24c5967fd13da0868aa47abaddac3056b2f1fb88321f81cedab1451e6604b1af32f62acc26e8990a4e52a05d7de8f84ec81fd40eafabbd8fa3aa892b343a23d5a58f34ba7871c54e852309f90879e178c78e78cf02942b0c92ea1c6393ef09b1bbf40bad6d64cf226b2b79ffc24cd4bb5bc0e9456f6d790873aafd478b3dc11f03d0cf3291ca5784528942f73abcce91adbefd592cec728557396daa3a861d70791b37331a387b81e3a447f83b16209e244ee4dce43bfed6a522f3821c7cee0005c203c31c2884780d59ac1ed742702a94c0380e9269f1562b467738c5dc667f126d7fe225b8a812e471c2ba6d2286d7f2b947673f6179fa7db3f53b45d41e74859ed42af979082de43a6f7d651c706e6fd31bab30bae48046bcad49b5c892255420b1738c5e72c3ae21666da3cb95dd7c31d5ba267be965f6f33f879b83e1d37156f62d1581327e19f74b843f0066b8a60c5eef04f75d08f54b5c2b8e25322efe7ebba43e66edc6657aa34d74c0c01749d0689fc2bd64861eaa13bf6c90fbcd6b3e438302b22784d50a7268e3f7d0c54274ec9df89b6fd95675c7008dc0dbdb957557952065def1330f2da94805d97238da2cc6019c055e1645e72f49b3d3bda94ca9f03786ef56602a7a64c6c05951cae9937ffaf7261ebdf3454f5bee18def136550b4aa8206e7368add49022345efa55e0eed461f3e51397f3079e89152205cdcb5b0e5e85eada0c2dcbde7b8cfbfebb264106bebcba237f42124d038570cdf797bf898f101c47511006d6019762336e802020ad1ad83035a49cdcf15fbc3ec1ad540c2c1b468529eadc15cefc2268ce7bd11dca14b0f298ff07ee2bb6ccbbc2f7818d85001cc361048b768377d49d42ccda9fafad20f9b84d276ad126c1e67bf9c20f56a3618845e3ce7ba42b67fdcc6ee400f5532c5af3c882974544e28ed6401a5aeb06665039ff81e29b6c12e4f585e81ecfb1f841dd11f3ce5101fcc2f4ae601259565c1df6eef19308c3333c81be21f870a109603b3cb8c422b805ef434136ca262cff2a78496daf011eaddbcd9c1eaf8748037e258c42709dacba8e677d0d24f3302a74eec69fc2be603ef87f3c7ab7bffb5979fe048504caa02e8933dead379f81e102cc4e5614b00e1a16b9c43d872462dda846e967e8478d5ce6e44b5c215750b4cfc408eda5ba82c9d8b9d0923a7b7311a3e80f35bcf794b81cd5d04a83a42732bdda5ea6b0a7cce04efd070ebf2940f62dfa7a818ef343299eaed3140e1ccc3749f4f834fad6cf76985e25387f0f3d6b3db8701d54a847125e4301bfb2b522de143ace9f23abf19d41b601302a1be59010bda50cbe9979da5bcf122fc58eaa822fb3eadf14fdaecbe67d993171eb4b234ae6ae7247bf24e2459942c1bd27aedd7299d66272a426b19007a3a3b9b66bc2ab01a2090516b62cb8673a2e521c07b99e073ae99afa0d5486445f492203b16b233de70f0602dfab9f0e67398254a94f1997f258667beac21f1cc30f6306d269184beee5d3fb77a292a3d1029227f3d5d2db96c5d7d82b8f03f37e2f66e0a937f24d8482138de8de0abc36d409c94415056962bc5c12c0475804282d3a4f4c929685bceba20c71e0ccbbf063980982d314b830b95a64cdee4b63d0a84be7af92f7a8decdd80ee5f7ecb09d7190c6a55598068bcdb45c6dbe3800aa1b1cc5c1525c0c6146f8422c434121061c3a2bdcd18e569efd859d5888db12358b905c2d7957173b98bf88708cfd3d5ab90cb1b6faf4bba5c00415dd9730291a9afbf46bbf9501454d64e932759cced3db72fdfdb55e5febcfd033856980ff6f9577aeeffc3d53f61d49d12614f868326179f3a24354a92cfab44a2e8735985d72bd495a90f919b623a9d223da2b155f744582f596c75e8571b53ce77ef4305585b93e7800f69e6869ead3782b7e5b3c586d8977b0dc6331a931d972e6c17a712c79f6811345bf0531fce195c699b832bd9611f8620ff0de38a372f7dbe00dc2205066eabd71e9d5810a7e2c404a53f44ede245ec9d492581afd81c152c0ea62660f92263c2ca667bf88001a64bedf5df26935fe4732e3cc6e1de36ef70374943d5cb831087dcda5087493abe71f147a09ba39466869e2b8837c6ab45bb516f2016f6634f7537976ecd92ca29224969b01a48e122aaecdba3f7b5fc950d1a58e78916697f9b1e5274cb91a84879e32613200515c7acd023f4a173fea56732c94a48ed0ec5ff3c5501e421097e0a92dc7ae367d66f48648f5ee46bda796a1d577b215fc708999efbbaa3bed77cd80b7b1b4aa39b313227cbc8a5ae2d9cb943d132957542f654b4b548c58b7ba65de98ab0f2bcafdd10fe3c1cfeef68e2c8f0d4abdc5beafd135508663f4dafb188aa23742a3c35047c30e0493b8511d87e5685a5de63625147ba8d96386f8351b8b1f22cf5ba71fd04670941dd6e815837889b6339ef48ecdd7ff0bc09fe5a7fc4443af60d5635e02cb33ffb9a4785bcc17e8fad40ce0e886da7f38142aceb79198cd00bdcfc158d69875b7259563d486115bacff887fba60a9669a1a6ce41bf09991e4a84b82da626bbfda3386920f2cd0c16981b0c288a57153bdc2cb2bb17305d22aad6bfc38fc2893d918757f6cec0097e5b1863843ced5366f8fffb0d8911ae6d7f5d68ee748e924344cd04dda22c948df10fb3d18259dffbbc7de63d63c44525a4ab2c9b43d1d861c5c15e461ed31874b5d74ba5fe1ab11ef63a76a736d8c30376a8aba5adc6c3db2350dbf522abe7f586fb9b6bf1a6200875fde0fad64da856d701a84d289b1e20719c99041cb29e69c7b7365f7b64ea050fbfa7395d985bfe2cb4094fef721813c5f956e1515518bb9ffdd79677b231779bb12bbb27a426725ecfdacb006244793959774b91798e6cbf7409f485df79d1f735e32b2bce38bbdb1148d11c759bf6ec3f0359e074788dd076c1340988ac9d03e2e6894fe6a37795eef246caa9761002d6a674851399c809102ee32bdc17785f83f428bb335dd801386de253f2962f9fd9b0590b959b575f53ec66d7126c11c0176faf866f40a219cc3630c6341df2efa2141840adce0b50c967f0bef0c02e46d15b1807c50b315a39bf91f54c937620be6b1739825248da87308d528d8ca72717e7b444d86070c618ed397607e4d165eaef104bb0cc04811dfc1acdefadeb5685d52566bdc6e3e362c531a2a55e92f526820f1247afcb4d1ea34ba9136473cceaa26243fea69fb9c3f3549963b584098fa7766dc917bdc94f22a42aea58dd864860b79d974fcdd69944523b66ff87e18785f97f2e050e04289b81505891cd84d648c306fbf32b4dfaacb02fceb98bbe9fe8a3afe25d8693d9d70ee5367c80cbff3a799e0fa80bb1ac43c6df2dc29ae89a40cfa9c4e7808c44ae4ff44feb4863fcb6201f2c69531e2dc2c07809d0cca972a12f5a274fec8c7f3e1a4d65138859d3e253471f14fb30ac089eeedd31515097c3c9f6d325ccb1f9b319852c8dbabd588802ad2a6c920a0c1834f618496b2ea20163f503dfbaa03de0c9b34b576aa32b166faae9163a50e6192b0a1c15719bef5b611067d4e17f72c07db460463926bc9e32dcd29c992c8656ff683f68cdf205750e482140fffbd56e5ca7fcc3dbb7aed53623366e244bebaeff12cb79ff8fe09750dfca446a43012b5f71a1541972d729b9a43fdd8fe0ca6150ce00e472d7b2add25c6d76090a445c547ac911cf81435c50c87320589f8a79ea260fec4030df46908b89085788a08adfeee100efb6304be13d185186c347609a691f27b2040196db7a117d6379ca622fbc483a7d3d1129a8f3b66eb3082b15ffa74a2bbbc2e474597c6ef3d3012db45e9853b592468ee0341f13c00bb1acba8eb89fdd3edc895e03317afedd33e775bbfc4a7a5a0681fc673b3ada518310968e3620cc33c825713d5b84164c09c9be7d226a0a16b6efb07903f299dac7ea141c7dc3eeb203217362325198816659cc6b0ce45c1b9238d2f5797926914ad7c228a47497af091acbae1018c4709cd1001f7ccc84d1dbb6dbbbe182f2f15f2e4177b70f85875de085529c83be9f7e20de06fb6865b5c91ee9fdc530540edbf5b79f3a69d673867a51ecc2b38f1e63e60f63d597fe57c84fbf43d21f878d18e8a20fa7460dcd0f1e816cb13b23c4277b604c1af4c55d025bc067775affa8f378770431621204863c0f18db2249ac28e7c2ac9dd3933ed38af999ab64b92be6c86295cd6b2f9b7e729689f8e4b8bb4ce94940f8bca4898e83165d2731a27a8cb1b4a9350415298c9755ad0370055ef9f32f9a86019b5d8e6e69a1c82c2c8999bd3cfc3ac2d7584cb431c33a54af941b2acf2167727dee2eb5e747af3206e2e32e641e2830ebce5c04b16221e715212169ab107fd5b346cf432b193f93c1a3dbf61673fbcc2da75ff901737ff67c9aff3d685477e10981d66173d02517d57d76be48342a0add80fb39f0d2dc140b4e2de8ce2db942b3d0aa90a0944bf59bb72de27c6d444f9d6edb9bf4320f75d05ca561cbf477994478498138e0e2db5229ff72bdfe9af675edad2c235623c1baa6e9506e54a4d4b6d0731b658361eb1c426c31a1b5444dd1d2242f39d972139da6fa1543a8f87067474c7bf4a07fbaff03d69749cc1a977fa2f617954717fa32cb60c0a025eff4175cbeee57af3bfee602b4d15feebb09b239de8d3d81dd791686281805cfca78eca444f7a57bd42f9e6826beb33088cf03f59b6f7cbe2309c83ae197bc828c5f6fc85f4d3a22d044dbf362f33696a9076ce2eecdaf85 dd8pe32_small 8b47b3c7549885b8d4b73ded824cd9ccfd94b0b58ee3474a013577923666cd2f1fdb7e1bf0e55199c8d5965b1ce9a6029572b17745bb20cc4e934f15707cb91807eac441980bc5f44409eec3a1bb37d6333d813bcdda7463f541e5b85c47ba8bf8baa2bfa2547ff45b865d1ea14bd8b76cd9620fcaa3c8632b2fc5abcee2ad77e80808aa7bbd8e9726766177b152756619167b956030c2f5ea3fdd4b9a2711c81202cfafb1f7b1af81f4cef069c0a1fd58cfd6bf3a4a2c14f04881839d1f0a41f54cb10d716a16e28b110fbe66d191e588ee601e8466f692bf136850b54460a154fe91986a2f81ab29d1a82949901fdf506ced49f0e031779e5eaec7c44a7e1137a213b8cf14d457422db38db5d4c9fd994f3375b476160a95ded20d0d13750ee839bb68589a190883110c5c5442b1a68e0ecc2689d2ffca742bb75e65bbf86af6353a3940f87d6d5b5e461ad2cd9d95a2993676adde6a70cb05a507d08c5e49357edf4cd218502900e8de5fe09df5da894f4a13e1d1faf0f2d5466ce508a425236fbe5bb2970701687704d9310bc9d83d07ea3f6b2f7714032aaa0399e56a53e4d8d0b146c83caf50c8bb47803fc946fa0ba6cf15ccca76da7b44567f0af35c4dfdf02e50b0aa79388bf18087354c2f4116132d2bc603871b327b05d095274ddc94e0459f0932ef6465d26a08ab4cf3d85c26577ff1558b2cadddc353d80c67b6c943fe87d4daa0dbee2804c7336544c880b3de68d7a19b363eb655785562c8463ca1f4df7acb346bb2fc5d8d2cdb297e9e75e7beb1c0a2272d7a964ac86ee13cff6758028b5037a29f439a262a92fe2941dc2edf71f461b2b39176d61b2b768b9be5ecd1fcdaa8d6e255f462f41572006cf7fe06bb736c4c00c6f63071b7a1690a5009af0b003e1d2bf0b918d19188fc949e3b8ce5da2b3034482e6f1fd0d052bdbf9a83ac780c556936471d09d83179a24c5967fd13da0868aa47abaddac30596d11fb88321f81cedab1451e6604b1af32f62acc26e8990a4428205d7de8f84ec81ac40eafaeed8fa3aa892b343a2c25a58f34ba7871c54e852309f6c879e178c78e78cf02952b0c92ea1c6393ef09b49bf40bad6d64cf226b2b79ffc24ad0bb5bc0e9456f6d790873aafd478b3dc11f03d0cf329f5a5784528942f731acce91adbefd592cec728557396daa3a861d70791b37331a387b81e3a647f83b16209e244ee4dce43bfed6a522f3821c7cee0005c203c31c2084780d59ac1ed742702a94c0380e9269f1562b467738c5dc667f126d7fe225b8a812e471c2ba6d2286d7f07b97673f6179fa7db3f53b45d41e74859ed42af979082de43a6f7d651c72ae6fd31bab30bae48046bcad49b5ca20f55420b1738c5e72c3ae21666da17b95dd7c31d5ba267be965f6f33d279943e1d37155d62d1581327e19f5eb843f0066bbb60c5eef04f75d08f7eb5c2b8e25322efe7ebba43e66edc6657ca34d74c0c01749d0689fc2bd60261eaa115f6c90fbcd6b3e438b02b22784d50a7268e3f7d0c54274ec9df89b6fd95675c70082c0dbdb957557952065def1330f2da94805d57238da2cc6019c055e1645e72f49b3d3bda94ca9f03786ef56602a7a64c6c05951cae9937ffaf7261ebdf3454f5bee18def136550b4aa8206e7368add49022345efa55e0eed461f3e51397f3079e89152205cdcb5b0e5e85eada0c2dcbde7b8cfbfebb26410f978cba237f42124d0386a0cdf797bf898f101c47511006d6025762336e802020ad1ad64035a4926cf15fbc37d1ad54057c1b468529eadc15cefc2268ce7bd11dca14b0f298f807ee2bb6ccbbc2f78eed8b801cc361048b768377d49d42ccde9fafad20f9b84d276ad126c1e67f99c20f56a361884203ce7ba42b67fdcc6ee400f5532c5af3c882974542e28ed6401a5aeb06665039ff81e29b6c12e4f585e81ecfb1f841dd11f3ce5101fcc2f4ae601259565c1df6eef99308c3333c81be21f870a109603b3cb8c422b805ef434136ca262cf30648496daf011eaddbcd9c1eaf8748037e258c42709dacba8e677d0d28ef102a74eec69fc2be603ef87f3076a7bffb5979fe048504caa02e893fdea1179f81e102cc4e5614b00e11e6b5d43d872462dda846e967e84786ace6e44b5c21575cc4cfc408eda5ba82c9d8b9d092361b7311a3e80f35bcfc66b81cd5d04a83a42732bdda5ea6b0a7ccec7efd070ebf2940f62dfa7a8c7ef343299eaed3140e1ccc3741f4f834fad6cf76985a58b87f0f3d6b3db8701d54a847125e4301bfb2b522de143ace8f03abf19d41b60130261be59010bda50cbe9979da5bcf122fc58eaa822fb3eadf14fdaecbe67d993171eb4b234ae6ae7247bf24e2459942c1bd27aedd7299d66272a426b19007a3a3b9b66bc2ab01a2090516b62cb8673a2e521c07b99e073ae99afa0d5486445f492203b16b233de58d9602dfab9f0e6734af64a94f1997f258667beac2171cc30f6306d269184beee5d43b77a292a3d102922593d5d2d936c5d7d82b8f00f37e2f66e0a937f24d8482138de8de0abc36d409c944150dd9656c5c12c0475804282d3a4f4c929285bceba20c71e18cbbf063980982ded4b830b95a64cdee4b63d0a84be7af92f7a8decdd80ee5f7ecb09d7790c6a55598068bcdb45c6dbe3800aa1b1cc5c1525c0c6146f8422c434921061c3a2bdcd18e569efd859d5888db12358b905c2d7957173b98bf88708cfd3d5ab90cb1b6faf4bba5c00415dd9730291a9afbf46bbf9501454d64e932759cced3db72fdfdb55e5a8ebfd033856980ff6f9577aeeffc3d53f61d49d12614f868326179f3a71351d92cfab44a2e8735985d72bd4c0a958919b623a9d223da2b155f7440d2f596c75e8571b0ece77ef4305580e93e7800f69e6da9ead3782b7e5b3c586f8977b0dc6331a931d972e6c17d212c79f3111345bf0531fce19dc699b832bd9611f8620ff0de38a372f7dbe00dc2205066eab671e9d5810a7e2c404a53f44ede245ec9d492581afd81c152c0ea62660f92263c2ca267bf88001a64bedf5df26935fe4732e3cc6e1de36ef70374943d5cb831087dcda5087493abe71f147a09ba39466869e2b8837c6ab45bb516f2016f6634f7537976ecd92ca29224969b01a48e122aaecdba3f7b5fc95b0a458e78916697f9b1e5274cb91a84879e32613200515c7acb74bf4a173fea56732d84a48ed1bc5ff3c5501e42109c10a92dc7ae367d66f48648f5e586bda796a1d577b215fd708999efbbaa3bed77cca0b7b1b4aa39b313227cbc8a5ae0d5cb943d132957542f654b4b548c58b7ba65de98ab0f215afdd10fe3c1cfe9e68e2c8f0d4abdc5beafd135508663f4dafb188aa23742a3c35047c30c0493b8511d87e5685a5de63625147ba8d96386f8351b8b1f22cf5baf1fd04670941dd6e815837889b6339ef48ecdd7ff0bc09fe5a7fc4443af60d5635e02cb33ffb9a4785bcc19262ad40ce0e886da7f38142aceb79198cd00bdcfc158d69875b7259563da46115bacff887fba60a9669a1a6ceaa5209991e4a84b82da626bbfda3388220f2cd0c16981b0c288a57153b362c5ebb17305dd0aad6bfc38fc289d7918757f6ce31097e5b1863843cedb966f8fffb0d8911ae6d7f5d68ee748e92a344cd04dda22c948df10fb3d18859dffb527de63d63c44525a42b2c9b43d1d861c5c15e461ed31874b5d74ba5fe1ab11ef63a06a736d8c30376a8aba5adc6c3db2350dbf562abe7f586fb9b6bf1a6200875fde0fad64da856d701a84d289b1e20719c99041cb29e69c7b7365f7b64ea050fbfa7395d985bfe2cb4094fef721813c5f956e1515518bb9ffdd79677b231779bb12bbb27a426725ecfdacb006244793959774b91798e6cbf745ba785df79d1f735e32bd6ce38bbdb1148d11c759bf6ec3f03a5e074788dd076c134092fac9d0349e6894fe6f27795eea746caa9761002d6a674851399c809102ee32bdc1778af83f428bb335dd8018e6d4a53f2962f9fd9b0590b959b575f93ec66d7126c11c0176faf866f40a419cc3630c6341dccefa2141840adce0b50c967f0bef0c02e46d15b18e7c50b315a39bf91f54c937620be6b1739825248da87308d528d8ca72717e7b444d86070c618ed397607e4d1656aef104bb0cc04811dfc1acdefadeb5685d52566bdc6e3e362c531a227dd92f526820f1247afcb4d1ea34ba9136473cceaa26243fea69fb9c372d69963b584098fa7766dc917bd49ce22a42aea58dd864860b79d974f4dd61b44523b66ff87e18785f97f51058f04289b81505891cd84d648c379fbf32b4dfaacb0a8ceb98bbe9fe8a3afe25d8693d9510ee5367c80cbff3a06be0fa80bb1ac43c6df2dc29ae89a40cfa947e7808c44ae4ff44feb486363b6201f2c69531e2dc2c0780950cca972a12f5a274feb147f3e1a4d65138859d3e253471f14fb30ac089eeedd31519155c3c9f6d325ccb1525f19852c8dbabd588802ad2a6c920a0c1834f618496b2ea294f5f503dfbaa03de0c9b34b576aa32b166faae9163a50e6192b0a1c15719bef5b611067d4e17f72c07db460463926bc9e32dcd29c992c8656ff683f68cdf205750e482140fffbd56e5ca7fcc3db5f47d53623366e244b793dff12cb79ff8fe09750dfca046a43012b5f71a1541972d715b9a43fdd8fe0ca61b6ce00e498d7b2add25c6d46090a445c547ac911cf81435c50c87320589f8a79ea260fa7400ddf46908b89085788a08adfeee1c0efb6304be13dcc5186c347609a698327b2040196db7a117d6379ca622fbc483a7d3d1129a8f3b66eb308cb15ffa74a2bbbc2e474597c6ef3d3012db45e9853b592468ee0341f13400bb1acba8eb89fdd3edc895e03317afedd33e775bbfc4a7a5a0681fc673b3ada518310968e3620cc33c825713d5b84164c09c9be7d226a0a16b6efb07903f299dac7ea141c7dc3eea414217362325198816659cc6b0ce45c1b9238d2f5797926914ad7c228b17480af091acbae1018c4709cd1000a7cdb84d1dbb6dbbbe182f2f15f2e5477b70f85875de098529c83be9f7e35de06fb6865b5d51ee9fdc530540edbf5979f3a69d673867a51ecc2b38f2b63e60f7ad597fe57c84fbf43521f878d18e8a20fa7460dcd0f1e816cb13b23c4277b604c1a44c55d025bc067775affa8f378770431621204863c0f18db2249ac28e7c2ac9dd393fed38af999ab64b92be6c86295cd6b2f9b7e729689f8e4b8bb4ce94940f8bca4898e83165d2731a27a8cb1b4a9350415298c9755ad0370055ef9f32f9a86019b5d8e6e69a1c82c2c8999bd3cfc3ac2d7584cb431c33a29d1941b2acf2167727dee2eb5e747af3206e2e32e641e2830cce65c04b16221e715f02169abc57fd5b346cf432b194093c1a3dbf61673fbcc2da75f8501737ff67c9aff3d684477e10981d66173d025c5d57d76be48342a0add80fb39f0329c140b4e2de8ce2db942b3d0aa90a0944bf59bb72de2156d444f9d6edb9bc5320f75d05ca561cbf477994478498138e0e2db5229ff72bdfe9af675cdad2c235623c1baa6e9506e54a4d4b6d0731b658361eb1c426c31a135444dd1d2242f39d972139da6fa1543a8f87067474c7bf4a07fbaff03d69749cc1a977fa2f617954717fa9e6660c0a025eff4175cbeee57af3bfee602b4d15feebb09b239de8d3d8171791686281805cfca78eca444f7a5d0792f9e6826beb33088cf03f59b6fd7be2309c83ae197bc828c5f6fc8f54d9622d044db4162f33696a9076c48eecdaf85 dd8pe32_big 8b47b3c7549885b8d4b73ded824cd9ccfdb4b0b58ee3474a013577923666cd2f1fdb5e1bf0e55199c8d5965b1ce9a6029572b17745bb20cc4e934f95707cb91807eac441180bc5f44409eec3a1bb37d6333d813bcdda7463f541e5b85c47ba8bf8baa2bfa2547ff45b865d1ea14bd8b76cd9620fcaa3c8632b2fc5abcee2ad77e80808aa7bbd8e9726766177b152756619167b956030c2f5ea3fdd4b9a2711c81202cfafb1f7b1af81f4cef069c0a1fd58cfd6bf3a4a2c14f04881839d1f0a41f54cb10d716a16e28b110fbe0eb891e588ee601e8474e592bf136850b54460a154fe51986a2f81ab29d1a8294990a3df506ced49f0e031119e5eaeadc44a7e1137a223b8cf14d457422db38db5d4c9fd994f3375b476160a95ded20d7d13750ee839bb68589a19088311cc5c5442b1a68e0ecc2689d2ffca746bb75e65bbf86af6353a3940f87d6d5b5e461ad2cd9d95a2993676adde6a70cb05a507d08c5e49357edf4cd218502900e8de5fe09df5da894f4a13e1d1faf0f2d5466ce508a425236fbe5bb2970701687704d9310bc9d83d07ea3f6b2f7714032aaa0399e56a53e4d8d0b146c83caf50c8bb47803fc946fa0ba6cf15ccca76da7b44c0e80af35c4dfdf02e50b0aa79388bf18087354c2f4116132d2bc603878e32ec05d095274ddc94e0459f09327a64f2d26a08ab4cf3d85c26577ff1c08b2cadddc353d89167b6c943fe8741daa0dbee2804c7ae6544c880b3de68d7819b363eb655785562c8463ca1f4df7acb146bb2fc5d8d2cdb29fe9e75e7beb1c0a2272d7a964ac86ee13cff6758028b5037a21f439a262a92fe2941dc2edf71f461b2b39176d61b2b768b9be5ecd1fcdaa8d6e255f462f41572006cf7fe06bb736c4c00c6f63071b7a1690a5009af0b003e1d2bf0b918d19188fc949e3b8ce5da2b3034482e6f1fd0d052bdbf9a83ac780c556936471d09d83179a24c5967fd13da0868aa47abaddac3056b2f1fb88321f81cedab1451e6604b1af32f62acc26e8990a4e52a05d7de8f84ec81fd40eafabbd8fa3aa892b343a2c25a58f34ba7871c54e852309f90879e178c78e78cf02942b0c92ea1c6393ef09b79bf40bad6d64cf226b2b79ffc24ad4bb5bc0e9456f6d790873aafd478b3dc11f03d0cf329f5a5784528942f735acce91adbefd592cec728557396daa3a861d70791b37331a387b81e3a647f83b16209e244ee4dce43bfed6a522f3821c7cee0005c203c31c2084780d59ac1ed742702a94c0380e9269f1562b467738c5dc667f126d7fe225b8a812e471c2ba6d2286d7f2b947673f6179fa7db3f53b45d41e74859ed42af979082de43a6f7d651c706e6fd31bab30bae48046bcad49b5c892255420b1738c5e72c3ae21666da3cb95dd7c31d5ba267be965f6f33f879b83e1d37156f62d1581327e19f74b843f0066bbb52c5eef04f75d08f54b5c2b8e25322efe7ebba43e66edc6657aa34d74c0c01749d0689fc2bd60261eaa175f6c90fbcd6b3e438302b22784d50a7268e3f7d0c54274ec9df89b6fd95675c7008ac0dbdb957557952065def1330f2da94805d57238da2cc6019c055e1645e72f49b3d3bda94ca9f03786ef56602a7a64c6c05951cae9937ffaf7261ebdf3454f5bee18def136550b4aa8206e7368add49022345efa55e0eed461f3e51397f3079e89152205cdcb5b0e5e85eada0c2dcbde7b8cfbfebb264106bebcba237f42124d038570cdf797bf898f101c47511006d6019762336e802020ad1ad83035a49cdcf15fbc3ec1ad540c2c1b468529eadc15cefc2268ce7bd11dca14b0f298ff07ee2bb6ccbbc2f78eed8a801cc361048b768377d49d42ccda9fafad20f9b84d276ad126c1e67399c20f56a361884203ce7ba42b67fdcc6ee400f5532c5af3c882974542e28ed6401a5aeb06665039ff81e29b6c12e4f585e81ecfb1f841dd11f3ce5101fcc2f4ae601259565c1df6eef99308c3333c81be21f870a109603b3cb8c422b805ef434136ca262cff2a78496daf011eaddbcd9c1eaf8748037e258c42709dacba8e677d0d24f3302a74eec69fc2be603ef87f3c7ab7bffb5979fe048504caa02e8933dead379f81e102cc4e5614b00e1a16b9c43d872462dda846e967e8478d5ce6e44b5c215750b4cfc408eda5ba82c9d8b9d09236170311a3e80f35bcf794b81cd5d04a83a42732bdda5ea6b0a7ccee7efd070ebf2940f62dfa7a8c7ef343299eaed3140e1ccc3749f4f834fad6cf76985f25387f0f3d6b3db8701d54a847125e4301bfb2b522de143ace9f23abf19d41b60130261be59010bda50cbe9979da5bcf122fc58eaa822fb3eadf14fdaecbe67d993171eb4b234ae6ae7247bf24e2459942c1bd27aedd7299d66272a426b19007a3a3b9b66bc2ab01a2090516b62cb8673a2e521c07b99e073ae99afa0d5486445f492203b16b233de70f0602dfab9f0e67398254a94f1997f258667beac21f1cc30f6306d269184beee5d3fb77a292a3d1029227f3d5d2db96c5d7d82b8f03f37e2f66e0a937f24d8482138de8de0abc36d409c944150dd96a6c5c12c0475804282d3a4f4c929685bceba20c71e18cbbf063980982d2d4b830b95a64cdee4b63d0a84be7af92f7a8decdd80ee5f7ecb09d7790c6a55598068bcdb45c6dbe3800aa1b1cc5c1525c0c6146f8422c434921061c3a2bdcd18e569efd859d5888db12358b905c2d7957173b98bf88708cfd3d5ab90cb1b6faf4bba5c00415dd9730291a9afbf46bbf9501454d64e932759cced3db72fdfdb55e5febcfd033856980ff6f9577aeeffc3d53f61d49d12614f868326179f3a24354a92cfab44a2e8735985d72bd495a90f919b623a9d223da2b155f744582f596c75e8571b53ce77ef4305585b93e7800f69e6dac3ad3782b7e5b3c586d8977b0dc6331a931d972e6c17d212c79f1111345bf0531fce195c699b832bd9611f8620ff0de38a372f7dbe00dc2205066eabe71e9d5810a7e2c404a53f44ede245ec9d492581afd81c152c0ea62660f92263c2ca267bf88001a64bedf5df26935fe4732e3cc6e1de36ef70374943d5cb831087dcda5087493abe71f147a09ba39466869e2b8837c6ab45bb516f2016f6634f7537976ecd92ca29224969b01a48e122aaecdba3f7b5fc950d1a58e78916697f9b1e5274cb91a84879e32613200515c7acd023f4a173fea56732c94a48ed0ec5ff3c5501e42109c1ca92dc7ae367d66f48648f5ee46bda796a1d577b215fc708999efbbaa3bed77cfa0b7b1b4aa39b313227cbc8a5ae0d9cb943d132957542f654b4b548c58b7ba65de98ab0f215afdd10fe3c1cfe5e68e2c8f0d4abdc5beafd135508663f4dafb188aa23742a3c35047c30c0493b8511d87e5685a5de63625147ba8d96386f8351b8b1f22cf5baf1fd04670941dd6e815837889b6339ef48ecdd7ff0bc09fe5a7fc4443af60d5635e02cb33ffb9a4785bcc17e8fad40ce0e886da7f38142aceb79198cd00bdcfc158d69875b7259563d486115bacff887fba60a9669a1a6ce41bf09991e4a84b82da626bbfda3386920f2cd0c16981b0c288a57153bdc2cb2bb17305d22aad6bfc38fc2893d918757f6ce31fb7e5b1863843ced5366f8fffb0d8911ae6d7f5d68ee748e924344cd04dda22c948df10fb3d18859dffbb27de63d63c44525a4ab2c9b43d1d861c5c15e461ed31874b5d74ba5fe1ab11ef63a86a736d8c30376a8aba5adc6c3db2350dbf562abe7f586fb9b6bf1a6200875fde0fad64da856d701a84d289b1e20719c99041cb29e69c7b7365f7b64ea050fbfa7395d985bfe2cb4094fef721813c5f956e1515518bb9ffdd79677b231779bb12bbb27a426725ecfdacb006244793959774b91798e6cbf7409f485df79d1f735e32b2bce38bbdb1148d11c759bf6ec3f0359e074788dd076c1340988ac9d03e2e6894fe6a37795eef246caa9761002d6a674851399c809102ee32bdc17785f83f428bb335dd8018e6d5a53f2962f9fd9b0590b959b575f53ec66d7126c11c0176faf866f40e419cc3630c6341dccefa2141840adce0b50c967f0bef0c02e46d15b18e7c50b315a39bf91f54c937620be6b1739825248da87308d528d8ca72717e7b444d86070c618ed397607e4d1656aef104bb0cc04811dfc1acdefadeb5685d52566bdc6e3e362c531a2a55e92f526820f1247afcb4d1ea34ba9136473cceaa26243fea69fb9c3f3549963b584098fa7766dc917bdc94f22a42aea58dd864860b79d974fcdd69944523b66ff87e18785f97f2e050e04289b81505891cd84d648c306fbf32b4dfaacb02fceb98bbe9fe8a3afe25d8693d95189e5367c80cbff3a799e0fa80bb1ac43c6df2dc29ae89a40cfa967e7808c44ae4ff44feb486363b6201f2c69531e2dc2c07809d0cca972a12f5a274ffc8c7f3e1a4d65138859d3e253471f14fb30ac089eeedd31515097c3c9f6d325ccb1b9b319852c8dbabd588802ad2a6c920a0c1834f618496b2ea20163f503dfbaa03de0c9b34b576aa32b166faae9163a50e6192b0a1c15719bef5b611067d4e17f72c07db460463926bc9e32dcd29c992c8656ff683f68cdf205750e482140fffbd56e5ca7fcc3dbb7aed53623366e244bebaeff12cb79ff8fe09750dfca446a43012b5f71a1541972d729b9a43fdd8fe0ca6150ce00e472d7b2add25c6d76090a445c547ac911cf81435c50c87320589f8a79ea260fa7407ddf46908b89085788a08adfeee100efb6304be13dcc5186c347609a69c327b2040196db7a117d6379ca622fbc483a7d3d1129a8f3b66eb308cb15ffa74a2bbbc2e474597c6ef3d3012db45e9853b592468ee0341f13400bb1acba8eb89fdd3edc895e03317afedd33e775bbfc4a7a5a0681fc673b3ada518310968e3620cc33c825713d5b84164c09c9be7d226a0a16b6efb07903f299dac7ea141c7dc3eeb203217362325198816659cc6b0ce45c1b9238d2f5797926914ad7c228a47497af091acbae1018c4709cd1001f7ccc84d1dbb6dbbbe182f2f15f2e4177b70f85875de085529c83be9f7e20de06fb6865b5d503e9fdc530540edbf5b79f3a69d673867a51ecc2b38f2b63e60f5ad597fe57c84fbf43d21f878d18e8a20fa7460dcd0f1e816cb13b23c4277b604c1ac4c55d025bc067775affa8f378770431621204863c0f18db2249ac28e7c2ac9dd393fed38af999ab64b92be6c86295cd6b2f9b7e729689f8e4b8bb4ce94940f8bca4898e83165d2731a27a8cb1b4a9350415298c9755ad0370055ef9f32f9a86019b5d8e6e69a1c82c2c8999bd3cfc3ac2d7584cb431c33a54af941b2acf2167727dee2eb5e747af3206e2e32e641e2830ebce5c04b16221e715212169ab107fd5b346cf432b194013c1a3dbf61673fbcc2da75ff901737ff67c9aff3d685477e10981d66173d025f5d57d76be48342a0add80fb39f032dc140b4e2de8ce2db942b3d0aa90a0944bf59bb72de2156d444f9d6edb9b85320f75d05ca561cbf477994478498138e0e2db5229ff72bdfe9af675cdad2c235623c1baa6e9506e54a4d4b6d0731b658361eb1c426c31a135444dd1d2242f39d972139da6fa1543a8f87067474c7bf4a07fbaff03d69749cc1a977fa2f617954717fa32cb60c0a025eff4175cbeee57af3bfee602b4d15feebb09b239de8d3d81dd791686281805cfca78eca444f7a57bd42f9e6826beb33088cf03f59b6f7cbe2309c83ae197bc828c5f6fc85f4d3a22d044dbf362f33696a9076ce2eecdaf85 aes_3blocks 4146515e10aa93a49d1a493158794739b144583e9885b4aa986e36a4d4aa5e5f495522e28b2bd443d1e1a47ee4fb4493 checksum 8a09eab5 huff_ok true huff_out 4869696969696969 bc_ops [Add(5), Xor(170), Rol(3), Inc] bc_lut256 7e666e161e060e363e262ed6dec6cef6fee6ee969e868eb6bea6ae555d454d757d656d151d050d353d252dd5ddc5cdf5fde5ed959d858db5bda5ad58604850788068701820081038402830d8e0c8d0f800e8f098a08890b8c0a8b0575f474f777f676f171f070f373f272fd7dfc7cff7ffe7ef979f878fb7bfa7af525a424a727a626a121a020a323a222ad2dac2caf2fae2ea929a828ab2baa2aa51594149717961691119010931392129d1d9c1c9f1f9e1e991998189b1b9a1a9545c444c747c646c141c040c343c242cd4dcc4ccf4fce4ec949c848cb4bca4ac535b434b737b636b131b030b333b232bd3dbc3cbf3fbe3eb939b838bb3bba3ab565e464e76 advance_key 00025e18 advance_key3 deaed18b [上一页rust\_vectors.rs](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/rust_vectors.rs) [下一页调试日志示例](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/sample-debug-logs) 最后更新于 11天前 --- # Overview | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/analysis.md) . The format contains many byte sequences that can be mistaken for tables or transform programs. Reliable analysis therefore combines structural discovery with independent validation of ranges, checksums, decompression, PE relationships, and expected instruction shapes. GitBook Assistant * [Analysis workflow](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/workflow) GitBook Assistant * [Observed limitations](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/observed-limitations) GitBook Assistant * [il2cpp metadata obfuscation](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/il2cpp-metadata) GitBook Assistant * [Constants and offsets](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/constants) GitBook Assistant [PreviousHtsysm kernel components](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/kernel-components) [NextAnalysis workflow](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/workflow) Last updated 14 hours ago --- # Environment and anti-analysis checks | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/environment-checks.md) . Environment and anti-analysis checks[](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/environment-checks#environment-and-anti-analysis-checks) ---------------------------------------------------------------------------------------------------------------------------------------------------------------- The checks run before (and partly interleaved with) decryption. Grouped by what they target: GitBook Assistant **Debuggers.** A kernel-debugger check (`52F`), a SoftICE/Syser-era check (`BE0`), and timing-sensitive decoys embedded in the loader code (below). The VMware backdoor probe (`540`) doubles as an emulator check: the `in eax, dx` backdoor instruction faults on real hardware and in most emulators but returns a magic value under VMware. GitBook Assistant **Virtual machines.** Registry string checks (`A09`) against three values — `HKLM\Hardware\Description\System\SystemBiosVersion`, `HKLM\SYSTEM\CurrentControlSet\Control\SystemInformation\SystemProductName`, and `HKLM\Hardware\Description\System\BIOS\SystemProductName` — matched at their beginnings against: `Virtual`, `VMware`, `Bochs`, `VBOX`, `VRTUAL`, `Microsoft Hyper-V`, `Parallels`. CPU feature flags are sometimes checked at the same stage (requiring hardware virtualization to be exposed to the guest). GitBook Assistant **System integrity.** OS minimum/compatible version checks (`C00`/`B00`), a boot-options check for `testsigning` or `disableintegritychecks` (`C01`, which blocks the usual unsigned-driver analysis setups), and a check that `C:\Windows\msc.log.log` does not exist (`BD0`). GitBook Assistant **Process integrity.** An injected-DLL sweep (`A0F`), an injected-thread sweep that first kills (`A07`) and then aborts if any remain (`A01`), a parent-process policy (`A03`), and — for protected DLLs — a host-process check (`A11`) that looks for the protector's own markers in the host. The `A07` sweep is why in-process analysis helpers must either run before it or sleep past it. GitBook Assistant **Anti-hooking.** At `A08`/`A04` the loader copies the _code_ of ntdll/kernel32 from the pristine system DLLs on disk into memory and prefers that copy, defeating usermode inline hooks on those modules; `A04` aborts if the on-disk image is itself patched. GitBook Assistant [PreviousStartup sequence and status reporting](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/startup-status) [NextPage protection and loader code](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/page-protection) Last updated 14 hours ago --- # Stage 1 header | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/stage1.md) . The first stage uses a fixed-size parameter area. The observed default outer size is `0x23c` bytes and the word transform uses the constant `0xbf20165d`. Implementations must read the size from the protected section when a build supplies a different value; the defaults are recognition clues, not universal assumptions. GitBook Assistant Header fields[](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/stage1#header-fields) ------------------------------------------------------------------------------------------------------------- The decrypted word header contains eight 32-bit values: GitBook Assistant Field Meaning Required relation `key` GitBook Assistant Per-file arithmetic key GitBook Assistant Non-zero in observed files GitBook Assistant `reserved` GitBook Assistant Reserved word GitBook Assistant Must be zero GitBook Assistant `payload_offset` GitBook Assistant File-relative payload start GitBook Assistant Aligned and inside the private section GitBook Assistant `payload_size` GitBook Assistant Protected payload length GitBook Assistant Non-zero and inside the section GitBook Assistant `payload_key` GitBook Assistant Key passed to the next stage GitBook Assistant Preserved for stage 2 GitBook Assistant `entry_offset` GitBook Assistant Protected entry offset GitBook Assistant Inside the recovered image range GitBook Assistant `protect_size` GitBook Assistant Range covered by protection GitBook Assistant Does not exceed the image GitBook Assistant `size_copy` GitBook Assistant Copy of the payload length GitBook Assistant Must equal `payload_size` GitBook Assistant The words are restored with unsigned 32-bit arithmetic. For word index `i`, the observed form is: GitBook Assistant GitBook AssistantAskCopy plain[i] = (cipher[i] + (i + 3) * key) XOR (0xbf20165d * (i + 1)) All intermediate values wrap at 32 bits. The first word supplies `key`; implementations should restore the complete header and then apply the field checks rather than trusting a single decoded value. GitBook Assistant Fail-closed checks[](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/stage1#fail-closed-checks) ----------------------------------------------------------------------------------------------------------------------- Reject the file when the header is truncated, the reserved word is non-zero, the copied size differs, the payload is unaligned or out of range, or the entry/protected ranges do not fit the image. These checks prevent random section data from being mistaken for a valid stream. GitBook Assistant [PreviousProtected ELF](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/protected-elf) [NextStage 2 streams](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/stage2-streams) Last updated 1 day ago * [Header fields](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/stage1#header-fields) * [Fail-closed checks](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/stage1#fail-closed-checks) --- # 概览 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/analysis/analysis.md) . 格式中存在许多容易被误认为表或变换程序的字节序列。因此，可靠分析必须把结构发现与范围、校验和、解压结果、PE 关系及预期指令形态的独立验证结合起来。 GitBook Assistant * [分析流程](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/analysis/workflow) GitBook Assistant * [已观察到的局限](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/analysis/observed-limitations) GitBook Assistant * [il2cpp 元数据混淆](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/analysis/il2cpp-metadata) GitBook Assistant * [常量与偏移](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/analysis/constants) GitBook Assistant [上一页Htsysm 内核组件](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/kernel-components) [下一页分析流程](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/analysis/workflow) 最后更新于 15小时前 --- # PE 重建 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction.md) . 節恢復得到的是按 RVA 組織的內存映像。要形成可用的 PE 文件，還需要協調頭、文件偏移、數據目錄、導入、TLS 狀態、導出、重定位；託管映像還需要恢復 CLR 結構。 GitBook Assistant * [頭、節與零填充範圍](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/memory-image) GitBook Assistant * [導入、TLS 與導出](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/imports-tls-exports) GitBook Assistant * [重定位、頁變換與 CLR 數據](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/relocations-managed) GitBook Assistant 這些步驟依賴具體佈局。舊版固定基址可執行文件、需要重定基址的 DLL、外置伴生映像與 CLR 映像不能使用同一種數據目錄處理策略。 GitBook Assistant [上一頁結構發現與驗證](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/loading/discovery-validation) [下一頁頭、節與零填充範圍](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/memory-image) 最後更新於 20 小時前 --- # 環境與反分析檢查 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/environment-checks.md) . 環境與反分析檢查[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/environment-checks#huan-jing-yu-fan-fen-xi-jian-cha) -------------------------------------------------------------------------------------------------------------------------------------- 檢查在解密之前（部分與解密交錯）運行。按目標分組： GitBook Assistant **調試器。** 內核調試器檢查（`52F`）、SoftICE/Syser 時代檢查（`BE0`），以及嵌在加載器代碼中的計時敏感誘餌（見下文）。VMware 後門探測（`540`）同時充當模擬器檢查：`in eax, dx` 後門指令在真實硬件與多數模擬器上出錯，但在 VMware 下返回一個魔數。 GitBook Assistant **虛擬機。** 註冊表字符串檢查（`A09`），針對三個值——`HKLM\Hardware\Description\System\SystemBiosVersion`、`HKLM\SYSTEM\CurrentControlSet\Control\SystemInformation\SystemProductName` 與 `HKLM\Hardware\Description\System\BIOS\SystemProductName`——在值的開頭匹配：`Virtual`、`VMware`、`Bochs`、`VBOX`、`VRTUAL`、`Microsoft Hyper-V`、`Parallels`。同一階段有時檢查 CPU 特性標誌（要求硬件虛擬化暴露給客戶機）。 GitBook Assistant **系統完整性。** OS 最低/兼容版本檢查（`C00`/`B00`）、針對 `testsigning` 或 `disableintegritychecks` 的啟動選項檢查（`C01`，它會擋住常見的未簽名驅動分析環境），以及確保 `C:\Windows\msc.log.log` 不存在的檢查（`BD0`）。 GitBook Assistant **進程完整性。** 注入 DLL 清掃（`A0F`）、先殺（`A07`）再在殘留時中止（`A01`）的注入線程清掃、父進程策略（`A03`），以及——對受保護 DLL——宿主進程檢查（`A11`），尋找宿主中保護器自身的標記。`A07` 清掃決定了進程內分析輔助代碼要麼在此之前運行、要麼睡過它。 GitBook Assistant **反鉤子。** 在 `A08`/`A04`，加載器把磁盤上純淨系統 DLL 中 ntdll/kernel32 的_代碼_拷入內存並優先使用之，挫敗對這些模塊的用戶態內聯鉤子；`A04` 在磁盤映像本身被補丁時中止。 GitBook Assistant [上一頁啟動序列與狀態報告](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/startup-status) [下一頁頁保護與加載器代碼](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/page-protection) 最後更新於 20 小時前 --- # 结构发现与验证 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/loading/discovery-validation.md) . 为什么一切都要扫描，以及如何避免选错[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/loading/discovery-validation#wei-shen-me-yi-qie-dou-yao-sao-miao-yi-ji-ru-he-bi-mian-xuan-cuo) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 一个反复出现的事实是：很少有容器对象能在不同构建中保持同一偏移。表的位置会变化，PE32 布局还会应用 `ss_shift`；新版构建会省略标记，无关字节也可能看起来像指针或变换程序。加载器知道编译进自身构建的布局，静态分析则必须从文件中恢复该布局。 GitBook Assistant 不要接受首个匹配。应组合多项独立检查： GitBook Assistant * 检查表的形态，例如等于 `info[3]` 的锚点 dword、`(1, 0, info[3], 0)` 条目，以及边界有效的 `(offset, size)` 对。 GitBook Assistant * 将候选变换程序解析到真正的 `RET`；遇到无效操作码、无效 ModR/M，或只在操作数中偶然出现 `0xC3` 的流就拒绝。 GitBook Assistant * 要求指针指向当前映像或受保护文件中的有效范围。不能只凭指针看似合理就接受候选。 GitBook Assistant * 在不保留修改的前提下试解密候选描述符，再检查源范围与目标范围。 GitBook Assistant * 重放首个压缩节记录，并要求解压结果恰好达到声明大小。只对原始复制记录有效的候选尚未得到验证。 GitBook Assistant * 布局包含校验和链时，还要核对该链。 GitBook Assistant 稀疏页变换需要单独判断。若入口 stub 解码后的调用与跳转目标都位于 `.text` 内，这是一项较强证据；否则应在多个页上比较各候选恢复了多少预期的 `0xCC` 填充，并要求相对原字节有明显改善。少量增长通常只是随机噪声，不能据此执行变换。 GitBook Assistant 若没有候选通过内容检查，应在该阶段停止。输出一个看似正常但已被暗中破坏的 PE，会使后续观察都失去可信度。 GitBook Assistant [上一页PE32、DLL 与无标记布局](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/loading/layout-variants) [下一页PE 重建](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction) 最后更新于 15小时前 --- # 已观察到的局限 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/analysis/observed-limitations.md) . 已观察到的弱点[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/analysis/observed-limitations#yi-guan-cha-dao-de-ruo-dian) ----------------------------------------------------------------------------------------------------------------------------------- 为完整性与后续研究计，以下机制被证明存在不足： GitBook Assistant **VM 检查仅靠配置即可绕过。** 注册表检查只在 BIOS/产品值的_开头_匹配厂商字符串，而至少一家主流虚拟机监控器把其标记放在 BIOS 版本字符串的_末尾_——设置 `SMBIOS.reflectHost = "TRUE"` 即可完全隐藏。VMware 后门探测可用 `monitor_control.restrict_backdoor = "TRUE"` 中和（不安装客户机工具亦可），其他虚拟机监控器则允许直接覆盖 SMBIOS 字符串。 GitBook Assistant **调试日志是自我说明的加载器。** 方便厂商技术支持的状态码设计，同样把逐阶段的执行轨迹和每阶段一个 2 字节搜索模式交给了分析者。mailslot 通道是加密的，但文件日志不是。 GitBook Assistant **页加密败给进程内读者。** 按需解密处理器服务来自同一进程任意线程的缺页，因此进程内的辅助代码可以触及每一页并拷出解密字节。反转储涂写是可逆的；在未启用涂写的构建上，页面本来就是干净的。 GitBook Assistant **内核驱动削弱宿主。** 第一代向任意进程暴露无鉴权的内核 shellcode 执行。第二代的 PID 加密“鉴权”把 `EPROCESS` 写原语授予任何能复现它的程序——一个带签名的 BYOVD——而它设置的 Protected Process 标志既可用内核级手段关掉，也可在其设置前注入来吸收。只有第三代没有给攻击者新的权力。 GitBook Assistant **防篡改链完全可重算。** 容器中的每种变换都可逆（XOR 链、旋转、置换字节码、内嵌调度表的 CBC-AES），每个校验和都是对已知字节的标准 CRC-32。设计里没有任何必须保存在文件之外的秘密。因此校验和链能发现朴素打补丁，却无法阻止打补丁：修改了 payload 的分析者可以重算每一条链式密钥并重新嵌入结果，加载器会接受它。这条链提高了修改的代价，但并不封顶。 GitBook Assistant **进程策略检查很粗糙。** 父进程策略（`A03`）从获批父进程启动即可满足；DLL 宿主检查（`A11`）依赖的工件（`peC` 节、混合大小写的 `KeRnEl32.dLl` 导入）只能识别未修改的宿主。 GitBook Assistant 这些并不让保护变得平凡——分层设计仍需真正的工作量才能端到端分析——但每一条都是文档化、可复现的缺口，而非理论推测。 GitBook Assistant [上一页分析流程](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/analysis/workflow) [下一页il2cpp 元数据混淆](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/analysis/il2cpp-metadata) 最后更新于 16小时前 --- # 概览 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/file-format.md) . Android 格式以普通的 ELF64 小端 AArch64 文件为基础，并加入一个类型为 `SHT_LOUSER` 的私有节。私有节保存受保护载荷；普通动态链接节仍然可见，并用于识别和恢复。 GitBook Assistant 本组先说明外层首部，再说明其中的记录流。边界检查也是格式的一部分，因为单个字段看起来合理，并不能证明文件有效。 GitBook Assistant [上一页CrackProof for Android SO 内部机制](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn) [下一页受保护 ELF](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/protected-elf) 最后更新于 1天前 --- # 概览 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/data-transforms/data-transforms.md) . Android 格式把外层首部的算术变换与容器记录的模块变换组合起来。压缩是独立的一层，必须同时校验输入消耗量和输出长度。 GitBook Assistant 本组只描述可观察字段和公式，不为格式中没有出现的中间状态另造名称。 GitBook Assistant [上一页第二阶段记录流](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/stage2-streams) [下一页模块配置](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/data-transforms/module-config) 最后更新于 1天前 --- # Overview | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/file-format.md) . The Android format starts with a normal ELF64 little-endian AArch64 file and adds one private section with type `SHT_LOUSER`. The private section contains the protected payload. The normal dynamic-linking sections remain visible and are used during recognition and restoration. GitBook Assistant The pages in this group describe the outer header first, then the record stream inside it. Bounds checks are part of the format description because a plausible field is not enough to identify a valid file. GitBook Assistant [PreviousCrackProof for Android SO internals](https://xn--ri8h.gitbook.io/crackproof-research/android-so) [NextProtected ELF](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/protected-elf) Last updated 15 hours ago --- # 概览 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/restoration/restoration.md) . 恢复分阶段进行。首先把记录分发给能够解码它们的模块；然后生成动态链接表和隐藏符号；最后把恢复范围写入一致的 ELF 镜像，并再次校验。 GitBook Assistant 只有字节范围和 ELF 关系都一致时，输出才算可用。 GitBook Assistant [上一页Huffman 与 LZ 压缩](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/data-transforms/compression) [下一页模块记录流](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/restoration/module-streams) 最后更新于 1天前 --- # Dynamic linking | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/restoration/dynamic-linking.md) . The dynamic-linking module restores the information that the Android loader needs after the protected ranges have been expanded. GitBook Assistant Module `0x9D` supplies the target and auxiliary containers used to materialize `.dynsym`, `.dynstr`, `.gnu.hash`, `.gnu.version`, `.gnu.version_r`, and relocation tables. The restored offsets and sizes must fit the corresponding `PT_LOAD` range and the file's alignment rules. GitBook Assistant Module `0x9E` applies hidden-symbol patches. A patch is accepted only when its symbol index, name offset, version index, and target address point into the restored tables. The symbol count used by the GNU hash table, version arrays, and relocation records must agree; a mismatch is rejected rather than repaired heuristically. GitBook Assistant [PreviousModule streams](https://xn--ri8h.gitbook.io/crackproof-research/android-so/restoration/module-streams) [NextELF output](https://xn--ri8h.gitbook.io/crackproof-research/android-so/restoration/elf-output) Last updated 1 day ago --- # Huffman 与 LZ 压缩 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/data-transforms/compression.md) . 压缩写入块由紧凑的 Huffman 表和 LZ 风格的记录流组成。Huffman 节点各占 3 字节；最高位区分叶节点和子节点索引。16 位查找表用于处理代码的前几位，较长代码再沿树读取。 GitBook Assistant 解码符号要么是字面量，要么是长度/距离对。长度/距离对从已经产生的输出窗口复制字节。解码器检查距离非零、不指向输出开头之前，并且复制长度不会超过声明目标。 GitBook Assistant 只有在位读取器消耗允许的输入、输出达到精确大小时，块才有效。提前结束标志、悬空树索引，或文档规定填充之外的尾部字节，都属于格式错误，而不是部分成功。 GitBook Assistant [上一页容器变换](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/data-transforms/container) [下一页概览](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/restoration/restoration) 最后更新于 1天前 --- # 概覽 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/metadata/metadata.md) . 某些 Android 構建會同時保護 IL2CPP 元數據和原生鏡像範圍。元數據規則獨立於 ELF 動態鏈接，因此單獨成組。 GitBook Assistant [上一頁ELF 輸出](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/restoration/elf-output) [下一頁方法令牌](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/metadata/method-tokens) 最後更新於 20 小時前 --- # Overview | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/restoration/restoration.md) . Restoration is staged. First, records are dispatched to the modules that can decode them. Next, dynamic-linking tables and hidden symbols are materialized. Finally, the recovered ranges are written into a coherent ELF image and validated again. GitBook Assistant The output is considered usable only after both byte ranges and ELF relationships agree. GitBook Assistant [PreviousHuffman and LZ compression](https://xn--ri8h.gitbook.io/crackproof-research/android-so/data-transforms/compression) [NextModule streams](https://xn--ri8h.gitbook.io/crackproof-research/android-so/restoration/module-streams) Last updated 15 hours ago --- # Overview | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/data-transforms/data-transforms.md) . The Android format combines a small arithmetic transform for the outer header with module-specific transforms for container records. Compression is a separate layer and is validated by both its input consumption and its output length. GitBook Assistant The pages here describe observable fields and equations. They avoid assigning new names to intermediate states that are not present in the format. GitBook Assistant [PreviousStage 2 streams](https://xn--ri8h.gitbook.io/crackproof-research/android-so/file-format/stage2-streams) [NextModule configuration](https://xn--ri8h.gitbook.io/crackproof-research/android-so/data-transforms/module-config) Last updated 15 hours ago --- # 第二阶段记录流 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/stage2-streams.md) . 第二阶段从流标识 `0xE2` 开始。首部为 8 字节，后面是一系列固定大小的记录描述符。当前观察到的描述符大小为 `0x5c` 字节。 GitBook Assistant 记录边界[](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/stage2-streams#ji-lu-bian-jie) ------------------------------------------------------------------------------------------------------------------- 每个描述符包含命令标识、标志、镜像和元数据偏移、大小、副本标识，以及入口和初始化值。精确载荷从描述符之后开始；读取下一条记录前，必须检查每个偏移和大小都在所属流内。 GitBook Assistant 直接标志值为 `2`。直接记录不是压缩容器，而是指向子流，其标识为 `command_id - 0x10`。只有在对应模块定义存在时才解释该子流。使用 `(流标识, 内容哈希)` 作为键可避免同一子流被重复应用。 GitBook Assistant 嵌套容器[](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/stage2-streams#qian-tao-rong-qi) --------------------------------------------------------------------------------------------------------------------- 非直接记录指向容器载荷。容器描述符及其分段记录由该记录选中的模块解码。一条记录可能同时包含镜像字节和元数据字节；两种范围分开保存，避免把元数据写入 ELF 节段。 GitBook Assistant 描述符截断、范围重叠、子标识不可能，或流没有消耗完声明载荷时，都应拒绝。第一条记录有效并不足够，完整序列必须保持结构一致。 GitBook Assistant [上一页第一阶段首部](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/stage1) [下一页概览](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/data-transforms/data-transforms) 最后更新于 1天前 * [记录边界](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/stage2-streams#ji-lu-bian-jie) * [嵌套容器](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/file-format/stage2-streams#qian-tao-rong-qi) --- # Huffman 與 LZ 壓縮 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/data-transforms/compression.md) . 壓縮寫入塊由緊湊的 Huffman 表和 LZ 風格的記錄流組成。Huffman 節點各佔 3 字節；最高位區分葉節點和子節點索引。16 位查找表用於處理代碼的前幾位，較長代碼再沿樹讀取。 GitBook Assistant 解碼符號要麼是字面量，要麼是長度/距離對。長度/距離對從已經產生的輸出窗口複製字節。解碼器檢查距離非零、不指向輸出開頭之前，並且複製長度不會超過聲明目標。 GitBook Assistant 只有在位讀取器消耗允許的輸入、輸出達到精確大小時，塊才有效。提前結束標誌、懸空樹索引，或文檔規定填充之外的尾部字節，都屬於格式錯誤，而不是部分成功。 GitBook Assistant [上一頁容器變換](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/data-transforms/container) [下一頁概覽](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/restoration/restoration) 最後更新於 20 小時前 --- # 概覽 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/file-format/file-format.md) . Android 格式以普通的 ELF64 小端 AArch64 文件為基礎，並加入一個類型為 `SHT_LOUSER` 的私有節。私有節保存受保護載荷；普通動態鏈接節仍然可見，並用於識別和恢復。 GitBook Assistant 本組先說明外層首部，再說明其中的記錄流。邊界檢查也是格式的一部分，因為單個字段看起來合理，並不能證明文件有效。 GitBook Assistant [上一頁CrackProof for Android SO 內部機制](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw) [下一頁受保護 ELF](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/file-format/protected-elf) 最後更新於 20 小時前 --- # 概覽 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/analysis/analysis.md) . Android 頁面採用失敗即停止的分析路徑。識別、記錄流解碼、ELF 重建和元數據校驗分別提供證據；只有每個階段的證據一致時，候選文件才會輸出。 GitBook Assistant [上一頁存儲佈局](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/metadata/storage-layouts) [下一頁校驗清單](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/analysis/validation) 最後更新於 20 小時前 --- # 概览 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/metadata/metadata.md) . 某些 Android 构建会同时保护 IL2CPP 元数据和原生镜像范围。元数据规则独立于 ELF 动态链接，因此单独成组。 GitBook Assistant [上一页ELF 输出](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/restoration/elf-output) [下一页方法令牌](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-cn/metadata/method-tokens) 最后更新于 1天前 --- # 概覽 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/restoration/restoration.md) . 恢復分階段進行。首先把記錄分發給能夠解碼它們的模塊；然後生成動態鏈接表和隱藏符號；最後把恢復範圍寫入一致的 ELF 鏡像，並再次校驗。 GitBook Assistant 只有字節範圍和 ELF 關係都一致時，輸出才算可用。 GitBook Assistant [上一頁Huffman 與 LZ 壓縮](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/data-transforms/compression) [下一頁模塊記錄流](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/restoration/module-streams) 最後更新於 20 小時前 --- # 概覽 | Android SO | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/data-transforms/data-transforms.md) . Android 格式把外層首部的算術變換與容器記錄的模塊變換組合起來。壓縮是獨立的一層，必須同時校驗輸入消耗量和輸出長度。 GitBook Assistant 本組只描述可觀察字段和公式，不為格式中沒有出現的中間狀態另造名稱。 GitBook Assistant [上一頁第二階段記錄流](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/file-format/stage2-streams) [下一頁模塊配置](https://xn--ri8h.gitbook.io/crackproof-research/android-so/zh-tw/data-transforms/module-config) 最後更新於 20 小時前 --- # 概览 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/file-structure/file-format.md) . Windows 格式保留面向 PE 加载器的有效外层映像，但把原始映像与加载器数据放在按地址组织的独立容器中。分析的第一步是将该容器与普通文件尾数据区分开，并判断所用布局家族。 GitBook Assistant 主题 可确定的内容 [容器与加密头](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/file-structure/container-layout) GitBook Assistant 大偏移范围、八个 dword 组成的 `info` 表及其密钥派生 GitBook Assistant [识别与构建家族](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/file-structure/recognition) GitBook Assistant 用于区分 PE32、PE32+、原生/托管 EXE 与原生/托管 DLL 的证据 GitBook Assistant [节数据与伴生文件](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/file-structure/companion-layout) GitBook Assistant 节记录如何映射到载荷，以及外置 `._` 数据如何与 stub 组合 GitBook Assistant [上一页CrackProof for Windows 内部机制](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn) [下一页容器与加密头](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/file-structure/container-layout) 最后更新于 8小时前 --- # 概览 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/data-transforms/data-transforms.md) . CrackProof 并非只使用一种覆盖整个容器的密码，而是叠加多个小型变换。输入范围、地址依赖与执行顺序都很重要：即使对错误范围使用了正确变换，也可能产生看似合理的字节。 GitBook Assistant 各页按用途拆分： GitBook Assistant * [滚动密钥与旋转密码](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/data-transforms/rolling-and-rotation) 介绍早期阶段与小型记录使用的操作。 GitBook Assistant * [LFSR、字符串与页变换](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/data-transforms/lfsr-strings-pages) 介绍嵌入式指令流、导入名与稀疏代码页变化。 GitBook Assistant * [校验和与密钥推进](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/data-transforms/checksums) 说明记录验证，以及一个结果如何推进下一个密钥。 GitBook Assistant * [AES-CBC](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/data-transforms/aes) 、[Huffman/LZ 压缩](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/data-transforms/compression) 与[按构建定制的字节变换](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/data-transforms/bytecode-transform) 组成主要的节数据处理路径。 GitBook Assistant [上一页节数据与伴生文件](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/file-structure/companion-layout) [下一页滚动密钥与旋转密码](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/data-transforms/rolling-and-rotation) 最后更新于 15小时前 --- # 概覽 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/file-structure/file-format.md) . Windows 格式保留面向 PE 加載器的有效外層映像，但把原始映像與加載器數據放在按地址組織的獨立容器中。分析的第一步是將該容器與普通文件尾數據區分開，並判斷所用佈局家族。 GitBook Assistant 主題 可確定的內容 [容器與加密頭](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/file-structure/container-layout) GitBook Assistant 大偏移範圍、八個 dword 組成的 `info` 表及其密鑰派生 GitBook Assistant [識別與構建家族](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/file-structure/recognition) GitBook Assistant 用於區分 PE32、PE32+、原生/託管 EXE 與原生/託管 DLL 的證據 GitBook Assistant [節數據與伴生文件](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/file-structure/companion-layout) GitBook Assistant 節記錄如何映射到載荷，以及外置 `._` 數據如何與 stub 組合 GitBook Assistant [上一頁CrackProof for Windows 內部機制](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw) [下一頁容器與加密頭](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/file-structure/container-layout) 最後更新於 20 小時前 --- # 概覽 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/data-transforms.md) . CrackProof 並非只使用一種覆蓋整個容器的密碼，而是疊加多個小型變換。輸入範圍、地址依賴與執行順序都很重要：即使對錯誤範圍使用了正確變換，也可能產生看似合理的字節。 GitBook Assistant 各頁按用途拆分： GitBook Assistant * [滾動密鑰與旋轉密碼](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/rolling-and-rotation) 介紹早期階段與小型記錄使用的操作。 GitBook Assistant * [LFSR、字符串與頁變換](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/lfsr-strings-pages) 介紹嵌入式指令流、導入名與稀疏代碼頁變化。 GitBook Assistant * [校驗和與密鑰推進](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/checksums) 說明記錄驗證，以及一個結果如何推進下一個密鑰。 GitBook Assistant * [AES-CBC](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/aes) 、[Huffman/LZ 壓縮](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/compression) 與[按構建定製的字節變換](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/bytecode-transform) 組成主要的節數據處理路徑。 GitBook Assistant [上一頁節數據與伴生文件](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/file-structure/companion-layout) [下一頁滾動密鑰與旋轉密碼](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/rolling-and-rotation) 最後更新於 20 小時前 --- # 环境与反分析检查 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/environment-checks.md) . 环境与反分析检查[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/environment-checks#huan-jing-yu-fan-fen-xi-jian-cha) -------------------------------------------------------------------------------------------------------------------------------------- 检查在解密之前（部分与解密交错）运行。按目标分组： GitBook Assistant **调试器。** 内核调试器检查（`52F`）、SoftICE/Syser 时代检查（`BE0`），以及嵌在加载器代码中的计时敏感诱饵（见下文）。VMware 后门探测（`540`）同时充当模拟器检查：`in eax, dx` 后门指令在真实硬件与多数模拟器上出错，但在 VMware 下返回一个魔数。 GitBook Assistant **虚拟机。** 注册表字符串检查（`A09`），针对三个值——`HKLM\Hardware\Description\System\SystemBiosVersion`、`HKLM\SYSTEM\CurrentControlSet\Control\SystemInformation\SystemProductName` 与 `HKLM\Hardware\Description\System\BIOS\SystemProductName`——在值的开头匹配：`Virtual`、`VMware`、`Bochs`、`VBOX`、`VRTUAL`、`Microsoft Hyper-V`、`Parallels`。同一阶段有时检查 CPU 特性标志（要求硬件虚拟化暴露给客户机）。 GitBook Assistant **系统完整性。** OS 最低/兼容版本检查（`C00`/`B00`）、针对 `testsigning` 或 `disableintegritychecks` 的启动选项检查（`C01`，它会挡住常见的未签名驱动分析环境），以及确保 `C:\Windows\msc.log.log` 不存在的检查（`BD0`）。 GitBook Assistant **进程完整性。** 注入 DLL 清扫（`A0F`）、先杀（`A07`）再在残留时中止（`A01`）的注入线程清扫、父进程策略（`A03`），以及——对受保护 DLL——宿主进程检查（`A11`），寻找宿主中保护器自身的标记。`A07` 清扫决定了进程内分析辅助代码要么在此之前运行、要么睡过它。 GitBook Assistant **反钩子。** 在 `A08`/`A04`，加载器把磁盘上纯净系统 DLL 中 ntdll/kernel32 的_代码_拷入内存并优先使用之，挫败对这些模块的用户态内联钩子；`A04` 在磁盘映像本身被补丁时中止。 GitBook Assistant [上一页启动序列与状态报告](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/startup-status) [下一页页保护与加载器代码](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/page-protection) 最后更新于 15小时前 --- # 已觀察到的侷限 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/analysis/observed-limitations.md) . 已觀察到的弱點[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/analysis/observed-limitations#yi-guan-cha-dao-de-ruo-dian) ----------------------------------------------------------------------------------------------------------------------------------- 為完整性與後續研究計，以下機制被證明存在不足： GitBook Assistant **VM 檢查僅靠配置即可繞過。** 註冊表檢查只在 BIOS/產品值的_開頭_匹配廠商字符串，而至少一家主流虛擬機監控器把其標記放在 BIOS 版本字符串的_末尾_——設置 `SMBIOS.reflectHost = "TRUE"` 即可完全隱藏。VMware 後門探測可用 `monitor_control.restrict_backdoor = "TRUE"` 中和（不安裝客戶機工具亦可），其他虛擬機監控器則允許直接覆蓋 SMBIOS 字符串。 GitBook Assistant **調試日誌是自我說明的加載器。** 方便廠商技術支持的狀態碼設計，同樣把逐階段的執行軌跡和每階段一個 2 字節搜索模式交給了分析者。mailslot 通道是加密的，但文件日誌不是。 GitBook Assistant **頁加密敗給進程內讀者。** 按需解密處理器服務來自同一進程任意線程的缺頁，因此進程內的輔助代碼可以觸及每一頁並拷出解密字節。反轉儲塗寫是可逆的；在未啟用塗寫的構建上，頁面本來就是乾淨的。 GitBook Assistant **內核驅動削弱宿主。** 第一代向任意進程暴露無鑑權的內核 shellcode 執行。第二代的 PID 加密“鑑權”把 `EPROCESS` 寫原語授予任何能復現它的程序——一個帶簽名的 BYOVD——而它設置的 Protected Process 標誌既可用內核級手段關掉，也可在其設置前注入來吸收。只有第三代沒有給攻擊者新的權力。 GitBook Assistant **防篡改鏈完全可重算。** 容器中的每種變換都可逆（XOR 鏈、旋轉、置換字節碼、內嵌調度表的 CBC-AES），每個校驗和都是對已知字節的標準 CRC-32。設計裡沒有任何必須保存在文件之外的秘密。因此校驗和鏈能發現樸素打補丁，卻無法阻止打補丁：修改了 payload 的分析者可以重算每一條鏈式密鑰並重新嵌入結果，加載器會接受它。這條鏈提高了修改的代價，但並不封頂。 GitBook Assistant **進程策略檢查很粗糙。** 父進程策略（`A03`）從獲批父進程啟動即可滿足；DLL 宿主檢查（`A11`）依賴的工件（`peC` 節、混合大小寫的 `KeRnEl32.dLl` 導入）只能識別未修改的宿主。 GitBook Assistant 這些並不讓保護變得平凡——分層設計仍需真正的工作量才能端到端分析——但每一條都是文檔化、可復現的缺口，而非理論推測。 GitBook Assistant [上一頁分析流程](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/analysis/workflow) [下一頁il2cpp 元數據混淆](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/analysis/il2cpp-metadata) 最後更新於 20 小時前 --- # 結構發現與驗證 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/loading/discovery-validation.md) . 為什麼一切都要掃描，以及如何避免選錯[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/loading/discovery-validation#wei-shen-mo-yi-qie-dou-yao-sao-miao-yi-ji-ru-he-bi-mian-xuan-cuo) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 一個反覆出現的事實是：很少有容器對象能在不同構建中保持同一偏移。表的位置會變化，PE32 佈局還會應用 `ss_shift`；新版構建會省略標記，無關字節也可能看起來像指針或變換程序。加載器知道編譯進自身構建的佈局，靜態分析則必須從文件中恢復該佈局。 GitBook Assistant 不要接受首個匹配。應組合多項獨立檢查： GitBook Assistant * 檢查表的形態，例如等於 `info[3]` 的錨點 dword、`(1, 0, info[3], 0)` 條目，以及邊界有效的 `(offset, size)` 對。 GitBook Assistant * 將候選變換程序解析到真正的 `RET`；遇到無效操作碼、無效 ModR/M，或只在操作數中偶然出現 `0xC3` 的流就拒絕。 GitBook Assistant * 要求指針指向當前映像或受保護文件中的有效範圍。不能只憑指針看似合理就接受候選。 GitBook Assistant * 在不保留修改的前提下試解密候選描述符，再檢查源範圍與目標範圍。 GitBook Assistant * 重放首個壓縮節記錄，並要求解壓結果恰好達到聲明大小。只對原始複製記錄有效的候選尚未得到驗證。 GitBook Assistant * 佈局包含校驗和鏈時，還要核對該鏈。 GitBook Assistant 稀疏頁變換需要單獨判斷。若入口 stub 解碼後的調用與跳轉目標都位於 `.text` 內，這是一項較強證據；否則應在多個頁上比較各候選恢復了多少預期的 `0xCC` 填充，並要求相對原字節有明顯改善。少量增長通常只是隨機噪聲，不能據此執行變換。 GitBook Assistant 若沒有候選通過內容檢查，應在該階段停止。輸出一個看似正常但已被暗中破壞的 PE，會使後續觀察都失去可信度。 GitBook Assistant [上一頁PE32、DLL 與無標記佈局](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/loading/layout-variants) [下一頁PE 重建](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction) 最後更新於 20 小時前 --- # Loading and section recovery | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/loading.md) . The bootstrap does not expose one stable table at a fixed offset. It decrypts several stages, and later stages contain the records and transform programs required to recover the original sections. GitBook Assistant * [Stage chain and marker layout](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/loading/stage-chain) follows the common 64-bit sequence. GitBook Assistant * [PE32, DLL, and marker-less layouts](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/loading/layout-variants) records the main structural differences. GitBook Assistant * [Structural discovery and validation](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/loading/discovery-validation) explains how candidates are selected when fixed markers are absent and how a trial decode rejects false matches. GitBook Assistant [PreviousPer-build byte transform](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/bytecode-transform) [NextStage chain and marker layout](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/loading/stage-chain) Last updated 14 hours ago --- # 重定位、頁變換與 CLR 數據 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/relocations-managed.md) . 重定位與 /FIXED 分野[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/relocations-managed#zhong-ding-wei-yu-fixed-fen-ye) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 各構建刻意在結果可否重定向上不同： GitBook Assistant * **較舊單文件 EXE 構建是** `**/FIXED**`**。** 外殼丟棄基址重定位表並清空 `DllCharacteristics`；映像只能在首選基址加載。忠實的重建鏡像這一點：`DataDirectory[5]` 清零、`DllCharacteristics` 清零。 GitBook Assistant * **DLL（任何佈局）必須保持可重定位。** DLL 幾乎總是被映射到非首選基址；剝離其重定位會使其無法加載。重建保留 `DataDirectory[5]` 並確保置位 `IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE`（`0x0040`）。 GitBook Assistant * **無標記與伴生構建不是** `**/FIXED**`**。** 它們攜帶真實的 ASLR 標誌與有效重定位表，任何重定向都必須重定位一切——包括已還原 TLS 目錄的指針，這正是 TLS 還原期間要追加重定位的原因。 GitBook Assistant 代碼頁擾動，排在最後[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/relocations-managed#dai-ma-ye-rao-dong-pai-zai-zui-hou) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [頁級擾動](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/lfsr-strings-pages#%E9%A0%81%E7%B4%9A%E4%BB%A3%E7%A2%BC%E6%93%BE%E5%8B%95) 在節恢復之後施加於 `.text`。各家族觀察到的順序約束： GitBook Assistant * **標記佈局**：擾動在入口點/數據目錄還原之前運行。 GitBook Assistant * **無標記佈局**：擾動推遲到導入名解密之後，並在最終字節上重新選擇——且僅當入口點落在 `.text` 內才運行。託管映像在擾動**之後**才恢復 CLR 元數據，因為元數據區域位於 `.text` 內但不是被擾動的代碼：擾動它會每 16 字節約破壞 1 字節，產生無效的 COR20 簽名。 GitBook Assistant * **32 位**：當節已是明文（原生 DLL）時完全跳過擾動，通過比較 `0xCC` 還原得分與無擾動基線來檢測。 GitBook Assistant CLR 元數據與方法體必須分別處理[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/relocations-managed#clr-yuan-shu-ju-yu-fang-fa-ti-bi-xu-fen-bie-chu-li) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 某些託管佈局會在受保護文件按 RVA 映射後的文件偏移處原樣保留 COR20 頭（`cb == 0x48`）、BSJB 元數據流與 CLR 資源。節恢復完成後，可以把這些範圍複製回去。在無標記佈局中，應在頁變換之後恢復它們，因為這些數據可能位於 `.text` 地址範圍內，卻不是需要變換的代碼。 GitBook Assistant 保留的元數據**不包含每個 IL 方法體的明文副本**。方法體位於 PE 節中，仍受該構建的節數據變換與頁變換影響。若直接用受保護文件填充整個節，就可能用變換後的字節覆蓋已經正確恢復的方法。應先恢復節內容，再僅替換經過獨立驗證的 COR20、BSJB 與資源範圍。 GitBook Assistant 如果恢復後的 COR20 目錄指向 `cb` 為零的頭，並且沒有有效的保留頭可用，就應清除該目錄。把空頭交給 CLR 啟動路徑會失敗，而且容易被誤判為節恢復錯誤。混合模式映像還必須保留原生入口標誌；純託管映像應與該情況分開判斷。 GitBook Assistant Unity il2cpp 作品在 PE 之外還有一層獨立混淆：`global-metadata.dat` 內的方法令牌。見 [il2cpp 元數據混淆](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/analysis/il2cpp-metadata) 。 GitBook Assistant [上一頁導入、TLS 與導出](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/imports-tls-exports) [下一頁概覽](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/runtime) 最後更新於 20 小時前 * [重定位與 /FIXED 分野](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/relocations-managed#zhong-ding-wei-yu-fixed-fen-ye) * [代碼頁擾動，排在最後](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/relocations-managed#dai-ma-ye-rao-dong-pai-zai-zui-hou) * [CLR 元數據與方法體必須分別處理](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/relocations-managed#clr-yuan-shu-ju-yu-fang-fa-ti-bi-xu-fen-bie-chu-li) --- # 節數據與伴生文件 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/file-structure/companion-layout.md) . 在文件中定位節數據[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/file-structure/companion-layout#zai-wen-jian-zhong-ding-wei-jie-shu-ju) -------------------------------------------------------------------------------------------------------------------------------------------------- 加載器表內的節內容描述符存儲的偏移，相對於一個本身以補碼編碼在文件偏移 `0x1080` 處的基址： GitBook Assistant GitBook Assistant詢問複製 section_data_file_base = (~u32@0x1080) + 0x1000 (32-bit wrapping) 因此描述符的 `src` 字段映射到文件偏移 `src + section_data_file_base`。同一公式出現在所有構建家族中（在加載器代碼裡既稱 `rebase` 又稱 `compress_data_offset`）。 GitBook Assistant 外置伴生體佈局（`._` 文件）[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/file-structure/companion-layout#wai-zhi-ban-sheng-ti-bu-ju-.-wen-jian) -------------------------------------------------------------------------------------------------------------------------------------------------------- 某些構建——目前僅在 il2cpp 作品上觀察到——把受保護模塊拆成一對文件： GitBook Assistant * `**Foo.dll**`——磁盤上的瘦**加載器 stub**。其代碼節被裁剪到只剩一頁（即 CrackProof 加載器本體），但其頭部與 `.rdata` 是完整明文。 GitBook Assistant * `**Foo.dll._**`——全加密的**伴生體**，持有真正的 payload。它不含任何明文 PE 結構（熵 ≈ 8 比特/字節）。 GitBook Assistant 伴生體逐字節等於 stub 自 CrackProof 頭部（偏移 4096）起的 payload 區。運行時加載器映射 `Foo.dll._` 並對其執行常規解包；實際運行的模塊實際上就是拼接體 `stub[..4096] ++ companion`。 GitBook Assistant 配對關係由 32 字節精確匹配確認：`stub[4096..4128] == companion[0..32]`。這 32 字節覆蓋加密 info 頭（密鑰表與 magic），因此匹配即證明該伴生體就是此 stub 的 payload，而非無關文件。 GitBook Assistant stub 以明文保留的內容對後續重建很重要： GitBook Assistant * **導出目錄**（伴生體在此處解密為密文；加載器運行時從 stub 的副本重建導出）。 GitBook Assistant * **TLS 目錄**——`IMAGE_TLS_DIRECTORY` 結構體、其原始數據模板與數據目錄項，這些都被保護層從加密 payload 中剝離（見 [PE 變換](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction) ）。 GitBook Assistant * 真實的 `DllCharacteristics` 字段與基址重定位表——伴生模塊**不是** `/FIXED`，與較舊的單文件構建不同。 GitBook Assistant 關於此文件對在啟動時如何加載，見[運行時行為](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/runtime) ；關於缺失部分如何被還原進重建映像，見 [PE 變換](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction) 。 GitBook Assistant [上一頁識別與構建家族](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/file-structure/recognition) [下一頁概覽](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/data-transforms) 最後更新於 20 小時前 * [在文件中定位節數據](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/file-structure/companion-layout#zai-wen-jian-zhong-ding-wei-jie-shu-ju) * [外置伴生體佈局（.\_ 文件）](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/file-structure/companion-layout#wai-zhi-ban-sheng-ti-bu-ju-.-wen-jian) --- # Overview | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/runtime.md) . The runtime combines ordinary user-mode loading work with environment checks, optional kernel support, and page-level code protection. GitBook Assistant Area Detail Startup GitBook Assistant [Boot order, status values, and debug logging](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/startup-status) GitBook Assistant Environment GitBook Assistant [User-mode and kernel-assisted checks](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/environment-checks) GitBook Assistant Code pages GitBook Assistant [On-demand page changes and loader-code variation](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/page-protection) GitBook Assistant Embedded components GitBook Assistant [Manually mapped helper modules](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/mapped-modules) GitBook Assistant Kernel GitBook Assistant [Htsysm generations and responsibilities](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/kernel-components) GitBook Assistant [PreviousRelocations, page transforms, and CLR data](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction/relocations-managed) [NextStartup sequence and status reporting](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/startup-status) Last updated 14 hours ago --- # Section data and companion files | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/companion-layout.md) . Locating section data in the file[](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/companion-layout#locating-section-data-in-the-file) --------------------------------------------------------------------------------------------------------------------------------------------------------------- Section-content descriptors inside the loader tables store offsets relative to a base that is itself complement-encoded in the file at offset `0x1080`: GitBook Assistant GitBook AssistantAskCopy section_data_file_base = (~u32@0x1080) + 0x1000 (32-bit wrapping) A descriptor's `src` field therefore maps to file offset `src + section_data_file_base`. The same formula appears in every build family (it is referenced as both `rebase` and `compress_data_offset` in loader code). GitBook Assistant The external-companion layout (`._` files)[](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/companion-layout#the-external-companion-layout-._-files) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Some builds — observed so far on il2cpp titles — split a protected module into two files: GitBook Assistant * `**Foo.dll**` — a thin on-disk **loader stub**. Its code sections are stripped down to a single page (the CrackProof loader itself), but its headers and `.rdata` are intact plaintext. GitBook Assistant * `**Foo.dll._**` — the encrypted **companion**, holding the real payload. It contains no plaintext PE structures at all (entropy ≈ 8 bits/byte). GitBook Assistant The companion is byte-for-byte the stub's payload region starting at the CrackProof header (offset 4096) onward. At runtime the loader maps `Foo.dll._` and runs the ordinary unpack over it; the module that runs is effectively the splice `stub[..4096] ++ companion`. GitBook Assistant The pairing is confirmed by a 32-byte exact match: `stub[4096..4128] == companion[0..32]`. These 32 bytes cover the encrypted info header (key table and magic), so a match proves the companion is this stub's payload and not an unrelated file. GitBook Assistant What the stub retains in plaintext matters for later reconstruction: GitBook Assistant * The **export directory** (the companion decrypts to ciphertext here; the loader rebuilds exports at runtime from the stub's copy). GitBook Assistant * The **TLS directory** — the `IMAGE_TLS_DIRECTORY` struct, its raw-data template, and the data-directory entry, all of which the packer strips from the encrypted payload (see [PE transformations](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction) ). GitBook Assistant * A real `DllCharacteristics` field and base-relocation table — companion modules are **not** `/FIXED`, unlike the older single-file builds. GitBook Assistant For the boot-time view of how this pair is loaded, see [Runtime behavior](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/runtime) ; for how the missing pieces are restored into a reconstructed image, see [PE transformations](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction) . GitBook Assistant [PreviousRecognition and build families](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/recognition) [NextOverview](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/data-transforms) Last updated 5 hours ago * [Locating section data in the file](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/companion-layout#locating-section-data-in-the-file) * [The external-companion layout (.\_ files)](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/companion-layout#the-external-companion-layout-._-files) --- # 重定位、页变换与 CLR 数据 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction/relocations-managed.md) . 重定位与 /FIXED 分野[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction/relocations-managed#zhong-ding-wei-yu-fixed-fen-ye) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 各构建刻意在结果可否重定向上不同： GitBook Assistant * **较旧单文件 EXE 构建是** `**/FIXED**`**。** 外壳丢弃基址重定位表并清空 `DllCharacteristics`；映像只能在首选基址加载。忠实的重建镜像这一点：`DataDirectory[5]` 清零、`DllCharacteristics` 清零。 GitBook Assistant * **DLL（任何布局）必须保持可重定位。** DLL 几乎总是被映射到非首选基址；剥离其重定位会使其无法加载。重建保留 `DataDirectory[5]` 并确保置位 `IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE`（`0x0040`）。 GitBook Assistant * **无标记与伴生构建不是** `**/FIXED**`**。** 它们携带真实的 ASLR 标志与有效重定位表，任何重定向都必须重定位一切——包括已还原 TLS 目录的指针，这正是 TLS 还原期间要追加重定位的原因。 GitBook Assistant 代码页扰动，排在最后[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction/relocations-managed#dai-ma-ye-rao-dong-pai-zai-zui-hou) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [页级扰动](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/data-transforms/lfsr-strings-pages#%E9%A1%B5%E7%BA%A7%E4%BB%A3%E7%A0%81%E6%89%B0%E5%8A%A8) 在节恢复之后施加于 `.text`。各家族观察到的顺序约束： GitBook Assistant * **标记布局**：扰动在入口点/数据目录还原之前运行。 GitBook Assistant * **无标记布局**：扰动推迟到导入名解密之后，并在最终字节上重新选择——且仅当入口点落在 `.text` 内才运行。托管映像在扰动**之后**才恢复 CLR 元数据，因为元数据区域位于 `.text` 内但不是被扰动的代码：扰动它会每 16 字节约破坏 1 字节，产生无效的 COR20 签名。 GitBook Assistant * **32 位**：当节已是明文（原生 DLL）时完全跳过扰动，通过比较 `0xCC` 还原得分与无扰动基线来检测。 GitBook Assistant CLR 元数据与方法体必须分别处理[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction/relocations-managed#clr-yuan-shu-ju-yu-fang-fa-ti-bi-xu-fen-bie-chu-li) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 某些托管布局会在受保护文件按 RVA 映射后的文件偏移处原样保留 COR20 头（`cb == 0x48`）、BSJB 元数据流与 CLR 资源。节恢复完成后，可以把这些范围复制回去。在无标记布局中，应在页变换之后恢复它们，因为这些数据可能位于 `.text` 地址范围内，却不是需要变换的代码。 GitBook Assistant 保留的元数据**不包含每个 IL 方法体的明文副本**。方法体位于 PE 节中，仍受该构建的节数据变换与页变换影响。若直接用受保护文件填充整个节，就可能用变换后的字节覆盖已经正确恢复的方法。应先恢复节内容，再仅替换经过独立验证的 COR20、BSJB 与资源范围。 GitBook Assistant 如果恢复后的 COR20 目录指向 `cb` 为零的头，并且没有有效的保留头可用，就应清除该目录。把空头交给 CLR 启动路径会失败，而且容易被误判为节恢复错误。混合模式映像还必须保留原生入口标志；纯托管映像应与该情况分开判断。 GitBook Assistant Unity il2cpp 作品在 PE 之外还有一层独立混淆：`global-metadata.dat` 内的方法令牌。见 [il2cpp 元数据混淆](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/analysis/il2cpp-metadata) 。 GitBook Assistant [上一页导入、TLS 与导出](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction/imports-tls-exports) [下一页概览](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/runtime) 最后更新于 8小时前 * [重定位与 /FIXED 分野](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction/relocations-managed#zhong-ding-wei-yu-fixed-fen-ye) * [代码页扰动，排在最后](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction/relocations-managed#dai-ma-ye-rao-dong-pai-zai-zui-hou) * [CLR 元数据与方法体必须分别处理](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction/relocations-managed#clr-yuan-shu-ju-yu-fang-fa-ti-bi-xu-fen-bie-chu-li) --- # 導入、TLS 與導出 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/imports-tls-exports.md) . 導入：加密的名字，重建的表[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/imports-tls-exports#dao-ru-jia-mi-de-ming-zi-chong-jian-de-biao) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 導入名（DLL 名與按名函數名）以[字符串密碼](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/lfsr-strings-pages#%E5%B0%8E%E5%85%A5%E5%90%8D%E5%AD%97%E7%AC%A6%E4%B8%B2%E5%AF%86%E7%A2%BC) 加密，密鑰是各字符串自身 RVA 的低字節。各家族的還原遍歷不同，但收尾規則一致： GitBook Assistant * 每個名字就地解密並轉小寫。 GitBook Assistant * 按名 thunk 的 hint/name 字符串被解密，2 字節 hint 字段清零。序數 thunk（最高位置位——PE32+ 為 bit 63，PE32 為 bit 31）跳過。只讀 PE32+ thunk 的低 dword 會把序數誤當成小 RVA 而破壞頭部——8 字節寬度很關鍵。 GitBook Assistant * IAT 數據目錄（第 12 項）邊界經由首個 thunk 追蹤恢復。 GitBook Assistant 表來源各異： GitBook Assistant * **標記佈局（64 位）**：stage 5 內的 walk5 加密指針表。walk5 指針為 null 表示沒有表可走——託管程序集把該槽留空，因為它們的導入只是 CLR 引導 stub。 GitBook Assistant * **無標記佈局**：PE 導入目錄本身，由 `DataDirectory[1]` 驅動——當元數據的導入目錄為零時（託管映像常見）回退到錨點階段保存的值。名字解密在代碼頁擾動之後運行，因為這些構建上導入字符串位於 `.text` 內。 GitBook Assistant * **專用 DLL 佈局**：現有表的就地解密。 GitBook Assistant * **32 位**：EighthStage 導入表，或校驗更優時取元數據目錄。 GitBook Assistant `**.kmiat**` **搬遷（32 位 EXE）。** 當加載器寫出的 IAT 與原 `.idata` 佈局不符時，導入元數據（描述符、查找表、名字池）被重建進最後一節，更名 `.kmiat`，大小 `0x7000`，特徵 `0xE0000060`；活動 IAT 留在原 RVA，導入目錄改指新表。`api-ms-win-crt-*` 名歸一為 `ucrtbase.dll`。DLL 跳過此步——它們保留真實的導入表。 GitBook Assistant TLS 被剝離並在運行時重裝[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/imports-tls-exports#tls-bei-bao-li-bing-zai-yun-xing-shi-zhong-zhuang) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 保護層移除整個 `IMAGE_TLS_DIRECTORY`：數據目錄項、結構體、原始數據模板，以及覆蓋結構體指針字段的基址重定位。運行時加載器在映射模塊時自行重裝 TLS。 GitBook Assistant 靜態重建的映像得不到這種待遇——普通 Windows 加載器需要有效的 TLS 目錄，否則不會分配 TLS 槽、不會寫 `_tls_index`。此後每次 C++ `thread_local` 訪問都經由一個垃圾槽解析，模塊在初始化期間崩潰（運行時初始化深處 `0xC0000005`）。真正的目錄在加載器 stub 的 `.rdata`/`.tls` 中以明文倖存（單文件構建保留在受保護文件內；伴生布局保留在 stub 中），因此重建時按 RVA 逐字節覆蓋結構體與原始數據模板，併為結構體的四個 64 位指針字段追加 `DIR64` 基址重定位。較舊的單文件構建早於這種剝離，根本沒有 TLS 目錄。 GitBook Assistant 導出以明文倖存——在別處[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/imports-tls-exports#dao-chu-yi-ming-wen-xing-cun-zai-bie-chu) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 導出目錄在 payload 中從不加密。它住在哪裡取決於佈局： GitBook Assistant * **單文件佈局**：導出區域以明文留在受保護文件中其 RVA 處；加載器原樣拷入映像。（該區域經 `DataDirectory[0]` 定位，可從明文頭部讀取。） GitBook Assistant * **外置伴生布局**：伴生體在導出區域解密為垃圾（`NumberOfFunctions` 等均為密文）。運行時加載器從 stub `.rdata` 中保留的明文副本重建導出。靜態重建同樣必須從 stub 覆蓋導出目錄區域，否則分析工具會在導出表上出錯。 GitBook Assistant [上一頁頭、節與零填充範圍](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/memory-image) [下一頁重定位、頁變換與 CLR 數據](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/relocations-managed) 最後更新於 20 小時前 * [導入：加密的名字，重建的表](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/imports-tls-exports#dao-ru-jia-mi-de-ming-zi-chong-jian-de-biao) * [TLS 被剝離並在運行時重裝](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/imports-tls-exports#tls-bei-bao-li-bing-zai-yun-xing-shi-zhong-zhuang) * [導出以明文倖存——在別處](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/imports-tls-exports#dao-chu-yi-ming-wen-xing-cun-zai-bie-chu) --- # CrackProof for Windows internals | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/readme.md) . CrackProof for Windows protects PE32 and PE32+ executables and DLLs. The protected file retains enough PE structure to load a bootstrap image, while original sections, loader stages, selected directories, names, and code pages are stored in transformed form. The runtime reconstructs the image before transferring control to the original program. GitBook Assistant The observed layouts include native and managed images, older marker-based containers, newer layouts that must be identified structurally, and stub executables whose protected payload is stored in a companion file. GitBook Assistant Conventions[](https://xn--ri8h.gitbook.io/crackproof-research/windows#conventions) ----------------------------------------------------------------------------------- * All offsets are hexadecimal byte offsets from the start of the file unless noted otherwise. `u32@X` means the little-endian 32-bit value at offset X. GitBook Assistant * **RVA** (relative virtual address) is used in the usual PE sense. The loader works on a memory image laid out by RVA; on disk the same offsets are used as file offsets into the unpacked image buffer. GitBook Assistant * Integer arithmetic is fixed-width (32-bit or 8-bit) with wraparound, matching the x86 environment the algorithms come from. The Python reference code applies explicit masks for this. GitBook Assistant * Names like `info[3]` refer to entries of the 8-dword table derived from the encrypted file header (see [The protected file format](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/file-format) ). GitBook Assistant Contents[](https://xn--ri8h.gitbook.io/crackproof-research/windows#contents) ----------------------------------------------------------------------------- Area Start here On-disk layout and build recognition GitBook Assistant [Protected file structure](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/file-format) GitBook Assistant Ciphers, compression, and checksums GitBook Assistant [Data transforms](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/data-transforms) GitBook Assistant Loader stages and section recovery GitBook Assistant [Loading and section recovery](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/loading) GitBook Assistant Headers, directories, imports, and CLR data GitBook Assistant [PE reconstruction](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction) GitBook Assistant Startup checks, page protection, and kernel components GitBook Assistant [Runtime behavior](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/runtime) GitBook Assistant Analysis workflow, limitations, and constants GitBook Assistant [Analysis notes](https://xn--ri8h.gitbook.io/crackproof-research/windows/analysis/analysis) GitBook Assistant Tested code corresponding to the Windows transform pages is published in [Verification and reference](https://xn--ri8h.gitbook.io/crackproof-research/reference) . GitBook Assistant [NextOverview](https://xn--ri8h.gitbook.io/crackproof-research/windows/file-structure/file-format) Last updated 5 hours ago * [Conventions](https://xn--ri8h.gitbook.io/crackproof-research/windows#conventions) * [Contents](https://xn--ri8h.gitbook.io/crackproof-research/windows#contents) --- # PE reconstruction | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction.md) . Section recovery produces an RVA-oriented memory image. A usable PE file also needs coherent headers, file offsets, data directories, imports, TLS state, exports, relocations, and, for managed images, CLR structures. GitBook Assistant * [Headers, sections, and zero-fill ranges](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction/memory-image) GitBook Assistant * [Imports, TLS, and exports](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction/imports-tls-exports) GitBook Assistant * [Relocations, page transforms, and CLR data](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction/relocations-managed) GitBook Assistant These steps are layout-sensitive. In particular, old fixed-base executables, rebased DLLs, external-companion images, and CLR images cannot share one blanket directory policy. GitBook Assistant [PreviousStructural discovery and validation](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/loading/discovery-validation) [NextHeaders, sections, and zero-fill ranges](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction/memory-image) Last updated 14 hours ago --- # 概覽 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/runtime.md) . 運行時同時執行常規用戶態加載工作、環境檢查、可選內核支持與頁級代碼保護。 GitBook Assistant 範圍 詳細內容 啟動 GitBook Assistant [啟動順序、狀態值與調試日誌](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/startup-status) GitBook Assistant 環境 GitBook Assistant [用戶態與內核輔助檢查](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/environment-checks) GitBook Assistant 代碼頁 GitBook Assistant [按需頁變化與加載器代碼差異](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/page-protection) GitBook Assistant 嵌入組件 GitBook Assistant [手動映射輔助模塊](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/mapped-modules) GitBook Assistant 內核 GitBook Assistant [Htsysm 代際與職責](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/kernel-components) GitBook Assistant [上一頁重定位、頁變換與 CLR 數據](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/loading-and-pe-repair/pe-reconstruction/relocations-managed) [下一頁啟動序列與狀態報告](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/runtime/startup-status) 最後更新於 20 小時前 --- # Page protection and loader code | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/page-protection.md) . Page-level encryption[](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/page-protection#page-level-encryption) ------------------------------------------------------------------------------------------------------------------------------- The strongest runtime layer is optional and per-module. When enabled (`640` then `840`): GitBook Assistant 1. Executable sections are bulk-decrypted (status `640`). GitBook Assistant 2. They are then **re-encrypted page by page**, and every page is set to `PAGE_NOACCESS` (status `840`). GitBook Assistant 3. Execution that reaches a protected page faults; an exception handler decrypts the page on demand and resumes execution. GitBook Assistant The exception handling is installed by **patching** `**ntdll!KiUserExceptionDispatcher**` to jump into the protector's handler, which chains back to normal SEH when it is done. The kernel delivers every usermode exception to this single entry point, so the handler runs ahead of all SEH registrations — and is invisible to tools that walk the SEH chain looking for hooks. GitBook Assistant A consequence for memory analysis: a naive dump of a page-encrypted module captures only the pages touched since startup (the demand-decrypted working set); the rest is ciphertext or `PAGE_NOACCESS` filler. A complete image requires forcing every page to fault in first. Some builds additionally **scribble**: selected bytes of each decrypted page are XORed with random values once the page is resident, so a raw dump needs de-scribbling. The scribble is a per-build option and not always present — some page-encrypted modules dump cleanly once every page has been touched. GitBook Assistant The page-fault handler does not live inside the protected module's image. It ships in a manually mapped support module (`HtdpStub2.dll` — see [Htsysm kernel components](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/kernel-components) ), which is why handler signatures are absent when only the main module is dumped. GitBook Assistant The loader's own code: polymorphism and decoys[](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/page-protection#the-loaders-own-code-polymorphism-and-decoys) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The loader defends its code as aggressively as its data. Techniques observed in the final stage (stage 5) and its bootstrap: GitBook Assistant **Polymorphic emit.** The same algorithm appears as many permuted copies — one observed image carries 16 instances of one cipher prologue, differing only in cosmetic junk-jump placement. Disassemblers see 16 unrelated functions; the semantics are identical. GitBook Assistant **Anti-disassembly.** Junk bytes after unconditional jumps, jumps into the middle of multi-byte instructions, and return-address arithmetic (for example `call $+5` followed by add/sub of two constants whose difference is the distance to the real continuation, the modified return address then being discarded). Linear and even recursive-descent disassembly desynchronize; one 12.9 KB stage-5 blob decompiles almost entirely to "control flows out of bounds". GitBook Assistant **No-op decoy stubs.** The natural entry points are traps for the analyst's patience, not real code. One stub saves all 16 GPRs, performs the VMware backdoor probe, compares the result, and then executes `jne $+2` with a displacement of 0 — both branches reach the same instruction — restores every register, and returns. Its only side effect is the **timing** of the `in` instruction, consumed elsewhere. Another decoy hides its payload behind a trap flag: `pushfq; or [rsp], 0x100; popfq` raises `#DB`; under normal execution an SEH redirect skips the code after it, and only if a debugger (or naive emulator) swallows the exception and continues does the "hidden" path run — a path that goes nowhere useful. GitBook Assistant **Self-modifying metadata.** Stage tables are zeroed after use: markers present in the pre-load image are overwritten by the time the module finishes initializing, so a post-boot dump is missing structures the static file contains. GitBook Assistant Self-loading from disk[](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/page-protection#self-loading-from-disk) --------------------------------------------------------------------------------------------------------------------------------- The final stage does not do reflective in-memory loading. Its API string table contains `GetModuleFileNameW/A`, `CreateFileW`, `CreateFileMappingA`, `MapViewOfFile`, `UnmapViewOfFile`, `GetFileSize`, `GetFullPathNameW/A`, `CloseHandle`, `RtlGetVersion`, `SystemTimeToFileTime`, `Sleep` — file I/O and module-path APIs, with no allocation, protection, or loader APIs. The stage resolves its own on-disk path, maps the protected file as a memory view, and reads the encrypted payload from that view. (This is also why a static analysis can hand the same algorithm the raw file bytes and replay it offline.) GitBook Assistant Runtime state is held in a context structure addressed through a reserved register: function pointers at fixed slots, a doubly indirect pointer to the image buffer, and a per-slot table built by an unrolled `lea`\-and-store sequence. API addresses are read from the module's own OS-resolved import table — no PEB walk appears anywhere in the stage, so the module relies on the ordinary Windows loader having bound its imports, even though its stored `AddressOfEntryPoint` is junk and the OS never calls its real entry. GitBook Assistant The same stage contains its own `.reloc` walker: relocations are applied by the loader (status `655`), not the OS, consistent with the `/FIXED` handling in [PE transformations](https://xn--ri8h.gitbook.io/crackproof-research/windows/loading-and-pe-repair/pe-reconstruction) . GitBook Assistant [PreviousEnvironment and anti-analysis checks](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/environment-checks) [NextManually mapped helper modules](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/mapped-modules) Last updated 5 hours ago * [Page-level encryption](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/page-protection#page-level-encryption) * [The loader's own code: polymorphism and decoys](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/page-protection#the-loaders-own-code-polymorphism-and-decoys) * [Self-loading from disk](https://xn--ri8h.gitbook.io/crackproof-research/windows/runtime/page-protection#self-loading-from-disk) --- # LFSR, string, and page transforms | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/lfsr-strings-pages.md) . The LFSR keystream[](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/lfsr-strings-pages#the-lfsr-keystream) ------------------------------------------------------------------------------------------------------------------------------------ The per-build bytecode stubs (see below) are themselves wrapped in an LFSR keystream. The stream is data-independent — seed 1, feedback polynomial `0x8003`, eight bits emitted per byte, LSB first — so it can be replayed at any position, which is what makes trial-decoding candidate stub locations cheap: GitBook Assistant GitBook AssistantAskCopy def lfsr_keystream(n): out = bytearray(n) state = 1 for i in range(n): b = 0 for k in range(8): b |= (state & 1) << k state = (state << 1) & MASK32 if state & 0x8000: state ^= 0x8003 out[i] = b return out def lfsr_decrypt_block(d, pos): """XOR a bytecode stub with the keystream. The block length is stored unencrypted at pos+95.""" length = d[pos + 95] ks = lfsr_keystream(length) for i in range(length): d[pos + i] ^= ks[i] A stub block occupies a fixed 96-byte slot; the byte at `pos + 95` is the (unencrypted) length of the program inside. GitBook Assistant The import-name string cipher[](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/lfsr-strings-pages#the-import-name-string-cipher) ---------------------------------------------------------------------------------------------------------------------------------------------------------- DLL names and imported function names are encrypted with a rolling byte cipher: nibble swap, subtract the key, step the key by 67. The initial key is the low byte of the string's RVA — so a name cannot be decrypted without knowing where it lives. GitBook Assistant The `b == 0` remap avoids producing a NUL mid-string (which would truncate the walk): if the subtraction lands on zero, the byte is replaced by the two's complement of the key instead. GitBook Assistant The per-page code scramble[](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/lfsr-strings-pages#the-per-page-code-scramble) ---------------------------------------------------------------------------------------------------------------------------------------------------- Executable sections carry a sparse, page-granular scramble on top of everything else: one byte per 16-byte block is XORed, at an in-block offset that varies per block. The pattern skips block 0 (its key state still advances). 255 of each page's 4096 bytes are touched. GitBook Assistant The shift (64-bit: 0 or 15) and the formula choice (32-bit: `page+1` or `0x8000*(page+1)`) are **not recorded anywhere in the file**. Two builds can carry byte-identical configuration stamps yet require different choices. The only reliable discriminator is the code content itself: replay the scramble on sample pages under each candidate and count how many positions decode to `0xCC` (the MSVC `int3` padding byte). The correct choice restores padding disproportionately; a wrong one scrambles roughly one byte per 16. Some modules (native DLLs) have plaintext code and must not be descrambled at all. GitBook Assistant [PreviousRolling-key and rotation ciphers](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/rolling-and-rotation) [NextChecksums and key progression](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/checksums) Last updated 14 hours ago * [The LFSR keystream](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/lfsr-strings-pages#the-lfsr-keystream) * [The import-name string cipher](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/lfsr-strings-pages#the-import-name-string-cipher) * [The per-page code scramble](https://xn--ri8h.gitbook.io/crackproof-research/windows/data-transforms/lfsr-strings-pages#the-per-page-code-scramble) GitBook AssistantAskCopy def string_cipher(d, pos, key): """Decrypt a NUL-terminated string in place.""" i = 0 while d[pos + i] != 0: b = ror8(d[pos + i], 4) b = (b - key) & 0xFF if b == 0: b = (-key) & 0xFF d[pos + i] = b key = (key + 67) & 0xFF i += 1 GitBook AssistantAskCopy def page_scramble(d, va, size, key): """64-bit form. `key` is the absolute page index shifted left by a build-specific amount (0 or 15).""" for i in range(size >> 4): mixed = (ror32(key, 15) + i) & MASK32 key = (mixed + i) & MASK32 if i == 0: continue d[va + i * 16 + (mixed & 0xF)] ^= key & 0xFF def page_scramble_pe32(d, pa, page, big_formula): """32-bit form. The page key is (page+1) or 0x8000*(page+1).""" key = (0x8000 * (page + 1)) & MASK32 if big_formula else page + 1 key = ror32(key, 15) for bi in range(1, 256): rk = ror32(key, 15) ri = (rk + bi) & MASK32 key = (ri + bi) & MASK32 d[pa + bi * 16 + (ri & 0xF)] ^= key & 0xFF --- # 页保护与加载器代码 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/page-protection.md) . 页级加密[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/page-protection#ye-ji-jia-mi) ----------------------------------------------------------------------------------------------------------- 最强的运行时层是可选的、按模块配置的。启用时（`640` 然后 `840`）： GitBook Assistant 1. 可执行节被批量解密（状态 `640`）。 GitBook Assistant 2. 随后**逐页重新加密**，每页置为 `PAGE_NOACCESS`（状态 `840`）。 GitBook Assistant 3. 执行到达受保护页时出错；异常处理器按需解密该页并恢复执行。 GitBook Assistant 异常处理的安装方式是**补丁** `**ntdll!KiUserExceptionDispatcher**`，使其跳入保护器的处理器，处理完再链回正常 SEH。内核把每个用户态异常都递交给这唯一入口点，因此该处理器先于一切 SEH 注册运行——并且对遍历 SEH 链寻找钩子的工具不可见。 GitBook Assistant 对内存分析的一个推论：对页加密模块的朴素转储只能捕获自启动以来被触及的页（按需解密的工作集）；其余是密文或 `PAGE_NOACCESS` 填充。完整映像需要先强制每页缺页。某些构建还会**涂写**：已解密页驻留后，其选定字节被随机值 XOR 一次，因此原始转储需要反涂写。涂写是按构建的选项，并不总存在——有些页加密模块在每页都被触及后能干净转出。 GitBook Assistant 页错误处理器不在受保护模块的映像内。它随一个手动映射的支持模块（`HtdpStub2.dll`——见 [Htsysm 内核组件](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/kernel-components) ）分发，因此只转储主模块时找不到处理器签名。 GitBook Assistant 加载器自身的代码：多态与诱饵[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/page-protection#jia-zai-qi-zi-shen-de-dai-ma-duo-tai-yu-you-er) ------------------------------------------------------------------------------------------------------------------------------------------------------- 加载器保卫其代码的力度不亚于其数据。在最终阶段（stage 5）及其自举代码中观察到的技术： GitBook Assistant **多态发射。** 同一算法以许多置换副本出现——一个已观察映像携带同一密码序言的 16 个实例，仅在装饰性垃圾跳转的摆放上不同。反汇编器看到 16 个互不相干的函数；语义完全相同。 GitBook Assistant **反反汇编。** 无条件跳转后的垃圾字节、跳进多字节指令中间的跳转，以及返回地址算术（例如 `call $+5` 后随两个常量的加/减，其差恰是到真实续点的距离，被修改的返回地址随即被丢弃）。线性扫描乃至递归下降反汇编都会失步；一个 12.9 KB 的 stage-5 blob 几乎整体反编译为 “control flows out of bounds”。 GitBook Assistant **无操作诱饵 stub。** 自然的入口点是消耗分析者耐心的陷阱，而非真实代码。一个 stub 保存全部 16 个 GPR，执行 VMware 后门探测，比较结果，然后执行位移为 0 的 `jne $+2`——两个分支到达同一条指令——恢复每个寄存器并返回。它唯一的副作用是 `in` 指令的**计时**，在别处被消费。另一个诱饵把载荷藏在陷阱标志后：`pushfq; or [rsp], 0x100; popfq` 触发 `#DB`；正常执行下 SEH 重定向跳过其后的代码，只有当调试器（或朴素模拟器）吞下异常并继续时，“隐藏”路径才会运行——而那是一条没有用的路。 GitBook Assistant **自修改元数据。** 阶段表用后即清零：预载映像中存在的标记在模块完成初始化时已被覆写，因此启动后的转储会缺静态文件中存在的结构。 GitBook Assistant 从磁盘自我加载[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/page-protection#cong-ci-pan-zi-wo-jia-zai) --------------------------------------------------------------------------------------------------------------------------- 最终阶段不做反射式内存加载。其 API 字符串表包含 `GetModuleFileNameW/A`、`CreateFileW`、`CreateFileMappingA`、`MapViewOfFile`、`UnmapViewOfFile`、`GetFileSize`、`GetFullPathNameW/A`、`CloseHandle`、`RtlGetVersion`、`SystemTimeToFileTime`、`Sleep`——文件 I/O 与模块路径 API，没有任何分配、保护或加载器 API。该阶段解析自身的磁盘路径，把受保护文件映射为内存视图，并从该视图读取加密 payload。（这也是静态分析能把同样的算法喂以原始文件字节、离线重放的原因。） GitBook Assistant 运行时状态保存在一个由保留寄存器寻址的上下文结构中：固定槽位的函数指针、指向映像缓冲区的双重间接指针，以及由展开的 `lea`\-加-store 序列构建的逐槽表。API 地址从模块自身经 OS 解析的导入表读出——整个阶段中没有任何 PEB 遍历，因此该模块依赖普通 Windows 加载器已绑定其导入，尽管它存储的 `AddressOfEntryPoint` 是垃圾、OS 从不调用其真实入口。 GitBook Assistant 同一阶段内含自己的 `.reloc` 遍历器：重定位由加载器施加（状态 `655`），而非 OS——与 [PE 变换](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction) 中的 `/FIXED` 处理一致。 GitBook Assistant [上一页环境与反分析检查](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/environment-checks) [下一页手动映射辅助模块](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/mapped-modules) 最后更新于 15小时前 * [页级加密](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/page-protection#ye-ji-jia-mi) * [加载器自身的代码：多态与诱饵](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/page-protection#jia-zai-qi-zi-shen-de-dai-ma-duo-tai-yu-you-er) * [从磁盘自我加载](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/page-protection#cong-ci-pan-zi-wo-jia-zai) --- # LFSR、字符串與頁變換 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/lfsr-strings-pages.md) . LFSR 密鑰流[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/lfsr-strings-pages#lfsr-mi-yue-liu) ----------------------------------------------------------------------------------------------------------------------------- 按構建定製的字節碼 stub（見下文）本身還包著一層 LFSR 密鑰流。該流與數據無關——種子 1、反饋多項式 `0x8003`、每字節吐 8 位、LSB 優先——因此可在任意位置重放，這使得對候選 stub 位置做試解碼代價很低： GitBook Assistant GitBook Assistant詢問複製 def lfsr_keystream(n): out = bytearray(n) state = 1 for i in range(n): b = 0 for k in range(8): b |= (state & 1) << k state = (state << 1) & MASK32 if state & 0x8000: state ^= 0x8003 out[i] = b return out def lfsr_decrypt_block(d, pos): """XOR a bytecode stub with the keystream. The block length is stored unencrypted at pos+95.""" length = d[pos + 95] ks = lfsr_keystream(length) for i in range(length): d[pos + i] ^= ks[i] 一個 stub 塊佔固定的 96 字節槽；`pos + 95` 處的字節是內部程序的（未加密）長度。 GitBook Assistant 導入名字符串密碼[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/lfsr-strings-pages#dao-ru-ming-zi-fu-chuan-mi-ma) ------------------------------------------------------------------------------------------------------------------------------------------- DLL 名與導入函數名用一個滾動字節密碼加密：半字節交換、減密鑰、密鑰步進 67。初始密鑰是字符串 RVA 的低字節——不知道名字的位置就無法解密它。 GitBook Assistant `b == 0` 的重映射避免在字符串中間產生 NUL（那會截斷遍歷）：若減法結果為零，該字節改為取密鑰的二進制補碼。 GitBook Assistant 頁級代碼擾動[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/lfsr-strings-pages#ye-ji-dai-ma-rao-dong) --------------------------------------------------------------------------------------------------------------------------------- 可執行節在一切之上還帶一層稀疏的頁粒度擾動：每 16 字節塊 XOR 一個字節，塊內偏移隨塊變化。模式跳過塊 0（但其密鑰狀態仍推進）。每頁 4096 字節中有 255 個被觸及。 GitBook Assistant 移位量（64 位：0 或 15）與公式選擇（32 位：`page+1` 或 `0x8000*(page+1)`）**不記錄在文件的任何字段裡**。兩個構建可以攜帶逐字節相同的配置戳卻需要不同選擇。唯一可靠的判別依據是代碼內容本身：在每個候選下對採樣頁重放擾動，統計有多少位置解碼為 `0xCC`（MSVC 的 `int3` 填充字節）。正確選擇會不成比例地還原填充；錯誤選擇則每 16 字節約攪亂 1 字節。某些模塊（原生 DLL）代碼是明文，絕不能做反擾動。 GitBook Assistant [上一頁滾動密鑰與旋轉密碼](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/rolling-and-rotation) [下一頁校驗和與密鑰推進](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/checksums) 最後更新於 20 小時前 * [LFSR 密鑰流](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/lfsr-strings-pages#lfsr-mi-yue-liu) * [導入名字符串密碼](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/lfsr-strings-pages#dao-ru-ming-zi-fu-chuan-mi-ma) * [頁級代碼擾動](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-tw/data-transforms/lfsr-strings-pages#ye-ji-dai-ma-rao-dong) GitBook Assistant詢問複製 def string_cipher(d, pos, key): """Decrypt a NUL-terminated string in place.""" i = 0 while d[pos + i] != 0: b = ror8(d[pos + i], 4) b = (b - key) & 0xFF if b == 0: b = (-key) & 0xFF d[pos + i] = b key = (key + 67) & 0xFF i += 1 GitBook Assistant詢問複製 def page_scramble(d, va, size, key): """64-bit form. `key` is the absolute page index shifted left by a build-specific amount (0 or 15).""" for i in range(size >> 4): mixed = (ror32(key, 15) + i) & MASK32 key = (mixed + i) & MASK32 if i == 0: continue d[va + i * 16 + (mixed & 0xF)] ^= key & 0xFF def page_scramble_pe32(d, pa, page, big_formula): """32-bit form. The page key is (page+1) or 0x8000*(page+1).""" key = (0x8000 * (page + 1)) & MASK32 if big_formula else page + 1 key = ror32(key, 15) for bi in range(1, 256): rk = ror32(key, 15) ri = (rk + bi) & MASK32 key = (ri + bi) & MASK32 d[pa + bi * 16 + (ri & 0xF)] ^= key & 0xFF --- # aes_impl.py | Reference | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/aes_impl.py.md) . 分组密码：AES-CBC 解密，密钥调度嵌入数据缓冲区，见 [AES 变换](https://app.gitbook.com/s/fEb9nKPvKsjkPAHMUbOt/shu-ju-bian-huan/aes) 。 GitBook Assistant GitBook Assistant询问复制 """The block cipher: AES decryption in CBC mode with an in-buffer key schedule. The loader embeds the expanded key schedule inside the same buffer as the ciphertext: a small header at `key_offset` (the round count as a little-endian u16 at key_offset+2) followed by (rounds+1) 16-byte round keys. Decryption runs in 16-byte blocks; each block is XORed with the previous ciphertext block (CBC chaining, zero IV). The five lookup tables are the standard AES *decryption* T-tables (InvSubBytes fused with InvMixColumns), generated below from GF(2^8) arithmetic - they are public AES constants, not proprietary data. """ MASK32 = 0xFFFFFFFF def get_u16(d, off): return d[off] | (d[off + 1] << 8) def get_u32(d, off): return d[off] | (d[off + 1] << 8) | (d[off + 2] << 16) | (d[off + 3] << 24) # --- table generation ------------------------------------------------------- def _gf_mul(a, b): """Multiply in GF(2^8) with the AES reduction polynomial.""" p = 0 for _ in range(8): if b & 1: p ^= a hi = a & 0x80 a = (a << 1) & 0xFF if hi: a ^= 0x1B b >>= 1 return p def _inverse_sbox(): inv = [0] * 256 for a in range(1, 256): for b in range(1, 256): if _gf_mul(a, b) == 1: inv[a] = b break fwd = [0] * 256 for i in range(256): x = s = inv[i] for _ in range(4): s = ((s << 1) | (s >> 7)) & 0xFF x ^= s fwd[i] = x ^ 0x63 isb = [0] * 256 for i in range(256): isb[fwd[i]] = i return isb def _build_tables(): """Each table has 256 u32 entries. SBOX broadcasts invsbox(x) to all four lanes; COLUMMIX1 holds [0x0b*s, 0x0d*s, 0x09*s, 0x0e*s] and COLUMMIX2/3/4 are its one-, two- and three-byte rotations.""" isb = _inverse_sbox() sbox = bytearray(1024) cm = [bytearray(1024) for _ in range(4)] for x in range(256): s = isb[x] lanes = [_gf_mul(0x0B, s), _gf_mul(0x0D, s), _gf_mul(0x09, s), _gf_mul(0x0E, s)] for j in range(4): sbox[x * 4 + j] = s for t in range(4): cm[t][x * 4 + j] = lanes[(j + t) % 4] return sbox, cm _SBOX, _CM = _build_tables() # --- decryption ------------------------------------------------------------- def _aes_round(d, pos, key_offset, rounds): """Decrypt one 16-byte block in place. The state words are loaded and stored big-endian; the round keys are read from the same buffer.""" n = [int.from_bytes(d[pos + 4 * i:pos + 4 * i + 4], "big")\ ^ get_u32(d, key_offset + 4 * i) for i in range(4)] # Middle rounds: InvSubBytes + InvShiftRows + InvMixColumns, fused into # four T-table lookups per state word, plus the round key. for r in range(1, rounds): off = key_offset + r * 16 n = [\ get_u32(_CM[1], ((n[3] >> 16) & 0xFF) * 4) ^ get_u32(_CM[2], ((n[2] >> 8) & 0xFF) * 4)\ ^ get_u32(_CM[0], (n[0] >> 24) * 4) ^ get_u32(_CM[3], (n[1] & 0xFF) * 4) ^ get_u32(d, off),\ get_u32(_CM[1], ((n[0] >> 16) & 0xFF) * 4) ^ get_u32(_CM[0], (n[1] >> 24) * 4)\ ^ get_u32(_CM[2], ((n[3] >> 8) & 0xFF) * 4) ^ get_u32(_CM[3], (n[2] & 0xFF) * 4) ^ get_u32(d, off + 4),\ get_u32(_CM[1], ((n[1] >> 16) & 0xFF) * 4) ^ get_u32(_CM[2], ((n[0] >> 8) & 0xFF) * 4)\ ^ get_u32(_CM[0], (n[2] >> 24) * 4) ^ get_u32(_CM[3], (n[3] & 0xFF) * 4) ^ get_u32(d, off + 8),\ get_u32(_CM[2], ((n[1] >> 8) & 0xFF) * 4) ^ get_u32(_CM[1], ((n[2] >> 16) & 0xFF) * 4)\ ^ get_u32(_CM[0], (n[3] >> 24) * 4) ^ get_u32(_CM[3], (n[0] & 0xFF) * 4) ^ get_u32(d, off + 12),\ ] # Final round: S-box substitution with the ShiftRows lane permutation. s = [\ (get_u32(_SBOX, (n[0] >> 24) * 4) & 0xFF000000) | (get_u32(_SBOX, ((n[3] >> 16) & 0xFF) * 4) & 0x00FF0000)\ | (get_u32(_SBOX, ((n[2] >> 8) & 0xFF) * 4) & 0x0000FF00) | (get_u32(_SBOX, (n[1] & 0xFF) * 4) & 0x000000FF),\ (get_u32(_SBOX, (n[1] >> 24) * 4) & 0xFF000000) | (get_u32(_SBOX, ((n[0] >> 16) & 0xFF) * 4) & 0x00FF0000)\ | (get_u32(_SBOX, ((n[3] >> 8) & 0xFF) * 4) & 0x0000FF00) | (get_u32(_SBOX, (n[2] & 0xFF) * 4) & 0x000000FF),\ (get_u32(_SBOX, (n[2] >> 24) * 4) & 0xFF000000) | (get_u32(_SBOX, ((n[1] >> 16) & 0xFF) * 4) & 0x00FF0000)\ | (get_u32(_SBOX, ((n[0] >> 8) & 0xFF) * 4) & 0x0000FF00) | (get_u32(_SBOX, (n[3] & 0xFF) * 4) & 0x000000FF),\ (get_u32(_SBOX, (n[3] >> 24) * 4) & 0xFF000000) | (get_u32(_SBOX, ((n[2] >> 16) & 0xFF) * 4) & 0x00FF0000)\ | (get_u32(_SBOX, ((n[1] >> 8) & 0xFF) * 4) & 0x0000FF00) | (get_u32(_SBOX, (n[0] & 0xFF) * 4) & 0x000000FF),\ ] last = key_offset + rounds * 16 for i in range(4): d[pos + 4 * i:pos + 4 * i + 4] = (s[i] ^ get_u32(d, last + 4 * i)).to_bytes(4, "big") def aes_decrypt(d, pos, size, key_offset): """CBC decryption over `size` bytes at `pos`; the schedule lives in the same buffer at `key_offset` (round count at key_offset+2).""" rounds = get_u16(d, key_offset + 2) prev = bytes(16) for i in range(size >> 4): p = pos + i * 16 cur = bytes(d[p:p + 16]) _aes_round(d, p, key_offset + 4, rounds) for j in range(16): d[p + j] ^= prev[j] prev = cur [上一页primitives.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/primitives.py) [下一页huffman.py](https://xn--ri8h.gitbook.io/crackproof-research/reference/zh-cn/huffman.py) 最后更新于 1天前 --- # 节数据与伴生文件 | Windows | CrackProof Research For the complete documentation index, see [llms.txt](https://xn--ri8h.gitbook.io/crackproof-research/llms.txt) . This page is also available as [Markdown](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/file-structure/companion-layout.md) . 在文件中定位节数据[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/file-structure/companion-layout#zai-wen-jian-zhong-ding-wei-jie-shu-ju) -------------------------------------------------------------------------------------------------------------------------------------------------- 加载器表内的节内容描述符存储的偏移，相对于一个本身以补码编码在文件偏移 `0x1080` 处的基址： GitBook Assistant GitBook Assistant询问复制 section_data_file_base = (~u32@0x1080) + 0x1000 (32-bit wrapping) 因此描述符的 `src` 字段映射到文件偏移 `src + section_data_file_base`。同一公式出现在所有构建家族中（在加载器代码里既称 `rebase` 又称 `compress_data_offset`）。 GitBook Assistant 外置伴生体布局（`._` 文件）[](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/file-structure/companion-layout#wai-zhi-ban-sheng-ti-bu-ju-.-wen-jian) -------------------------------------------------------------------------------------------------------------------------------------------------------- 某些构建——目前仅在 il2cpp 作品上观察到——把受保护模块拆成一对文件： GitBook Assistant * `**Foo.dll**`——磁盘上的瘦**加载器 stub**。其代码节被裁剪到只剩一页（即 CrackProof 加载器本体），但其头部与 `.rdata` 是完整明文。 GitBook Assistant * `**Foo.dll._**`——全加密的**伴生体**，持有真正的 payload。它不含任何明文 PE 结构（熵 ≈ 8 比特/字节）。 GitBook Assistant 伴生体逐字节等于 stub 自 CrackProof 头部（偏移 4096）起的 payload 区。运行时加载器映射 `Foo.dll._` 并对其执行常规解包；实际运行的模块实际上就是拼接体 `stub[..4096] ++ companion`。 GitBook Assistant 配对关系由 32 字节精确匹配确认：`stub[4096..4128] == companion[0..32]`。这 32 字节覆盖加密 info 头（密钥表与 magic），因此匹配即证明该伴生体就是此 stub 的 payload，而非无关文件。 GitBook Assistant stub 以明文保留的内容对后续重建很重要： GitBook Assistant * **导出目录**（伴生体在此处解密为密文；加载器运行时从 stub 的副本重建导出）。 GitBook Assistant * **TLS 目录**——`IMAGE_TLS_DIRECTORY` 结构体、其原始数据模板与数据目录项，这些都被保护层从加密 payload 中剥离（见 [PE 变换](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction) ）。 GitBook Assistant * 真实的 `DllCharacteristics` 字段与基址重定位表——伴生模块**不是** `/FIXED`，与较旧的单文件构建不同。 GitBook Assistant 关于此文件对在启动时如何加载，见[运行时行为](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/runtime/runtime) ；关于缺失部分如何被还原进重建映像，见 [PE 变换](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/loading-and-pe-repair/pe-reconstruction) 。 GitBook Assistant [上一页识别与构建家族](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/file-structure/recognition) [下一页概览](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/data-transforms/data-transforms) 最后更新于 15小时前 * [在文件中定位节数据](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/file-structure/companion-layout#zai-wen-jian-zhong-ding-wei-jie-shu-ju) * [外置伴生体布局（.\_ 文件）](https://xn--ri8h.gitbook.io/crackproof-research/windows/zh-cn/file-structure/companion-layout#wai-zhi-ban-sheng-ti-bu-ju-.-wen-jian) ---