1C binary unpack/repack MCP
v8unpack-mcp
An MCP server for the full unpack-edit-repack cycle on .cf, .cfe, .epf, .erf files without an EDT import, with granular rebuilds and closed-module decompilation
High risk
We rate an entry high when the tool writes to external systems, handles money, production databases or secrets, or runs arbitrary commands. The CLI installs it only with your consent.
Why this level
- Decompiles closed modules from bytecode, which the platform license only permits for your own objects
- repack overwrites the configuration or processing binary based on the unpacked and edited directory
Install
Manual install
pip install -e .Install from source; the vendored v8unpack core is included in the package.
This is third-party code. Review the repository files before installing.
What it does
The server unpacks a 1C binary file into a temporary directory with an organized object tree and a parallel raw layer, provides tools for reading metadata, BSL modules, closed-module bytecode and searching code, forms and templates, then repacks the file. Repack itself picks the build path: byte-for-byte copying from the raw layer if the tree wasn't edited, granular rebuilding of only the touched objects if part was edited, or a full build from the tree. A separate four-step cycle finds closed modules, detects whether they're obfuscated, and decompiles the bytecode to BSL for analysis, though the decompiled result isn't guaranteed to compile in the platform. For large files there are async unpack_async and repack_async variants with job_status, so as not to hit the MCP client's timeout.
Who it is for. For 1C developers who need to quickly read or make a targeted edit to a binary .cf, .cfe, .epf or .erf file without a full EDT project import.
Good fit when
- You want to quickly look inside a .cf or .epf file without exporting it to an EDT project
- You need to make a targeted fix to one object in a large configuration and rebuild the file as fast as possible
- You need to compare two 1C binaries object by object and see a unified diff of what changed
Not a fit when
- The forms are 8.2-era managed forms (internal layout version 25-28): the README states their elements are not parsed or rebuilt at all
- The configuration is in the 8.0/8.1 format (version-2 objects): the container reads but object decoding fails
- You want to break protection on someone else's configuration: the README and DISCLAIMER explicitly restrict decompilation to your own objects
Example request
Unpack C:\1C\MyExt.cfe, find the Settings form module and show its sourceLimitations
The 1C:Enterprise 8 platform license forbids modifying the product's code and data by non-standard means and decompiling the system's software part; this restriction protects the platform and standard configurations, not the author's own configurations, extensions and external processing reports. The README and DISCLAIMER explicitly state that closed-module decompilation is implemented for research purposes and must not be used to break or remove protection on someone else's configurations, citing Article 146 of the Russian Criminal Code. Obfuscated modules are not decompiled at all. Spreadsheet templates (.mxl) are not parsed yet, a parser is in development. The 8.2 managed-form layout and the 8.0/8.1 format are unsupported. Large .cf files are fully extracted; per-object reading without a full unpack doesn't exist yet.
How to disable. Remove the v8unpack block from your MCP client configuration and run cleanup(all=true) to remove leftover unpack directories.
MCP
- Transport
- stdio
- Authentication
- not required
Security check
- Decompiles closed modules from bytecode, which the platform license only permits for your own objects
- repack overwrites the configuration or processing binary based on the unpacked and edited directory
README in short
The README describes in detail the unpack-read-repack-cleanup workflow, a table of fourteen tools with signatures, three repack build paths with speed measurements, a separate four-step closed-module decompilation cycle with an obfuscation detector, an async mode for large files, an architecture built on a vendored saby v8unpack core with patches, connection formats for different MCP clients including Kilo Code's special format, a list of known limitations, and a separate legal-notice section citing the platform license and Article 146 of the Russian Criminal Code. It ends by crediting the borrowed open-source components and their licenses.
FAQ
Does repack always rebuild the whole file from scratch?
No, it picks the path itself: if the tree wasn't edited it copies the raw layer byte-for-byte, if part of the objects were edited it rebuilds only those, and granular rebuilding is notably faster than a full one on large configurations.
Can decompiled code be loaded straight back into 1C?
Not guaranteed. The README states the decompiled result is meant for analysis and algorithm extraction, not for guaranteed platform compilation.
Related
A skills library that gives coding agents a development process: brainstorming, planning, TDD, subagents and code review
Skills for real engineers by Matt Pocock
Skills For Real Engineers
Small composable skills for engineering with agents: plan grilling, TDD, bug diagnosis, code review and architecture
GitHub toolkit for spec-driven development: the specify CLI adds agent commands and skills to a project, from principles to implementation
Reference MCP servers
Model Context Protocol servers
Official reference MCP servers: Filesystem, Fetch, Git, Memory, Sequential Thinking, Time and Everything