# ReArk 1.0.0 opens HarmonyOS and Android packages, but its Linux row is still empty

> ReArk reads HarmonyOS HAP, APP and ABC files plus Android APK and AAB packages, drives connected devices through HDC and ADB, and hands part of the analysis to a model agent. The 1.0.0 release published a Windows installer and an Apple Silicon dmg, and several parts of the documentation stop before the part you would need.

**lkimuk/ReArk** — An intelligent reverse engineering analysis tool designed for multiple target platforms, currently supporting HarmonyOS (HAP/APP/ABC) and Android (APK/AAB).

- Repository: https://github.com/lkimuk/ReArk
- Stars: 455 · Forks: 73
- Language: C++
- License: Apache-2.0
- Published: 2026-09-20 · Updated: 2026-09-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/lkimuk-reark

## The Linux row of the platform table still reads coming in the next release

Version 1.0.0 was tagged on 2026-09-07, and the platform table under the installation heading still has a hole in it. Windows gets a real row: Windows 10+, x64, with a direct link to ReArk-1.0.0-windows-x64-setup.exe. macOS gets macOS 14.0+ and Apple Silicon, with ReArk-1.0.0-macos-arm64.dmg. The Linux row names x64 as the architecture, then puts the words System requirements to be announced in the requirements cell and Coming in the next release where the link should be. No Linux artifact exists for a release numbered 1.0.0.

The repository root does not look like a project waiting for a build host. CMakeLists.txt, a cmake/ directory, installer/, and app_icon.rc.in are all present, and the primary language is C++. app_icon.rc.in is a Windows resource template, so part of the packaging already assumes Windows tooling. What is missing is a published binary and a stated dependency list for the one platform the table has not filled in.

The macOS gap is narrower than the table makes it look. The single dmg is arm64, and the row names Apple Silicon explicitly, so an Intel Mac has no download on the versioned link or on the latest release page. Installation is a manual download in every case. There is no package manager entry, no checksum column, and nothing that tells you how to confirm the exe or dmg you downloaded is the one the project published.

## The direct download links stay pinned to v1.0.0 filenames

Both platform links embed the version in the path: one ends in /releases/download/v1.0.0/ReArk-1.0.0-windows-x64-setup.exe and the other in /v1.0.0/ReArk-1.0.0-macos-arm64.dmg. The two general pointers beside them, Latest release and All releases, do follow new tags. So the moment a 1.0.1 appears, that table keeps serving 1.0.0 binaries to anyone who clicks the platform row instead of the generic link.

Release history is short and uneven: v0.2.0 on 2026-07-07, v0.3.0 on 2026-07-16, v1.0.0 on 2026-09-07. Nine days between the first two tags, then seven weeks to the 1.0 tag. The release titles change shape at the same point, from ReArk version 0.3.0 to ReArk v1.0.0, which suggests the naming settled when the version jumped rather than at the start.

Two files at the root can carry the version string, VERSION and CMakeLists.txt. Neither is mentioned in the installation section, so anyone building from source has no way to tell which one the shipped installers were cut from, or what happens if the two disagree.

## The screenshot gallery is six empty anchors and the star widget link is malformed

The screenshot section is two tables holding six images, and every cell is an anchor with no text and no alt attribute. They point at assets/screenshots/harmony-decompilation.png, android-decompilation.png, abc-hex.png, abc-strings.png, agent-analysis.png, and android-mirroring.png. Rendered as written, the gallery is a grid of empty cells, so the decompilation views, the hex inspector, and the mirroring feature show nothing at all.

The Star History block has a smaller version of the same problem. Its link reads https://star-history.com/#lkimuk/ReArk&Date, which puts Date after the hash, so it lands in the fragment instead of reaching the widget as a parameter.

Documentation is split in a way worth knowing before you rely on it. The support section sends readers to a user guide hosted on cppmore.com, outside the project domain and not versioned with the code. Meanwhile the root already carries docs/ and plugin/ directories, and neither is linked or explained anywhere in the README. If you are looking for the plugin interface, this repository does not describe it. The language switch at the top is the one part that works as advertised, pairing the English text with README.zh-CN.md.

## ReArk Agent runs Python on the host, and the approval flows behind it are undefined

ReArk Agent is where the exposure sits. It answers contextual questions about the package currently open, it discovers analysis capabilities and retrieves package files, metadata, strings, disassembly, and decompiled output as needed, it accepts reference documents you attach, and it uses supported model providers, including OpenAI-compatible endpoints and local Ollama models.

The device line is the one to read twice: host commands, Python execution, and device operations use the applicable approval flows. Which flows those are, where they are configured, whether an approval can be pinned for a session, and whether they can be switched off, none of it appears in the documentation. The provider list is open ended by its own wording, and no config file path, endpoint field, model name, or default is given for any of them.

The privacy note is narrower than the feature list. It tells you to avoid submitting secrets, certificates, user data, or trade secrets when the agent talks to a remote provider. It says nothing about what a local Ollama model receives, what happens to attached reference documents, or what the tool retains after a session ends. An agent that executes Python on your machine and reads the artifact without waiting for you to select anything deserves settings you have read before it is allowed near a device.

## HarmonyOS re-signing documents no key handling, and the Android path stops at the APK

Signing and packaging is a HarmonyOS feature set, and its documentation stops before the interesting part. The three capabilities are inspecting signatures, certificates, and signing validity; configuring signing materials, re-signing, and repackaging HarmonyOS applications; and installing supported application packages on connected devices. No key format is named, no keystore tool is named, nothing says whether an existing signature survives a repackage, and no error behaviour is given for a profile that does not match.

The scope statement is explicit that ABC evidence tools and HarmonyOS re-signing are specific to HarmonyOS packages, and that is where the Android boundary shows up as well. Android analysis covers manifests, permissions, components, entry points, resources, and icons, and it reads disassembly plus Java-like decompiled output. Installation is narrower: Android device installation uses APK files. Opening an .aab gets you analysis, while the install step still wants an APK.

Repackaging an application changes what that file claims to be and who signed it, so the checks that matter before you touch a package are ownership and authorization rather than buttons. The project states its own scope as legally authorized reverse engineering, interoperability research, malware analysis, and security research. Hold the keys and the permission before repackaging anything you did not build.

## samples/ ships third-party packages and a .rar archive inside a C++ tree

The samples directory ships eight files inside the source tree: Bridge.hap, EasyHap-default-unsigned.app, contacts.hap, fpt-default-signed.app, shctf.app, shctf.zip, 倩倩手机逆向包.rar, and 遥遥领先.hap. Two names encode signing state outright, one unsigned .app and one signed, which is convenient for the repackaging workflow and says nothing about whose certificate the signed sample carries. Two more are named shctf, matching the mention of working through CTF challenges in the overview, and one is a zip of the same name.

One file is a .rar archive, and three names are not ASCII, in a repository whose build is CMake based and whose only published artifacts are a Windows exe and an Apple Silicon dmg. Nothing in the documentation says whether an archive in that directory is unpacked by a build step or by hand, and no fixture path is given for any of the samples. If you script against samples/, the non-ASCII names and the case sensitivity of your filesystem are the first two things to test.

Provenance is unstated for every one of these packages. They are third-party applications redistributed inside the repository, so check the rights before shipping anything derived from them.

## Device control reaches the clipboard, the audio, and a live screen mirror

Connected device support is the broadest part of the product and the least bounded. HarmonyOS devices are discovered through HDC and Android devices through ADB. From there the tool installs and launches applications, captures screenshots, inspects UI nodes, reads device logs, mirrors the screen in real time, and takes mouse and keyboard control, with screen recording, audio, and clipboard access where the device supports it. Mirroring windows can be fullscreen or detached.

Two qualifiers decide what you get in practice. Available analysis views and device actions depend on the package format, the operating system version, and device capabilities. Read the feature list as a ceiling rather than a contract: ABC evidence tools and HarmonyOS re-signing simply do not exist for an APK, and the clipboard and recording actions depend on the device and the runtime, not on your install.

That combination is the thing to plan around. A live mirror, mouse and keyboard control, device logs, and an agent permitted to run host commands form one remote control path into a handset that may hold real accounts and real messages. Use hardware you can wipe, keep mirroring off while you learn the approval settings, and treat the device logs you collect as data you will have to handle later.

## Conclusion

ReArk is a reasonable pick for HarmonyOS package work, because the ABC evidence tools and the signing and repackaging path are built for those formats rather than added as an afterthought. Its Android side reads a package well and stops there, since the install step takes an APK even when you opened an AAB. Before committing, confirm four things: that a build exists for your platform and CPU, what the agent approval flows actually permit, how signing material is handled, and whether the Linux row or an Intel Mac build is part of the plan. On a phone you care about, leave mirroring and host command execution switched off until you have read those settings yourself.

## FAQ

### Does ReArk have a Linux build?

Not for version 1.0.0. The platform table names Linux x64, but its requirements cell reads System requirements to be announced and its link cell reads Coming in the next release, so no Linux artifact was published.

### Can ReArk install an AAB package onto an Android device?

No. Android device installation uses APK files. An .aab package can be opened for static analysis, but the install step takes an APK.

### Which model providers does ReArk Agent support?

The project names OpenAI-compatible endpoints and local Ollama models, using the word including, and gives no config file path, endpoint field, or default model for any of them.

### Can ReArk re-sign an Android APK?

No. ABC evidence tools and HarmonyOS re-signing are specific to HarmonyOS packages, so configuring signing materials and repackaging applies to .hap and .app targets rather than to Android packages.

### How is ReArk licensed and what does the repository carry besides the source?

It is licensed under the Apache License 2.0, with a LICENSE file and a THIRD_PARTY_NOTICES.md alongside a third_party/ directory. The root also holds VERSION, installer/, docs/, plugin/, and a samples/ directory of third-party packages.

## Sources

- [Issues](https://github.com/lkimuk/ReArk/issues)
- [License: Apache-2.0](https://github.com/lkimuk/ReArk/blob/main/LICENSE)
- [lkimuk/ReArk on GitHub](https://github.com/lkimuk/ReArk)
- [README](https://github.com/lkimuk/ReArk/blob/main/README.md)
- [Releases](https://github.com/lkimuk/ReArk/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lkimuk-reark