# Native Export Findings

Source binaries:

- `current\aahClient.dll`
- `current\aahClientCommon.dll`
- `current\aahClientManaged.dll`

`dumpbin` was not available on PATH, so the PE export table was read directly.

## Export Counts

- `aahClient.dll`: 99 exports
- `aahClientCommon.dll`: 2 exports
- `aahClientManaged.dll`: 0 exports

Current DLL hashes are recorded in `capture-manifest.json`.

The x86 and x64 `aahClient.dll` builds both expose 99 exports. The undecorated
`mdas_*` names are stable across architectures; decorated C++ names differ only
by pointer/reference decoration.

This confirms `aahClientManaged.dll` is a managed/C++-CLI wrapper with no native
export surface of its own. The useful native ABI is in `aahClient.dll` and
`aahClientCommon.dll`.

## Relevant Query Exports

The exports below are the first ABI anchors for reproducing the native client
behavior in managed C#:

```text
mdas_StartDataRetrievalQuery
mdas_GetNextDataQueryResult
mdas_StartEventDataRetrievalQuery
mdas_GetNextEventDataQueryResult
mdas_StartBlockRetrievalQuery
mdas_GetNextBlockQueryResult
mdas_EndQuery
mdas_GetSystemParameter
mdas_GetRuntimeParameter
mdas_SetConnectionParameter
mdas_ConfigureParameter
mdas_SetParameter
mdas_GetSFParameter
mdas_SetSFParameter
```

`aahClient.dll` also exports decorated C++ names for newer structures:

```text
?mdas_AddHistorianValue2@@YAHKPEAUHISTORIAN_VALUE2@@PEAUHISTORIAN_ERROR@@@Z
?mdas_GetNextEventDataQueryResult@@YAHKKPEAVEventQueryResultRow@@PEAUHISTORIAN_ERROR@@@Z
?mdas_StartEventDataRetrievalQuery@@YAHK_K0IIGGAEAVEventQueryFilters@@PEB_WPEAKPEAUHISTORIAN_ERROR@@@Z
```

## Client Common Exports

`aahClientCommon.dll` exposes only:

```text
?CreateClientCommon@@YAPEAVIClientCommon@@PEA_W@Z
?DeleteClientCommon@@YAXPEAVIClientCommon@@@Z
```

That suggests `aahClientCommon.dll` owns the higher-level client object used by
the C++/CLI wrapper, while `aahClient.dll` exposes the procedural MDAS query ABI.

## Wrapper Load Evidence

The `mdas_*` exports remain useful ABI anchors, but they are not yet proven to
be on the active `aahClientManaged.dll` wrapper path.

Two local integrated read probes are negative evidence for that path:

- `dumpbin /dependents current\aahClientManaged.dll` shows no dependency on
  `aahClient.dll` or `aahClientCommon.dll`. The mixed-mode wrapper imports
  system DLLs such as `WS2_32.dll`, `Secur32.dll`, `RPCRT4.dll`, `NETAPI32.dll`,
  `CRYPT32.dll`, and `mscoree.dll`.
- `Test-AahClientManagedReadIntegrated.ps1 -DumpLoadedModules` lists only
  `aahClientManaged.dll` among the AVEVA/current DLLs during a successful
  wrapper read. It does not show `aahClient.dll` or `aahClientCommon.dll` loaded
  as separate modules.
- `Attach-NativeTraceHarnessAahClientExportCapture.ps1` attached before
  `aahClientManaged.dll` load and attempted to hook interesting exports from
  `aahClient.dll`. The same native direct history read succeeded, but the Frida
  capture never observed `aahClient.dll` being loaded and installed no export
  hooks.

This does not make the exported `mdas_*` ABI irrelevant; it may still be a
separate supported native client surface. It does mean the current C++/CLI
wrapper evidence target remains inside `aahClientManaged.dll` or a lower system
boundary, not `aahClient.dll` exports.

Follow-up system-boundary Frida passes also failed to catch the active wrapper
transport through exported user-mode APIs. Even when a Debian relay connection
was owned by the harness PID, hooks on exported Winsock calls, `WSAIoctl`,
`mswsock` extension exports, and `NtDeviceIoControlFile` produced no call
callbacks before the server-side security reset. Treat these exports as useful
static/native SDK evidence, not as the active wrapper capture route.

## Next ABI Tasks

- Demangle the decorated exports to recover exact signatures.
- Compare x86 and x64 export tables for drift.
- Capture call arguments for `mdas_StartDataRetrievalQuery`,
  `mdas_GetNextDataQueryResult`, `mdas_StartEventDataRetrievalQuery`, and
  `mdas_EndQuery`.
- Correlate the ABI calls with packet captures to map exported function calls to
  wire frames.