Reverse engineering Access without running it

Start with the file as potentially hostile input.

An Access database is not merely a neutral document. It may contain startup behavior, linked sources, forms, reports, queries, VBA, and macros. A useful evidence workflow therefore begins with a threat boundary, not an assumption that opening the file is harmless. The operator selects one authorized local file on an isolated Windows system with Microsoft Access available. Network locations and ambiguous file shapes are outside the supported file-first boundary.

The ordinary reader remains count-only for forms, reports, VBA modules, and macros. It does not read rows, open recordsets, run queries, render screens, invoke events, refresh links, or inspect protected command bodies. Those exclusions are product behavior, not merely advice added after extraction.

File-first means verified copy, generic identity, and disposable provenance.

The file-first path validates the selected file, hashes it, copies it under a generic database name into restricted scratch space, and verifies that the copy matches. TraceMap creates a no-remote disposable repository around that private copy so the resulting evidence still has a deterministic commit and scan identity. The provenance label is local-file-snapshot, which is deliberately different from an upstream repository commit.

After scanning, the original is checked again. A changed source, failed integrity check, timeout, or cleanup problem stops the workflow instead of becoming clean evidence. The original filename and machine-specific location are not persisted. The generic snapshot is removed on success, failure, or cancellation. This establishes a bounded chain of custody for the analyzed bytes; it does not establish that the database is safe, complete, correct, or representative of production.

Two provenance kinds answer different questions.

A clean tracked database can be anchored to a repository and commit. A locally selected database can be anchored to a verified disposable snapshot. Both preserve the rule ID, evidence tier, extractor version, coverage label, and bounded coordinate needed for review. They are not interchangeable. The local snapshot proves which verified copy TraceMap analyzed; it does not imply that the copy came from source control.

This distinction matters during handoff. A reviewer can ask whether a repository-backed artifact or an operator-supplied snapshot was used, whether its identity remained stable, and which owner can attest to the source. TraceMap supplies the evidence fields. It does not supply that owner attestation.

Protected design acquisition is separate from ordinary scanning.

Form and report bindings require a different input surface from catalog inventory. A Windows-only producer can create a protected, source-neutral design bundle from another verified disposable copy. Before Access is opened, startup behavior is suppressed on that inner copy. Automation stays invisible and force-disabled; canaries, source hashes, timeouts, process state, and scratch cleanup are checked. Any failed boundary becomes a stop or an explicit gap.

The bundle can describe closed categories such as record-source bindings, control-source bindings, row-source bindings, subform links, and report grouping or sorting evidence. Deterministic parsing and composition can then happen cross-platform without launching Access. Standard outputs retain stable opaque identities, hashes, categories, rule IDs, tiers, coverage, provenance, coordinates, and limitations—not the raw serialized design.

The optional VBA lane is a second protected boundary.

VBA source acquisition is not part of the ordinary database scan or the form/report metadata producer. It is a separate, optional Windows-only export lane with its own verified copy, startup suppression, invisibility, canaries, hash checks, timeouts, and cleanup gates. Protected source is processed locally and omitted from standard artifacts.

Static same-module candidates and event-property links can help orient a reviewer, but they do not prove that an event fired, that lifecycle order was observed, that a branch was feasible, or that a user followed a workflow. Embedded macros, dynamic handlers, and unsupported shapes remain gaps instead of guessed behavior.

Rules keep the public evidence smaller than the protected input.

legacy.access.database.inventory.v1 records the selected database and safe local capability evidence at Tier 2 structural or Tier 4 unknown. legacy.access.design-input.v1 records acceptance and bounded gaps for a versioned design bundle bound to a completed base scan. legacy.access.coverage-gap.v1 records platform, provider, trust, timeout, cleanup, parsing, ambiguity, unsafe-value, and extraction limits as Tier 4 unknown.

A gap means “unable to prove,” not “nothing exists.” A valid bundle proves only that its declared schema, hashes, binding, bounds, and vocabulary were checked. It does not prove exporter safety, catalog completeness, business intent, runtime reachability, or correctness. See the broader evidence model and gap guidance for how tiers and reduced coverage should constrain wording.

What a manager or reviewer can ask next.

The acquisition record makes concrete questions visible: Which provenance kind was used? Did source identity remain stable? Which protected producer supplied design evidence? What categories were omitted? Did any timeout, cleanup, ambiguity, or completeness gap reduce coverage? Who owns the file, the Access environment, and the runtime validation still required?

Use the manager proof path to keep those questions attached to evidence, the static-versus-runtime guide to separate declared structure from observed behavior, the capability index to locate the supported surface, and the change-review use case to frame owner follow-up. The limitations page remains part of the answer.

What this article does not prove.

TraceMap does not claim that it ran, rendered, queried, or reconstructed the Access application. It does not establish runtime execution, selected branches, event firing, production behavior, complete coverage, data correctness, effective permissions, successful reconstruction, release approval, or operational safety. Static evidence does not replace the database owner, Access specialist, security review, testing, runtime observation, or human approval.

Public material includes no database file, serialized definition, SQL or scheduled-command body, VBA or macro body, source snippet, credential, connection material, machine-specific path, private object identity, analyzer dump, or private validation detail. TraceMap core adds no LLM, embedding, vector, or prompt-based classification to make these findings.

The useful claim is intentionally modest.

TraceMap can produce bounded static evidence about one selected Access file while keeping raw acquisition material protected and uncertainty explicit. That evidence can make a modernization or change-review conversation more concrete. It cannot turn a static file into proof of a running application. Continue with the form-to-field lineage story to see how protected binding evidence becomes a bounded review path.