ReArk is a desktop reverse engineering workbench that disassembles and decompiles HarmonyOS .hap and .abc, Android, and iOS packages, pairing static analysis with an AI agent for authorized security research.
| Tool | lkimuk/ReArk — AI-assisted desktop reverse engineering workbench for HarmonyOS NEXT, Android, iOS, and native binaries |
| Category | Reverse engineering and binary analysis platform |
| Primary Use | Disassembling and decompiling .hap/.abc, .apk/.aab, and .ipa packages plus PE/ELF/Mach-O binaries during authorized audits and malware triage |
| Safe Use | The README states ReArk is only for legally authorized reverse engineering, interoperability research, malware analysis, and security research |
| Telemetry Note | Desktop analysis is largely local; the Agent can call remote model providers, so analysts should watch outbound LLM API traffic and avoid sending secrets to remote endpoints |
Most reverse engineering workbenches treat mobile platforms as an afterthought, and almost none of them understand HarmonyOS NEXT at all. ReArk, an open-source C++ desktop tool from lkimuk, fills that gap: it opens HarmonyOS .hap, .app, and .abc files, Android .apk and .aab packages, and iOS .ipa archives in a single workspace, and it also accepts standalone Windows PE, ELF, and Mach-O binaries for native analysis. What makes it notable is not just format coverage but the integration of an AI agent — ReArk Agent — that can pull evidence from the loaded package on demand. For teams facing their first HarmonyOS NEXT assessment, this is one of the few purpose-built options.
The static analysis core is where the engineering effort shows. For HarmonyOS packages, ReArk disassembles and decompiles ArkCompiler Bytecode (.abc), letting you walk strings, literals, cross-references, and call argument flows — the same breadcrumb trail you would follow in JD-GUI or jadx for Java, but for ArkTS. Android packages get manifest inspection covering permissions, components, and entry points, plus disassembly and Java-like decompiled output. iOS archives surface signature and certificate-chain views. A generic viewer handles hex, formatted JSON, XML, images, and media resources with file search across the source output.
Native binary analysis is treated as a first-class workflow rather than a bolt-on. You can open .exe and .dll PE files, ELF executables, and Mach-O libraries directly, browsing headers, sections, imports, exports, relocations, and dependencies. More useful for hardening reviews, ReArk enumerates security mitigations including ASLR, DEP/NX, PIE, RELRO, stack canaries, and CFG. Structure-aware listings and annotated hex views give field-level decoding, which is the level of detail that separates a serious disassembler frontend from a hex editor with ambitions.
The ReArk Agent is the feature that defines the tool's identity. Instead of copying decompiled code into a chat window, the agent operates contextually against the currently loaded HarmonyOS or Android package: you ask questions, and it discovers analysis capabilities and retrieves package files, metadata, strings, disassembly, and decompiled output as needed. You can attach reference documents to supplement package evidence with your own materials. Supported model providers include OpenAI-compatible endpoints and local Ollama models, and version 1.2.0 adds llama-server support — meaning the whole loop can run air-gapped on local models, which matters when the sample under analysis is suspicious.
Agent safety deserves explicit attention, and the README handles it better than most. Host commands, Python execution, and device operations go through applicable approval flows, so the agent cannot silently pivot from analysis to execution. The privacy guidance is blunt and correct: when using remote model providers, avoid submitting secrets, certificates, user data, or trade secrets. That is a real operational concern — a decompiled enterprise app can contain hardcoded API keys, and piping that output to a third-party LLM endpoint is a data-leak incident waiting to happen. Running local models through Ollama or llama-server neutralizes the risk entirely.
Device integration rounds out the dynamic side. ReArk discovers HarmonyOS devices via HDC and Android devices via ADB, and can install and launch applications, capture screenshots, inspect UI nodes, and read device logs. Screen mirroring is real-time with mouse and keyboard control, plus screen recording, audio, and clipboard access where the device supports it, in fullscreen or detached windows. This collapses the usual shuffle between scrcpy, hdc, log viewers, and the analysis workbench into one environment — genuinely useful for authorized device-lab workflows and CTF work.
Version 1.2.0 pushed the tool firmly into dynamic analysis territory. It adds Frida-based instrumentation, CPU emulation, memory dumping, and dynamic debugging — the standard dynamic toolkit, now wired into the same workspace as the decompiler. On the Android side, bounded APK modification, repackaging, alignment, signing, and signature verification are supported, alongside HarmonyOS signing-material configuration, re-signing, and repackaging. A Reproduction Mode flags application cracking and tampering risks, which reads as a defensive feature for developers validating their own anti-tamper posture. MCP Server integration lets external tools such as REA plug into the agent loop.
That repackaging capability sits closest to the policy edge of what the tool does, and it is worth being precise about the authorized framing. Re-signing and repackaging have legitimate purposes — interoperability research, malware unpacking, patched-sample analysis in a lab — and Reproduction Mode exists specifically to detect tampering, not facilitate it. The README's own safety section is explicit that use is restricted to legally authorized reverse engineering, interoperability research, malware analysis, and security research. Anyone running this against third-party applications without permission is outside both the license's spirit and, in most jurisdictions, the law.
HarmonyOS signing inspection ties the package story together: you can verify signature validity, examine certificates, and confirm whether an app's provenance holds up — directly relevant to malware triage on a platform where fake-signature distribution is already a documented abuse pattern. The 1.2.0 release notes also mention improved Android embedded ELF analysis and agent access to native artifacts, acknowledging that modern apps hide logic in bundled native libraries, not just managed bytecode.
Installation is conventional for a desktop application: download the Windows 10+ x64 setup exe or the macOS 14.0+ Apple Silicon dmg from the GitHub releases page; a Linux x64 build is promised in the next release. There is no package-manager dance, and the documentation lives at cppmore.com/ReArk alongside GitHub Issues for support. The repository carries an Apache-2.0 license with third-party notices in THIRD_PARTY_NOTICES.md, and it has accumulated over 800 stars — healthy traction for a tool serving a platform ecosystem this young.
Where does ReArk fit in a professional workflow? For mobile application security assessments on HarmonyOS NEXT — a platform where jadx and IDA alone leave you stranded — it is arguably the only integrated option, and its Android and native coverage makes it viable as a single workbench for mixed-platform engagements. The AI agent accelerates triage on large packages, but the approval flows and local-model options show the author understood the trust implications. Watch the maturity curve: Linux support is still pending, and the feature list is growing fast enough that version-to-version behavior changes are likely. For authorized assessors, malware analysts, and CTF players, this is a repository worth bookmarking.
lkimuk/ReArk.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.