REA connects reverse engineering tasks to the CLI and MCP server, so you can start analyses from a terminal or an agent. For your first setup, it’s best to use a small project of your own to verify the full flow—“entry point verification → client connection → analysis → evidence check”—rather than testing with a production program.
The key to this tutorial is to validate two things separately: whether REA is running properly, and whether its interpretation of the target is correct. Check the former by inspecting the process and tool calls, and the latter by checking the original files and reproducible behavior.
Check the documentation to confirm supported targets and dependencies
Open the project documentation from the REA listing, and first look for installation instructions, CLI usage, and MCP integration examples. “Reverse engineer anything” is a capability overview, not a list of supported input formats.
Before installing, note the following:
| What to confirm | Where you’ll use it |
|---|---|
| Whether it accepts a source directory, a single file, or another target | Choosing an analysis sample |
| Runtime and version requirements | Setting up the local environment |
| Official installation command and CLI entry point name | Installation and entry point checks |
| MCP startup arguments and transport method | Configuring the client |
| Model, credentials, and external tool requirements | Troubleshooting startup and analysis failures |
Be sure to distinguish between the “CLI analysis command” and the “MCP server startup command.” An entry point that runs an analysis directly will usually exit after completing the task; a server connected to a client must continue interacting over the protocol. If you put the former in the server configuration, the process will commonly start and then immediately disconnect.
The terminal steps below use Bash on macOS or Linux. The sample uses Python source code; follow this route only after confirming that REA accepts this type of input. Binaries, traffic files, and web pages each require different processing workflows. Don’t try to force them into a source code analysis workflow by changing their file extensions.
Prepare a minimal sample you own or are authorized to use
For your first project, keep only one entry point, one conversion function, and a few input-output cases. That way, if the analysis results are off, you can pinpoint the issue to a specific line.
mkdir -p "$HOME/rea-lab/input"
cd "$HOME/rea-lab"
cat > input/token_demo.py <<'PY'
import base64
import sys
def encode_token(text):
payload = text.strip().encode("utf-8")
return base64.urlsafe_b64encode(payload).decode("ascii").rstrip("=")
if __name__ == "__main__":
print(encode_token(sys.argv[1]))
PY
python3 input/token_demo.py ' hello '
python3 input/token_demo.py 'hello'
python3 input/token_demo.py ' '
The first two outputs are both aGVsbG8, and the third output is an empty line. This sample includes three behaviors that are easy to verify: trimming leading and trailing whitespace, URL-safe Base64 encoding, and removing trailing padding characters.
Save another copy of the source with line numbers so you can check it line by line later:
nl -ba input/token_demo.py > source-numbered.txt
Give the analysis tool only the input directory, and keep the test records outside it. Have it infer the behavior from the target first, then compare its results with your records. This makes for a more meaningful validation.
Your own project may also contain secrets. Don’t put .env files, access tokens, or real user data in the analysis directory. If you’ve configured a remote model, file contents may be sent to the model service, so the plain test code here is sufficient for a first run.
Install and verify the command-line entry point
Install REA using the command in its documentation, and keep the full output. Don’t guess the package name from the project name and then try pip install or npm install: a package with the same name or an incorrect entry point can mislead subsequent troubleshooting.
After installation, check the actual CLI name in the current terminal. Enter the value yourself below; this does not assume the name of REA’s executable:
read -r -p "输入文档中的 CLI 入口名称：" REA_CLI
command -v "$REA_CLI"
The check succeeds when it prints the executable’s path. If nothing is printed, first check that installation completed and that the installation directory is on PATH. Don’t rush to configure the client.
Next, run the help command and minimal invocation listed in the documentation. At this point, confirm three things: the help text displays correctly, the arguments are recognized, and there are no runtime or missing module errors. Seeing the help text only confirms that the entry point is executable; it does not yet verify the analysis workflow.
If you used a virtual environment during installation, save the absolute path to the entry point within that environment. A GUI client won’t automatically inherit the environment activation you performed in the terminal.
Configure the client and check the connection
First, confirm the MCP transport method. The example below shows only the stdio connection structure to illustrate the fields; replace the placeholder values with the actual paths and arguments from the documentation. Don’t paste it as-is to start the server.
{
"mcpServers": {
"rea": {
"command": "/ABSOLUTE/PATH/TO/EXECUTABLE",
"args": ["MCP_START_ARGUMENT"],
"env": {}
}
}
}
Put the executable in command and split the arguments into an array in args. Don’t put the entire startup command, including spaces, into command. Add only the environment variables required by the documentation to env.
If the client uses a different configuration structure, map these three pieces of information to its server configuration. For HTTP connections, enter the server address instead of using the stdio example above.
After saving the configuration and reconnecting, validate in this order:
- The client started the server process, and it did not exit immediately.
- MCP initialization completed.
- The client listed the tools exposed by REA.
- The input parameters and target types in the tool descriptions are as expected.
The third step is especially important. Seeing “connected” in the chat window isn’t enough to confirm that the analysis tool can be called. Check the tool list first, then submit a task; don’t make up a tool name like analyze and ask the agent to call it.
Start an analysis and check the original files
Get the sample’s absolute path in the terminal:
cd "$HOME/rea-lab"
pwd -P
Append /input to the output path and pass it to the client. You can write the analysis request like this:
请调用已连接的 REA 工具分析下面的自有源码目录：
<替换为 input 目录的绝对路径>
目标：
1. 找出程序入口与调用关系。
2. 解释输入字符串到输出字符串的每一步转换。
3. 说明空白输入、非 ASCII 输入和缺少命令行参数时的行为。
4. 每个结论附上文件路径、函数名和相关代码位置。
5. 将源码直接支持的结论与推测分开列出。
只做静态阅读，不修改文件，不安装依赖，不执行目标代码。
Check the client’s tool call record: which tool was actually called, what path was passed in, and whether it returned content or an error. A response without a tool call does not count as validation of this connection.
When reading the results, prioritize evidence that pinpoints the code. In the sample, strip() explains why ' hello ' and 'hello' produce the same output; rstrip("=") explains why the result has no padding characters. Describing Base64 as encryption is a conceptual error; go back to the base64.urlsafe_b64encode line to correct it.
It’s also worth checking what happens when an argument is missing:
python3 "$HOME/rea-lab/input/token_demo.py"
The source accesses sys.argv[1] directly without checking for arguments, so this command triggers IndexError. If the analysis result says “displays usage help,” ask it to cite the entry point code again.
Troubleshoot by checking dependencies, paths, permissions, and inputs
When troubleshooting, preserve the first meaningful error instead of only capturing the final “connection failed” message.
If you see command not found, first check the CLI entry point and PATH. If you see ModuleNotFoundError or Cannot find module, check the runtime environment associated with the startup entry point. Avoid installing dependencies into a different interpreter or package environment.
If you see ENOENT or No such file or directory, verify the executable path and target path separately. The terminal’s current directory often differs from the client’s working directory, so use absolute paths for targets.
If you see Permission denied, check whether the target is readable, the directory is accessible, and the entry point is executable. Don’t use chmod -R 777 to hide the problem; it expands write permissions across the entire directory.
If the process starts but MCP initialization fails, check the startup arguments and transport method next. For stdio servers, standard output is used for protocol communication, so a startup script that prints a welcome message to stdout can interfere with the connection. Diagnostic logs should go to stderr.
Only then check the supported input range: narrow the target down to a single file, review the tool arguments and supported target types, and try again. For your first validation, keep three records: the startup command, the actual tool call, and the analysis conclusion with source locations. When you move on to a real project, it will be much clearer which layer has a problem.