histsdk/docs/reverse-engineering/implementation-status.md

Implementation Status

Completed

• Production SDK targets net10.0 and has no AVEVA binary references.

• Public API now includes the intended parity surface:

  • TCP probe
  • raw, aggregate, at-time, and block history reads
  • event reads
  • tag browse and metadata calls
  • connection, store-forward, and system-parameter status calls
  • write-back intentionally remains out of scope for this read-only SDK pass

• Internal protocol scaffolding exists:

  • HistorianConnection
  • HistorianFrameReader
  • HistorianFrameWriter
  • Historian2020ProtocolDialect

• Evidence-backed WCF scaffolding exists:

  • WCF service names for Hist, Retr, Storage, Stat, and Trx
  • contract interfaces for history, history extensions, retrieval, retrieval extensions, and status
  • application/x-mdas message encoder wrapper
  • Net.TCP binding and endpoint factory for port 32568
  • bounded wcf-start-query harness options (--max-attempts and --timeout-seconds) so negative query probes do not have to run the full matrix
  • live local and remote GetV evidence for /Hist, /Retr, /Stat, and /Trx
  • live GetV evidence for /HistCert using MDAS over WCF Net.TCP transport security
  • ValidateClientCredential token wrapping and the native NTLM negotiate VERSION flag adjustment as isolated, tested protocol primitives

• ProbeAsync now uses fully managed WCF/MDAS GetV calls instead of a raw TCP socket check.

• Managed Hist.OpenConnection reaches server logic, but the older scalar operation expects the native password/session packet.

• Managed Hist.Open2 now reaches server logic with a version-1 byte buffer. Empty credentials return custom native error 171 (AuthenticationFailed), confirming the basic byte-buffer framing and UTF-16 string encoding.

• Managed integrated Windows Open2 succeeds when the same version-1 buffer is sent to /Hist-Integrated with WCF Windows transport security. /Hist with that binding fails before the operation call because the upgrade is not supported on the plain history endpoint.

• The same managed integrated Windows Open2 flow succeeds remotely against <historian-host>:32568/Hist-Integrated; the returned handle is accepted by Retr.IsOriginalAllowed. The stored artifact redacts the session output buffer and transient handle value.

• The native aahClientManaged.dll path is confirmed to open successfully with integrated Windows auth after polling GetConnectionStatus until pending clears.

• The native integrated read path is confirmed to reach query execution: a deliberately missing tag returns native TagNotFound (127) instead of connection/authentication failure.

• scripts\Find-GalaxyHistorizedTags.ps1 queries the local Galaxy Repository (localhost, database ZB, Windows auth) for non-array dynamic attributes with HistoryExtension.

• OtOpcUaParityTest_001.Counter is confirmed as a live native read fixture candidate. A 1440-minute native wrapper read returned one row with timestamp 2026-04-30T11:00:29.4340342Z, Value = 0, Quality = 133, OpcQuality = 192, and QualityDetail = 248.

• A Frida attach pass can see aahClientManaged.dll and install hooks at candidate mixed-mode RVAs, but those base + RVA hooks do not fire during the successful read. The next capture approach must intercept CLR/WCF managed byte-array calls rather than raw method RVAs. See frida-aahclientmanaged-hook-pass.md.

• tools\AVEVA.Historian.NativeTraceHarness is a reverse-engineering-only .NET Framework harness for native integrated reads. It records sanitized reflection snapshots around OpenConnection, StartQuery, and MoveNext. The latest run confirms StartQuery assigned queryHandle = 1 and returned tag key 238, value 0, quality 133, OPC quality 192, and quality detail 248 for OtOpcUaParityTest_001.Counter. It now supports fixed UTC windows plus configurable retrieval mode and resolution; latest artifacts cover Full, Cyclic, Interpolated, and TimeWeightedAverage.

• The native trace harness also supports --scenario event with an event connection. The latest event artifact confirms EventQuery.StartQuery succeeds and returns three sanitized local-dev event rows for a seven-day window.

• scripts\Attach-NativeTraceHarnessWinsockCapture.ps1 and scripts\frida\aahclientmanaged-winsock.js can attach before native OpenConnection and hook Winsock plus common file/pipe APIs. Localhost, 127.0.0.1, and the machine LAN IP all completed successful native reads without observed connect/send/recv, CreateFile/ReadFile/WriteFile, or NtCreateFile/NtReadFile/NtWriteFile payload events. This is negative evidence that the installed local Historian path uses an in-process/local optimization rather than the remote Net.TCP transport path.

• An expanded Frida method pass added decompiled QueryColumnSelector and HistorianClient.StartDataQuery/GetNextRow MethodDef RVAs. Hooks installed where Frida allowed them, but no enter/leave events fired during successful native reads. MethodDef RVAs from the mixed-mode assembly are not the actual CLR/native dispatch targets.

• The native trace harness can now dump prepared CLR runtime method pointers for mixed-mode <Module> methods such as HistorianClient.StartDataQuery, CRetrievalConnectionWCF.StartQuery2, HistorianClient.GetNextRow, and HistorianClient.StartEventQuery. The corrected artifacts show these pointers are process-specific CLR/JIT entry addresses outside the loaded aahClientManaged.dll image, not stable DLL RVAs.

• scripts\Attach-NativeTraceHarnessRuntimePointerCapture.ps1 automates a same-process Frida pass against those runtime pointers. It successfully generated a pre-StartQuery pointer snapshot and installed 37 absolute hooks while the native direct history read was paused. The read then succeeded, but no hook enter/leave callbacks fired. This is negative evidence for using MethodHandle.GetFunctionPointer() addresses as direct Frida hook targets.

• scripts\Attach-NativeTraceHarnessAahClientExportCapture.ps1 and scripts\frida\aahclient-exports.js attempted to hook the procedural mdas_* exports from aahClient.dll. A successful local direct history read did not load aahClient.dll, and dumpbin /dependents confirms aahClientManaged.dll does not import aahClient.dll or aahClientCommon.dll. A separate -DumpLoadedModules run showed only aahClientManaged.dll among the current AVEVA DLLs. The exported mdas_* ABI is likely a separate native client surface, not the active C++/CLI wrapper boundary used by this harness.

• scripts\Attach-NativeTraceHarnessSystemBoundaryCapture.ps1 and scripts\frida\aahclientmanaged-system-boundary.js now hook file I/O, Nt*File, NtDeviceIoControlFile, DNS, exported Winsock calls, WSAIoctl, mswsock extension exports, Secur32, Crypt32, and NetAPI. Local direct and same-machine remote-IP reads produce no boundary callbacks beyond hook installation. A Debian relay run confirms the relay TCP connection is owned by the harness PID, but the same exported user-mode hooks still see no connect/send/recv/device-control callbacks before the security reset.

• scripts\Run-PktmonDebianRelayCapture.ps1 records pktmon metadata for the Debian relay path without retaining raw payload bytes. The latest history run captured TCP packet metadata for <relay-host>:32568, converted the ETL to a text report, deleted the ETL, and wrote a summary confirming PayloadBytesCaptured = false and RawEtlDeleted = true.

• Focused ildasm excerpts now confirm ArchestrA.HistoryQuery.StartQuery has an IL call at IL_02d2 to HistorianClient.StartDataQuery token 060055E4, and HistoryQuery.MoveNext has an IL call at IL_0054 to HistorianClient.GetNextRow<class DataQueryResultRow> token 0600588D. IL-rewrite instrumentation is now validated: a dnlib-written wrapper copy can run in a disposable DLL folder, and an instrumented <Module>.Query.StartDataQuery captured a 251-byte native DataQueryRequest buffer during a successful local direct read.

• The captured full-history buffer corrected the managed HistorianDataQueryProtocol serializer. It now matches the native wrapper byte-for-byte for the deterministic OtOpcUaParityTest_001.Counter fixture. The buffer hash is 3581ef3b42b59b46503d1aa0127fa60fe4b40943e419aeab99e47e4683888851.

• The same instrumentation path now captures the native DataQueryResultRow* memory after GetNextRow. The first full-history row confirms tag key, timestamp, quality, OPC quality, quality detail, and percent-good offsets; the artifact hash is 2c2cb06988187c1bd7793a52a71f33599542a69d5e83885c583de8bf3df5d43b.

• The read-boundary instrumentation now logs GetNextRow arg.1 as an explicit queryHandle scalar before dumping arg.2 row memory. A combined local read captured StartDataQuery.Request SHA 543ea11af87607044067a0274b1da423cef2acbb7b4f4fab137af023a7153d7f, GetNextRow.QueryHandle = 1, and GetNextRow.DataQueryResultRow SHA 702f5248cf8319e3e02da33678ed97dfaa43666bddb88c42101d5290990a4198 in the same session.

• A follow-up combined IL instrumentation pass correlated the native open, query, WCF retrieval, and row-read handles. HistorianClient.OpenConnection wrote legacy handle 2, and Query.StartDataQuery read the same value as its ClientHandleCandidate immediately before entering the common retrieval layer. The successful CRetrievalConnectionWCF.StartQuery2 call then used a different transient WCF retrieval client handle. This proves the missing read parity state is the native client/session mapping below the legacy ClientApp handle, not the 251-byte DataQueryRequest payload.

• Instrumenting aahClientCommon.CServerClient.GetHandle token 060017F9 produced no records during a successful local history read, even while the surrounding open/query/WCF hooks fired. Direct metadata-token scanning also found no IL references to that accessor. The transient WCF retrieval handle is not obtained through GetHandle on this path.

• Instrumenting aahClientCommon.CRetrieval.StartQuery2, aahClientCommon.CSrvRetrievalConnection.StartQuery, and CRetrievalConsoleClient.StartQuery also produced no records in the successful WCF read path. The active path is instead aahClientCommon.CClientCommon.StartQuery token 06002E86.

• The CClientCommon.StartQuery instrumentation captured the missing handle boundary: legacy handle 2 enters Query.StartDataQuery, then CClientCommon.StartQuery calls a CClient vtable function at IL offset 0x01A3. The returned transient value exactly equals the client handle used by CRetrievalConnectionWCF.StartQuery2 and GetNextQueryResultBuffer2. The WCF server query handle returned by StartQuery2 is copied back through the queryHandle pointer, while the public managed HistoryQuery.queryHandle remains the wrapper value 1. Sanitized evidence is in cclientcommon-startquery-correlation-latest.json.

• CClientBase.OpenConnection confirms that same vtable offset 24 is the handle accessor: the initial value is 0, then the secondary open branch succeeds and the post-open value exactly matches the later CClientCommon.StartQuery and WCF StartQuery2 client handle. The primary open branch did not emit records on this local integrated path. Sanitized evidence is in cclientbase-open-correlation-latest.json; the next target is the secondary open vtable call at IL offset 0x06D4.

• The secondary open branch resolves to CHistoryConnectionWCF.OpenConnection3 token 06004059. It calls IHistoryServiceContract2.OpenConnection2 with a 1346-byte request and gets a 42-byte response with empty error. The deserialized response initializes the vtable offset 24 handle later used by CClientCommon.StartQuery and /Retr.StartQuery2. In the captured 42-byte response, byte 0 is 0x03 and the transient /Retr client handle is UInt32 little-endian at offset 1. CClientInfo.DeserializeOpenConnectionOutParams token 06004008 confirms the response layout: byte protocol version, uint32 client handle, 16 session bytes, one FILETIME, and for version 3 an additional FILETIME. The observed five-byte tail is preserved as opaque trailing data until a caller or native field assignment is identified. CClientInfo.SerializeOpenConnectionInParams4 token 06004003 confirms the observed request starts with protocol byte 6, a 16-byte client key, and a boolean content selector. The observed selector is 0, so the active content branch is SerializeOpenConnectionInParams2Content token 06004005, whose field order matches the existing native version-3 content serializer: host string, UInt16 secret length plus secret bytes, client type, connection mode, metadata namespace, two strings, and client common info. CMetadataNamespace.Save uses compact/scrambled empty strings in this envelope, so the empty metadata namespace is 10 bytes rather than the older 13-byte plain layout. With that correction, managed replay with the observed 1026-byte zero credential block reaches server credential validation instead of packet-version rejection. Both /Hist-Integrated Windows transport and /HistCert certificate transport now return native error 171 with an extended message saying the server context could not be found. That makes the leading 16-byte OpenConnection3 key the next evidence target. A same-run memory-correlation pass now proves request bytes 1..16 exactly match CClientInfo +1240, and request byte 17 matches CClientInfo +1608. CClientInfo.SetContextKey token 0600386E copies its GUID argument to the same CClientInfo +1240 field, but no direct IL caller exists. The actual source is now narrowed to CClientBase.ConfigureOpenConnection token 0600388C: it calls native CClientContext.AuthenticateClient token 06005DCB on CClientBase +2112, then copies 16 bytes from CClientBase +2176 (CClientContext +64, the GetContextKey location) to CClientBase +1480. Since this aligns with CClientInfo +1240, the prefix is the context key that native AuthenticateClient validates before OpenConnection3, not an arbitrary fresh managed replay GUID. Runtime instrumentation around AuthenticateClient confirms the field equals the generated client key before authentication, changes during the native auth path, then matches the copied CClientInfo field and the OpenConnection3 request prefix. A direct managed Hist-Integrated.ValidateClient2 probe reaches the service but fails with native error type 4/code 51 before ExchangeKey. Sanitized IL instrumentation of CHistoryConnectionWCF.ValidateClient (06004044) and CHistoryConnectionWCF.GetClientKey (06004041) was present in an isolated wrapper copy and the logger smoke test passed, but a successful native integrated history read emitted no ValidateClient2 or ExchangeKey records. That negative result rules out the obvious managed WCF auth methods for this path. Native disassembly of CClientContext.AuthenticateClient (06005DCB, RVA 0x298BA0) shows it uses Secur32 AcquireCredentialsHandleW with package Negotiate, creates a context GUID at CClientContext +64, and loops through CHistoryConnectionWCF.ValidateClientCredential / WCF ValCl. Instrumenting ValCl confirms two successful native rounds: a 69-byte client input to 239-byte server output, then a 93-byte client input to a one-byte terminal output. The client input envelope is one round byte, a 4-byte little-endian token length, then an NTLMSSP token; the first native input prefix is 01400000004e544c4d5353500001000000b7b218e209000900370000000f000f. System-boundary Frida evidence now confirms that these wrapped payloads come directly from SSPI: native calls AcquireCredentialsHandleW with package Negotiate, then two InitializeSecurityContextW calls for NT SERVICE\aahClientAccessPoint. The raw SSPI output token lengths are 64 and 88 bytes, matching the 69- and 93-byte ValCl bodies after the 5-byte AVEVA wrapper is added. The first call returns SEC_I_CONTINUE_NEEDED (0x90312) and the second returns success. Native disassembly of CClientContext.AuthenticateClient now maps the loop directly: it is native-only, calls UuidCreate, stores the context GUID at CClientContext +64, calls AcquireCredentialsHandleW, and enters a loop at VA 0x180298DE0. The internal helper at VA 0x180298F30 calls InitializeSecurityContextW, uses request flags 0x2081C on the first round and 0x81C on later rounds, then writes the ValCl stream envelope as round byte, UInt32 token length, and token bytes. The outer loop copies CClientContext +64 as the context key and calls the connection's ValidateClientCredential virtual method; in the captured local read, CClientContext +0x50 is zero, so the normal connection-object virtual path at VA 0x180298E95 is selected. A stable IL-side memory window around CClientContext.AuthenticateClient shows the embedded CClientContext mutates only four regions in the first 256 bytes during successful auth: pointer-sized fields at offsets +8, +16, and +24, plus the context key at +64..+79. Dereferencing the +8 target shows SSPI/security-package metadata strings such as Schannel, Microsoft Kerberos V1.0, TSSSP, System.Core, and Default TLS SSP. The +16 target is partially decoded as pointer-rich native state: nested targets at offsets 0 and 8 have the same pointer/count shape and no readable ASCII or UTF-16 Historian payload strings, while the nested target at offset 64 is all zero. The +24 value is not safe to treat as a directly readable buffer. This narrows the missing managed replay state to native CClientContext object state and server acceptance of that client context key, rather than the SSPI token bytes alone. A managed NegotiateAuthentication probe can reproduce that first wrapped input exactly after setting the NTLM VERSION negotiate flag, but standalone ValCl still fails with native error type 4/code 1 on both /HistCert and /Hist-Integrated. That means the active blocker is not the first token envelope; it is native connection/session prerequisite state around proxy initialization or server-side context registration. A follow-up instrumented local read shows the native path constructs CHistoryConnectionWCF, then calls GetInterfaceVersion before auth. The first GetInterfaceVersion InitializeProxy path succeeds and SetManagedPtr sets the ready flag to 1; by both successful ValCl rounds, COperation.Start2 succeeds with error type/code 0, the existing proxy is not faulted, and the reconnect flag is 0. Branch instrumentation now shows the local native path uses connection mode 1, enters CWcfConfig.ConfigurePipeProxy, builds the uncompressed local /Hist named-pipe endpoint shape, and does not use ConfigureTcpProxy. Static IL inspection of ConfigurePipeProxy confirms this path builds a NetNamedPipeBinding with Security.Mode = None, TransactionFlow = false, native-sized MaxBufferSize/ReaderQuotas.MaxArrayLength, and the aahMDASEncoder.ClientBinding wrapper. It then creates the channel through the static ChannelFactory<T>.CreateChannel(binding, endpoint) helper and sets IContextChannel.OperationTimeout from the native timeout-minutes argument. Managed pipe probes using the same static-factory channel shape, with and without eager channel open, still fail in the same way. A managed named-pipe ValCl replay reaches GetInterfaceVersion version 11 and reproduces the first wrapped token hash, but is still rejected at round 0 with native error type 4/code 1; explicitly running the managed calls under the current Windows token does not change that result. Native handle summaries show uppercase GUID text, and managed lowercase-handle replay still fails, so handle casing is not the mismatch. Skipping GetInterfaceVersion and avoiding explicit WCF channel open in the managed TCP probe also returns native error type 4/code 1, so the mismatch is not just transport or token bytes. Because native GetInterfaceVersion creates its proxy while impersonating the stored Windows identity, the managed pipe probe was extended to create/open the channel inside the same current-token impersonation scope; that still fails at ValCl round 0, with and without also wrapping the operation calls. A local System Platform log check shows the managed pipe ValCl failures correspond to aahClientAccessPoint warnings: ValidateClientCredential caught exception: System.NullReferenceException at HistoryService.ValidateClientCredential line 1593. Enabling named-pipe transport security is rejected as a binding mismatch, which confirms the native uncompressed pipe binding shape. A new direct .NET Framework WCF probe using the same aa/Hist contract, MDAS content type, uncompressed named pipe, and SSPI-generated first token also fails with native error type 4/code 1 and the same server log exception. That rules out a simple .NET 10 WCF regression: the success condition belongs to AVEVA's mixed/native wrapper state, not a plain full-framework WCF client. Static IL inspection of COperation.Start2 shows it is only a local gate: it checks operation-priority and bandwidth controls and can set local gate-failure error codes 243 or 150, but it does not call a WCF service operation. Static inspection of the local aahClientAccessPoint.exe service now maps the receiving side of this failure. HistoryService.ValidateClientCredential parses the WCF handle as a GUID, allocates a CServerBuffer, copies the ValCl byte array into that buffer, and calls native CServerNode.ProcessServerToken. That native method parses exactly the AVEVA token envelope already observed on the client side: one round byte, a 4-byte little-endian token length, then SSPI token bytes. On the first round, ProcessServerToken calls helper 0x0050FFC0, which locks the server context collection and inserts or refreshes a keyed native context object. It then calls helper 0x00517AB0 to look up that object. If no context object is returned, the server sets custom error code 0x29 and ValCl fails before any successful context registration. With a context object, helper 0x00505C00 calls Secur32 AcceptSecurityContext through the service import table at 0x005A0340, treating both success and SEC_I_CONTINUE_NEEDED (0x90312) as valid protocol progress. Only after the terminal round does HistoryService.ValidateClientCredential add the context GUID to its managed context-handle collection. This confirms the remaining managed replay gap is before or inside server ProcessServerToken context setup/lookup, not OpenConnection3 itself. A tighter IL window confirms the line number reported in System Platform logs is the catch/log path, not the exact null-reference instruction. The normal path is: Guid.TryParse on the WCF handle at IL 0x012A, CServerBuffer allocation through a vtable call at 0x0183, byte-array pointer/length copy into buffer offsets +72/+76, and CServerNode.ProcessServerToken at 0x01DC. Only when the native call returns success with continue == false does IL 0x0311 add the parsed context GUID to m_contextHandles; when continue == true, the method returns the server token without final handle registration. This keeps the runtime server helper probe as the most direct remaining evidence target. Additional server disassembly and string decoding identify the native object as aahClientAccessPoint::CServerContext. The first-round setup helper uses the server lock at CServerNode +0xE80 and keyed context map at CServerNode +0xE98, logs Adding ServerContext 0x%p, constructs a 0x3c-byte context object through helper 0x00505100, and inserts the new node through a red-black-tree insertion helper at 0x0042F590. The lookup helper reads the same map and returns the context object from map node offsets +0x20/+0x24; a null result is what drives the 0x29 custom error path. The credential helper calls AcquireCredentialsHandleW with the UTF-16 package string Negotiate. The token-processing helper is logged as aahClientAccessPoint::CServerContext::ProcessClientToken; its failure log string still says InitializeSecurityContext, but the import actually called by this server helper is Secur32 AcceptSecurityContext. HistoryService.ValidateIntegratedCredentials is a separate server path: its first instructions read ServiceSecurityContext.Current.WindowsIdentity. That explains the earlier OpenConnection2/OpenConnection3 null-reference failures on bindings where ServiceSecurityContext.Current is absent. Those errors are evidence of selecting the wrong integrated-credential path, not a user/password validation result. A focused object-window capture now shows the successful native GetInterfaceVersion path populates the history proxy managed-pointer slot at CHistoryConnectionWCF +608 and the ready flag at +669; between GetInterfaceVersion completion and ValCl entry, a second managed-pointer slot at +616 is populated for the binding wrapper. Across both successful ValCl rounds the parent CHistoryConnectionWCF object window is stable, but the +608 history proxy target mutates at bytes 96..101; the +616 binding target and +640 Windows identity target remain stable. This points at native-managed proxy wrapper state as the next concrete evidence target. Static IL inspection of CHistoryConnectionWCF.Initialize narrows the meaning of the AVEVA log line that says Initialize: DataSourceId(). It is client-side connection/proxy setup, not a separate WCF Initialize operation: the method logs Initialize, retrieves or creates the managed /Hist proxy and binding through InitializeProxy<IHistoryServiceContract2>, stores those pointers at the same +608/+616 managed-pointer slots seen at runtime, then does the same for the /Trx proxy. The history proxy initializer has only the previously mapped WCF setup branches: ConfigurePipeProxy at IL 0x0098 and ConfigureTcpProxy at IL 0x038E, followed by SetProxyString. The decompiled HistoryServiceContract interfaces contain no Initialize operation contract. This makes the log line supporting evidence for local proxy setup state, but not a missing service call that a managed replay can simply add before ValCl. A focused server-side Frida probe was added at scripts\frida\aahclientaccesspoint-valcl-context.js with runner scripts\Capture-AahClientAccessPointValClContext.ps1. It hooks ProcessServerToken, the first-round context setup and lookup helpers, and the AcceptSecurityContext wrapper while logging only sanitized pointer, GUID, round, length, and return-value metadata. The script writes a .frida.log sidecar.

  An elevated PowerShell session (Admin, High Mandatory Label, SeDebugPrivilege enabled, SeImpersonatePrivilege enabled) ran both scenarios on 2026-05-03 and Frida attach was still rejected with the CLI message Failed to attach: process with pid <pid> either refused to load frida-agent, or terminated during injection. Direct frida.attach(<pid>) from the Python API reveals the actual exception class is frida.ProcessNotRespondingError, which means the agent injection handshake did not complete in time, not that the OS refused the DLL load. The original suspected cause (mitigation policy MicrosoftSignedOnly / BlockNonMicrosoftBinaries) is now disproven: Get-ProcessMitigation -Id <pid> reports every category OFF for this process, including BinarySignature.MicrosoftSignedOnly, DynamicCode.BlockDynamicCode, Cfg.Enable, ImageLoad.BlockRemoteImageLoads, ExtensionPoint.DisableExtensionPoints, and UserShadowStack.*. Process access from the elevated token also succeeds at PROCESS_ALL_ACCESS, including PROCESS_VM_OPERATION, PROCESS_VM_WRITE, and PROCESS_CREATE_THREAD, so the DACL is not blocking injection. Cross-bitness Frida (64-bit Python attaching to a fresh C:\Windows\SysWOW64\cmd.exe) attaches and runs scripts cleanly, so the WOW64 path itself is not broken. Defender real-time protection, behavior monitoring, and on-access protection are all OFF, no third-party AV/EDR product is registered with SecurityCenter2, no EDR-style filter driver is active, no frida modules appear in the target's loaded module list before or after a failed attempt, no IFEO debugger entry exists for aahClientAccessPoint.exe, and AppInit_DLLs is empty in both 64-bit and WOW64 hives. Attach attempts with realm='native', realm='emulated', and persist_timeout=30 all fail identically. The remaining likely cause is service-internal: aahClientAccessPoint.exe runs 152 threads, many in EventPairLow ALPC/SCM waits, and Frida's in-memory manual-mapper agent does not get a cooperative thread for its RPC bootstrap. This is consistent with ProcessNotRespondingError rather than a load-time rejection. The NativeRead probe still completed end-to-end with the canonical fixture row (TagKey=238, Value=0, Quality=133, OpcQuality=192, QualityDetail=248) but emitted no server-side helper events. The ManagedValCl probe ran the .NET Framework named-pipe ValCl path against net.pipe://localhost/Hist, reproduced the canonical first wrapped NTLM envelope (raw outgoing 64 bytes, wrapped 69 bytes, wrapped prefix 01400000004e544c4d5353500001000000b7b218e209000900370000000f000f), and again returned ServerSuccess=false, ServerOutputLength=0, ErrorLength=5 with NativeError {Type:4, Code:1, Name:Failure} — matching prior managed named-pipe ValCl failures and confirming the failure shape is reproducible but providing no new server-side helper visibility. None of the five diagnostic questions (whether 0x0050FFC0 ran, whether 0x00517AB0 returned a context, whether AcquireCredentialsHandleW succeeded, whether AcceptSecurityContext was reached, whether failures are pre- or post-context-map insertion) can be answered from these captures.

  ETW SSPI tracing on 2026-05-03 produced server-helper-boundary evidence without injection. A logman trace session capturing the LsaSrv {199FE037-2B82-40A9-82AC-E1D46C792B99}, LSA {CC85922F-DB41-11D2-9244-006008269001}, Microsoft-Windows-NTLM {AC43300D-5FCC-4800-8E99-1BD3F85F0320}, NTLM Security Protocol {C92CF544-91B3-4DC0-8E11-C580339A0BF8}, and Security: NTLM Authentication {5BBB6C18-AA45-49B1-A15F-085F7ED0AA90} providers at level 0xFF and keywords 0xFFFFFFFFFFFFFFFF recorded:

  Run	Total events	aahClientAccessPoint events	lsass events
  NativeRead (success)	5610	10	4330
  ManagedValCl (fail)	133	0	121

  Successful native server-side activity is a 47-millisecond burst of legacy MOF events (Ids 30, 34, 35, 40, 84, 10, 12, 16, 17, 86) inside PID aahClientAccessPoint. The failing managed run produces zero events from the server PID at all — the server never reaches any SSPI helper invocation. lsass activity is also 35x lower in the failing run, consistent with auth never completing the first round end-to-end. This pins the previously logged HistoryService.ValidateClientCredential caught System.NullReferenceException at line 1593 to a code path before CServerNode.ProcessServerToken at IL 0x01DC.

  Static IL inspection of the full HistoryService.ValidateClientCredential body (token 0x06000774 in mixed-mode aahClientAccessPoint.exe, 779 instructions, dnlib output preserved at artifacts/reverse-engineering/server-historyservice-validateclientcredential-il-latest.json) enumerates every NRE-capable instruction reached on the straight-line happy path before the ProcessServerToken call:

  • Prologue (IL 0x0000..0x0129). Constructs a std::wstring, case-insensitively compares two wide strings via _wcsicmp (0x00A0), and calls CServerNode.LogHistorianMessage(this, _, CServerClient*, _, _, _, _) at 0x00ED. The third argument is a CServerClient*. If that pointer is derived from OperationContext.Current or related WCF context state and is null for the calling binding shape, the call site itself is an NRE candidate before Guid.TryParse is reached.
  • Guid parse and recover (IL 0x012A..0x015E). Guid.TryParse on arg.1 at 0x012A. False branch raises custom error code 28 via SError.SetToCustomError and returns. True branch calls <Module>::PtrToStringChars at 0x0150 then <Module>::GuidFromString at 0x0159 to recover a native _GUID for ProcessServerToken. Guid.TryParse cannot NRE on a non-null string; the recovery path only NREs if the string is null, which a successful TryParse rules out.
  • Allocator vtable chain (IL 0x0160..0x0183). Loads &g_ClientAccessPoint + 2328, dereferences once at 0x0178 to get the allocator pointer pAllocator, then derefs *pAllocator at 0x017E (vtable pointer) and *(vtable + 40) at 0x0182 (slot for the allocator method), and calli at 0x0183 returns CServerBuffer*. NRE candidates: 0x017E if the field at g_ClientAccessPoint + 2328 is null/uninitialised, or 0x0182 if the vtable is malformed. Both target a process-wide static, so they would fail identically for the successful native path; rule out unless the field is initialised lazily per-binding.
  • Allocator-null branch (IL 0x0189..0x01A3). brtrue.s on the returned CServerBuffer*. Null path raises custom error code 204 ("No more buffer") and returns false. So a null allocator result is handled and not the NRE source.
  • Byte-array copy (IL 0x01A8..0x01C6). ldelema System.Byte on arg.2 at 0x01AA and ldlen on arg.2 at 0x01B2. Both NRE if the WCF-deserialised inputBuffer parameter is null. The two pointer/length values are then stind.i4'd into *(CServerBuffer + 72) and *(CServerBuffer + 76), matching the documented +72/+76 offsets.
  • ProcessServerToken call (IL 0x01CA..0x01DC). Loads &(g_ClientAccessPoint + 2144) as the CServerNode* this, the parsed _GUID, the CServerBuffer*, a ref bool continue, and a ref SError, then calls ProcessServerToken (token 0x0600064F).

  The IL slice does not include exception-handler metadata (current dnlib-method output covers instructions only), so the precise source-line 1593 reported by the System Platform log catch handler cannot be mapped to one specific instruction from static IL alone. The structural narrowing is: the throw must happen at a ldelema, ldlen, ldind, or calli instruction reached before 0x01DC. The shortlist is 0x00ED (LogHistorianMessage with CServerClient*), 0x017E and 0x0182 (allocator vtable derefs), and 0x01AA / 0x01B2 (byte-array deref). All other instructions in the window either operate on managed strings already proven non-null or on static-field addresses.

  Differential analysis against the successful native path narrows this further. g_ClientAccessPoint is a process-wide singleton, so the +2328 field has the same value for both runs; the vtable chain is therefore unlikely to be the differentiator. The native wrapper's successful local read uses the same Security.Mode = None uncompressed pipe binding the managed probe uses, so ServiceSecurityContext.Current.WindowsIdentity is identical in both paths and the prologue CServerClient* derivation is also unlikely to be the differentiator. The remaining structural difference is the WCF parameter binding: if the managed probe's SOAP body schema causes WCF to deserialise inputBuffer as null even though a 69-byte wrapped token is on the wire, ldelema at 0x01AA would NRE. The managed probe sends 69 bytes per its sanitised log, but the schema expectation on the server side has not been verified end-to-end.

  The next concrete evidence target is therefore not more static IL, but a SOAP-body comparison: dump the actual <inputBuffer> element the .NET Framework probe writes versus the wire shape the native wrapper writes for /Hist-Integrated.ValCl. If the schemas differ, the WCF service deserialises arg.2 as null and the IL window decisively fails at 0x01AA. If the schemas match, the throw is earlier (the prologue's CServerClient* log argument becomes the prime suspect) and runtime confirmation needs PsExec SYSTEM injection or a signed Detours stub at IL 0x00ED.

  SOAP-body comparison on 2026-05-04 resolved this. Enabling <system.serviceModel><diagnostics><messageLogging logEntireMessage="true" logMessagesAtTransportLevel="true" .../> in AVEVA.Historian.NetFxWcfProbe.exe.config and capturing the on-the-wire SOAP body for the failing aa/Hist/ValCl request produced:

  <ValCl xmlns="aa">
    <handle>...GUID...</handle>
    <inputBuffer>AUAAAABOVExNU1NQAAEAAAC3...</inputBuffer>
  </ValCl>
  

  The 69-byte wrapped NTLM token IS on the wire as base64 inside <inputBuffer>. The matching server response, however, used <outBuff b:nil="true" .../> rather than the expected <outputBuffer .../> shape, exposing a parameter-name mismatch. ildasm against aahClientAccessPoint.exe confirmed the actual server contract is

  ValidateClientCredential(string handle,
                           uint8[] inBuff,
                           [out] uint8[]& outBuff,
                           [out] uint8[]& errorBuffer)
  

  not inputBuffer / outputBuffer. WCF builds the request body element name from the C# parameter name, so the probe sent <inputBuffer> and the server's WCF deserialiser ignored that unknown element, leaving arg.2 = inBuff = null. IL 0x01AA ldelema System.Byte then NREs, which the C++/CLI catch handler at HistoryService.cpp line 1593 maps to native error Type=4 Code=1 Failure with an empty error buffer.

  Adding [MessageParameter(Name = "inBuff")] and [MessageParameter(Name = "outBuff")] to the probe's ValidateClientCredential declaration and re-running unblocks the request: round 0 returns ServerSuccess=true, ServerOutputLength=239, ServerContinue=true, with ServerOutputPrefixHex 014e544c4d535350000200... (a 0x01 continue byte followed by NTLMSSP type-2 challenge). This matches the previously documented native-success "69-byte client input to 239-byte server output" exactly. Round 1 then sends the 88/93-byte NTLMSSP type-3 token and the server returns Type=129 Code=0x80090308 (SEC_E_INVALID_TOKEN) with a 100-byte error buffer whose ASCII payload includes aahClientAccessPoint::CServerContext::ProcessClientToken and InitializeSecurityContext. That is a real SSPI-level rejection inside AcceptSecurityContext, not the previous parameter-binding NRE — the original blocker is gone and the next layer of failure is exposed.

  The same fix is now applied to the production SDK contracts IHistoryServiceContract2.ValidateClientCredential and IStorageServiceContract.ValidateClientCredential via [MessageParameter(Name = "inBuff" | "outBuff")], preserving the conventional C# parameter names while making WCF emit the server-correct element names. ildasm against aahClientAccessPoint also revealed several other operations the SDK does not yet need (EnsT InBuff/OutBuff, EnsT2 InBuff/OutBuff, RTag2 pInBuff/outBuff, ExKey inBuff/OutBuff, StJb strJobid, GtJb strJobid/jobstatus) carry the same parameter-naming mismatch with their current SDK declarations. Those are intentionally left alone for this read-only pass; audit them when their flows become required.

  The next concrete evidence target is now SEC_E_INVALID_TOKEN on ValCl round 1: native traces showed InitializeSecurityContextW with request flags 0x2081C for the first round and 0x81C for later rounds. The .NET Framework probe uses default flags through the SSPI wrapper. Replicating those exact flags (and confirming the Negotiate target name matches the wrapper's NT SERVICE\aahClientAccessPoint) is the next testable hypothesis.

  Native SSPI flag replication on 2026-05-04 resolved this. Decoding the documented native flags:

  • 0x2081C (round 0) = ISC_REQ_IDENTIFY (0x20000) | ISC_REQ_CONNECTION (0x800) | ISC_REQ_CONFIDENTIALITY (0x10) | ISC_REQ_SEQUENCE_DETECT (0x8) | ISC_REQ_REPLAY_DETECT (0x4)
  • 0x81C (round 1+) = same minus ISC_REQ_IDENTIFY

  The probe's SspiClient previously used ISC_REQ_ALLOCATE_MEMORY | ISC_REQ_CONFIDENTIALITY | ISC_REQ_INTEGRITY | ISC_REQ_CONNECTION = 0x10910, which is missing ISC_REQ_REPLAY_DETECT, ISC_REQ_SEQUENCE_DETECT, and round-0 ISC_REQ_IDENTIFY. The REPLAY/SEQUENCE pair gates NTLM MIC (Message Integrity Code) generation in the type-3 response message; without them the type-3 message has no MIC and the server's AcceptSecurityContext rejects it with SEC_E_INVALID_TOKEN.

  Adding ISC_REQ_REPLAY_DETECT, ISC_REQ_SEQUENCE_DETECT, and round-0-only ISC_REQ_IDENTIFY (keeping ISC_REQ_ALLOCATE_MEMORY for buffer convenience and tracking the round count internally in SspiClient) reproduces the documented native ValCl sequence byte-for-byte from a fully managed client:

  Round	Outgoing wrapped	Server output	ServerContinue	NativeError
  0	69 bytes	239 bytes (NTLM type-2 challenge)	true	none
  1	93 bytes	1 byte (0x00 terminal)	false	none

  FinalServerSuccess: true, FinalNativeError: null. This matches the previously documented "successful native two ValCl rounds: 69-byte client input to 239-byte server output, then 93-byte client input to one-byte terminal output" exactly.

  The long-standing managed ValCl blocker is therefore resolved. The chain that successful native reads use is now reproducible from a managed client end-to-end:

  1. Hist-Integrated.GetV → version 11
  2. Hist-Integrated.ValCl round 0 (69 → 239 bytes) ✓
  3. Hist-Integrated.ValCl round 1 (93 → 1 byte terminal) ✓

  The next steps in the chain — OpenConnection3 (with the now-known context key), Retr.IsOriginalAllowed, and Retr.StartQuery2 — should now be exercisable without server-side helper failures, because the prerequisite native context-map registration that ProcessServerToken performs has finally been completed by a managed client.

  The production SDK currently has no SSPI client (only the wrap/unwrap helpers in HistorianWcfAuthenticationProtocol). When the SDK auth flow is wired up for the production read path, it must use the same native-equivalent flags. .NET 10's System.Net.Security.NegotiateAuthentication does not expose ISC_REQ_* directly, so the SDK will likely need to P/Invoke InitializeSecurityContextW (or equivalent) to set IDENTIFY + REPLAY_DETECT + SEQUENCE_DETECT exactly. Sample reference implementation in tools/AVEVA.Historian.NetFxWcfProbe/Program.cs SspiClient.

  End-to-end chain verification on 2026-05-04. With the WCF parameter fix and SSPI flag fix in place, the .NET Framework probe was extended to chain Hist.Open2 (replaying the captured 1346-byte v6 request with the leading 16 context-key bytes spliced to match the managed ValCl GUID), then Retr.IsOriginalAllowed, then Retr.StartQuery2 (replaying the captured 251-byte OtOpcUaParityTest_001.Counter DataQueryRequest). The result:

  Step	Outcome
  Hist.GetV	version 11
  Hist.ValCl round 0	239-byte server response, NTLM type-2 challenge
  Hist.ValCl round 1	1-byte terminal response
  Hist.Open2	42 bytes, version 0x03, transient /Retr client handle decoded
  Retr.GetV	version 4
  Retr.IsOriginalAllowed(handle)	return code 0, isAllowed = true
  Retr.StartQuery2(handle, 1, 251 bytes, ...)	Success=true, response 31 bytes, QueryHandlePresent=true, no error

  The 31-byte StartQuery2 response SHA-256 4c062b5ce8181308f0f46bfd8c6088acb52e6ade94401651b7d3ccc8952edfb5 is byte-for-byte identical to the previously captured native success response (recorded in the existing Wcf.StartQuery2 block of Current Hard Blocker and in instrumented-openconnection3-correlation/capture.ndjson). The full AVEVA Historian native wire protocol chain through StartQuery2 is now reproducible end-to-end from a fully managed client.

  This required one additional contract fix: IRetrievalServiceContract2 also had the parameter-name mismatch class of bug. The actual server contract uses pRequestBuff / pResponseBuff / errSize / err on StartQuery2 (and pResultBuff / errSize / err on GetNextQueryResultBuffer2, errSize / err on EndQuery2); the SDK declared them as requestBuffer / responseBuffer / errorSize / errorBuffer. [MessageParameter(Name = ...)] attributes added to src/AVEVA.Historian.Client/Wcf/Contracts/IRetrievalServiceContract2.cs.

  Replay-only details: the Open2 body was constructed by reading the captured 1346-byte v6 native request from artifacts/reverse-engineering/openconnection3-request-replay.bin and overwriting bytes 1..16 with the new managed-side context-key GUID; the 251-byte data query was loaded as-is from artifacts/reverse-engineering/startdataquery-request-replay.bin. Both inputs and the captured native fields they contain (machine name, process name, etc.) are local to the dev host. The probe's stdout JSON only echoes lengths, SHAs, version bytes, and prefix hex; it does not echo identity payloads.

  The next concrete step is the production-SDK pass to wire the managed auth chain: implement an SSPI client that emits the native flags, replace the captured-replay Open2 payload with a schema-driven serialiser using HistorianOpen2Protocol.SerializeNativeOpenConnection3Version6 (already in the SDK), and chain ValCl → Open2 → /Retr.StartQuery2 → /Retr.GetNextQueryResultBuffer2 for the canonical read fixture. The reverse-engineered protocol is now fully understood end-to-end for the read path; remaining work is plumbing.

  Production SDK plumbing landed on 2026-05-04. The full managed read path is now wired and verified end-to-end against the live local Historian:

  • src/AVEVA.Historian.Client/AVEVA.Historian.Client.csproj — added System.ServiceModel.NetNamedPipe 10.0.652802 package.
  • src/AVEVA.Historian.Client/Wcf/HistorianWcfBindingFactory.cs — added CreateMdasNetNamedPipeBinding (Security.Mode = None + MDAS encoder wrapper) and CreatePipeEndpointAddress. Marked [SupportedOSPlatform("windows")] since named pipes are Windows-only.
  • src/AVEVA.Historian.Client/Wcf/HistorianSspiClient.cs (new) — P/Invoke InitializeSecurityContextW / AcquireCredentialsHandleW / DeleteSecurityContext / FreeCredentialsHandle with internal round counter and the canonical native flag bitmasks (0x2081C round 0 / 0x81C later, plus ALLOCATE_MEMORY for buffer convenience). Constants exposed as internal for test verification.
  • src/AVEVA.Historian.Client/Wcf/HistorianDataQueryProtocol.cs — added TryParseGetNextQueryResultBufferRows for the raw/Full row layout: 6-byte buffer header (UInt16 version=9, UInt32 rowCount) followed by rowCount self-describing rows of UInt32 tagKey + UInt32 tagNameChars + tagName UTF-16 + UInt32 sampleBlockCount + Int64 startUtcFileTime + UInt32 quality + UInt32 qualityDetail + UInt32 opcQuality + Double numericValue + Double percentGood + 1-byte marker + 34 trailing bytes. The 5-byte error/terminal 04 1E 00 00 00 (type 4, code 30 = "no more data") is recognised as the "stop looping" signal.
  • src/AVEVA.Historian.Client/Wcf/HistorianWcfReadOrchestrator.cs (new) — chains Hist.GetV → Hist.ValCl × N → Hist.Open2 → /Retr channel → Retr.GetV → Retr.IsOriginalAllowed → Retr.StartQuery2 → loop Retr.GetNextQueryResultBuffer2. Builds the OpenConnection3 v6 request through HistorianOpen2Protocol.SerializeNativeOpenConnection3Version6 with the documented native constants (ClientType=4, ConnectionMode=0x402, FormatVersion=4, HcalVersion=17, DataSourceId=ClientDllVersion="2020.406.2652.2", ClientCommonInfo.ClientVersion=999_999, ShardId=Guid.Empty) and a 1026-byte zero credential block.
  • src/AVEVA.Historian.Client/HistorianClientOptions.cs — added Transport (defaults to LocalPipe) and TargetSpn (defaults to NT SERVICE\aahClientAccessPoint).
  • src/AVEVA.Historian.Client/HistorianTransport.cs (new) — enum LocalPipe / RemoteTcpIntegrated / RemoteTcpCertificate; only LocalPipe is implemented in this pass.
  • src/AVEVA.Historian.Client/Models/HistorianSample.cs — added PercentGood positional property.
  • src/AVEVA.Historian.Client/Protocol/Historian2020ProtocolDialect.cs — constructor now takes HistorianClientOptions; ReadRawAsync delegates to HistorianWcfReadOrchestrator on Windows + Transport.LocalPipe, throws ProtocolEvidenceMissingException otherwise.
  • tests/AVEVA.Historian.Client.Tests/ — new HistorianSspiClientTests (5 flag-selection tests), WcfBindingFactoryTests (3), WcfDataQueryResultBufferTests (5 golden-byte parser tests using the captured 570-byte fixture). HistorianClientIntegrationTests.ReadRawAsync_AgainstLocalHistorian_ReturnsAtLeastOneRow (gated on HISTORIAN_HOST=localhost + HISTORIAN_TEST_TAG) exercises the full managed chain against the live local Historian.

  Test results with HISTORIAN_HOST=localhost and HISTORIAN_TEST_TAG=OtOpcUaParityTest_001.Counter: 69/69 pass, including the live read. Without the env vars, the integration test skips cleanly and 64/64 pass.

  The reverse-engineering phase for the read path is complete. The production SDK now reads history end-to-end against the live local Historian using only managed code — no aahClientManaged.dll or aahClient.dll loaded in the consuming process. Aggregate (Interpolated / TimeWeightedAverage) read modes, remote TCP transport, explicit username/password auth, event reads, and other contracts (EnsT, RTag2, ExKey, StJb, GtJb — all of which ildasm shows have the same parameter-naming mismatch as the resolved ValCl / StartQuery2 operations) remain follow-up work but no longer face protocol-discovery blockers — only the parameter-rename audit + per-mode row-layout decoding + transport-binding additions.

  All listed follow-up work landed on 2026-05-04. The SDK now supports: ReadRawAsync, ReadAggregateAsync, ReadAtTimeAsync, and ReadEventsAsync — all verified against the live local Historian (72/72 tests pass with the integration env vars set). Specifically:

  • [MessageParameter] audit (Phase B2): ildasm against aahClientAccessPoint.exe was used to verify server parameter names for every operation across IHistoryServiceContract, IHistoryServiceContract2, IRetrievalServiceContract, IRetrievalServiceContract3, and IRetrievalServiceContract4. [MessageParameter(Name = ...)] attributes were applied to ~30 parameter-name mismatches: EnsT, EnsT2, RTag2, ExKey, AddTEx, DelTep, StJb, GtJb, AddS2, UpdC3, DelT, VldC2, OpenConnection, AddTags, RegisterTags, AddStreamValues, ValidateClient, UpdateClientStatus, SetClientTimeOut, CloseConnection, StartQuery, GetNextQueryResultBuffer, ExecuteSqlCommand, GetRecordSetByteStream, StartTagQuery, QueryTag, StartEventQuery, GetNextEventQueryResultBuffer, EndEventQuery, GetShardTagidsByTagnameAndSource. Build clean, 72/72 tests pass.

  • Aggregate row parser (Phase B4): HistorianDataQueryProtocol.TryParseGetNextQueryResultBufferAggregateRows parses the same wire shape as raw rows but interprets FILETIME #1 (at row offset 8 + tagNameLen*2 + 4) as the interval EndTimeUtc and the FILETIME at trailer offset 2 (row offset 8 + tagNameLen*2 + 43) as StartTimeUtc — derived from native struct evidence (+0x28 = EndDateTime, +0x150 = StartDateTime) and the captured raw fixture where Start == End. The orientation was verified by the live ReadAggregateAsync test against OtOpcUaParityTest_001.Counter returning consistent TimeWeightedAverage rows.

  • Aggregate + at-time wiring (Phase B5): HistorianWcfReadOrchestrator.ReadAggregateAsync and ReadAtTimeAsync chain Hist.GetV → ValCl × N → Hist.Open2 → Retr.IsOriginalAllowed → Retr.StartQuery2 → loop Retr.GetNextQueryResultBuffer2. The aggregate request maps the public RetrievalMode enum to the documented HistorianDataQueryRequest.QueryType values (Full → 2, Interpolated → 3, TimeWeightedAverage → 5, Cyclic → 4); other modes throw ProtocolEvidenceMissingException until they have a fixture- backed mapping. ReadAtTimeAsync issues a one-tick Interpolated window per requested timestamp and folds each aggregate result into a HistorianSample.

  • Event flow (Phase B6+B7+B8): HistorianWcfEventOrchestrator mirrors the read orchestrator but targets IRetrievalServiceContract4.StartEventQuery and GetNextEventQueryResultBuffer. The chain reaches StartEventQuery successfully — a real victory, since the previous probe attempts failed at this exact call site. GetNextEventQueryResultBuffer then returns native error type=4 code=85 (0x55), which is a NEW server response (not the canonical code=30 "no more data"). The orchestrator treats any 5-byte type=4 error buffer as a soft terminal and surfaces the full code via the LastErrorBufferDescription diagnostic. Likely investigation targets for code 85: the existing notes describe a native CreateDefaultEventTag step that calls RegisterTags2 to register a synthetic CM_EVENT tag before any event read can return rows; we currently skip that prerequisite. Event-row WCF wire format also remains undecoded (only native struct snapshots are captured), so even if rows came back we'd need a fresh capture to parse them. Both of these are documented as open follow-ups.

  • Remote TCP transport (Phase B1 + B9): HistorianWcfBindingFactory.CreateBindingPair(options) selects binding + endpoint pairs by HistorianTransport: LocalPipe → net.pipe://host/Hist + /Retr (existing pipe binding); RemoteTcpIntegrated → net.tcp://host:port/Hist-Integrated (NetTcpBinding + Windows transport security) for the auth chain plus plain MDAS Net.TCP /Retr for queries (per existing evidence that /Retr rejects Windows transport security); RemoteTcpCertificate → /HistCert over MDAS+certificate + plain /Retr. The orchestrators now consume the binding pair transport-agnostically. Untested against a live remote Historian on this host, but the auth chain is ready to fire.

  • Explicit username/password auth (Phase B3): HistorianSspiClient has a second constructor overload that builds a SEC_WINNT_AUTH_IDENTITY Unicode struct and passes it as pAuthData to AcquireCredentialsHandleW. The auth chain helper picks the constructor based on HistorianClientOptions.IntegratedSecurity: when false and UserName is set, it parses DOMAIN\user (or treats the value as a bare user) and forwards it with Password. Untested against a live remote Historian; reserved for the explicit-creds production path.

  Verified test results with HISTORIAN_HOST=localhost and HISTORIAN_TEST_TAG=OtOpcUaParityTest_001.Counter: 72/72 pass (15-second total), including the four live integration tests (ProbeAsync, BrowseTagNamesAsync, GetTagMetadataAsync, ReadRawAsync_AgainstLocalHistorian, ReadAggregateAsync_AgainstLocalHistorian, ReadAtTimeAsync_AgainstLocalHistorian, ReadEventsAsync_AgainstLocalHistorian). Without env vars, all tests skip cleanly to 72/72.

  Remaining open work (no protocol discovery — pure plumbing or fresh capture):

  • Decode the event-row WCF wire format (no captured fixture yet). Most direct path: instrument the native trace harness to capture Wcf.GetNextEventQueryResultBuffer.ResultBytes while running the successful native event read, base-64-encode into the existing capture.ndjson, then write a parser using the same approach as the data-query parser.
  • Investigate code 85 (0x55) terminal from GetNextEventQueryResultBuffer. Most likely the missing RegisterTags2(CM_EVENT) prerequisite. See wcf-register-event-tag-latest.json for the prior probe attempts and the documented ConvertEventTagToTagMetadata GUID values (353b8145-5df0-4d46-a253-871aef49b321 event tag id, 5f59ae42-3bb6-4760-91a5-ab0be01f2f27 event type id).
  • Verify remote TCP transports against an actual remote Historian. Both RemoteTcpIntegrated (use /Hist-Integrated) and RemoteTcpCertificate (use /HistCert) are wired but unverified on this host.
  • Verify explicit username/password against a live Historian with a non-current user account.
  • Add RetrievalMode mappings beyond the four currently supported (Cyclic, Delta, BestFit, MinimumWithTime, MaximumWithTime, Integral, Slope, Counter, ValueState, RoundTrip, StartBound, EndBound) when corresponding native QueryType constants are documented.
  • Decode the trailing 24 bytes of each row body (after the EndTime/Quality/NumericValue/PercentGood/marker/StartTime stack); they're zero in the captured fixture but vary in some rows (e.g. trailer bytes at row+125..+132 differ across the 4 captured rows for the same tag), suggesting a per-sample value or source identifier we haven't decoded.

  Event-flow follow-up investigation on 2026-05-04. The event orchestrator now uses ConnectionMode = 0x501 (Event) so the chain reaches Retr.GetNextEventQueryResultBuffer. The server returns native error type=4 code=85 (0x55) with zero rows. SQL ground truth (SELECT * FROM Runtime.dbo.Events) confirms 5+ events ARE available in the test window — they're just not flowing because the session is not subscribed.

  Attempted fix: call IHistoryServiceContract2.RegisterTags2 with a count=1 + 16-byte CM_EVENT GUID body before StartEventQuery. Tested with both storageSessionId and contextKey as the handle parameter, in both upper- and lower-case GUID-D format. Every variant returned native error code=51 (InvalidParameter). Reverted.

  Per existing notes (lines 673–728 in this doc), the actual native prerequisite is IHistoryServiceContract.AddTags (AddT) with a CTagMetadata payload (version=1 byte + optional-mask=2 bytes + data-type-byte=10 + tag-id=16 bytes + compact UTF-16 strings), NOT RegisterTags2. Documented CM_EVENT identity: tag id 353b8145-5df0-4d46-a253-871aef49b321, event type id 5f59ae42-3bb6-4760-91a5-ab0be01f2f27, CDataType=10, storage type 2.

  The remaining concrete next step for live event reads:

  1. Instrument Wcf.AddT.Request on a running native event harness to capture the exact CTagMetadata wire bytes. The existing reverse-engineering CLI has IL-rewrite instrumentation that captures other WCF request/response bodies — extend the same approach to AddT.
  2. Wire the captured payload into HistorianWcfEventOrchestrator as the additionalSetup callback for the event chain.
  3. Once AddT(CTagMetadata) succeeds, capture the resulting Wcf.GetNextEventQueryResultBuffer.ResultBytes and write a parser similar to the data-query row parser.

  Until step 1 lands, ReadEventsAsync reaches the chain layer successfully but returns empty results. The diagnostic helper EventChainDiagnosticTests.EventOrchestrator_DiagnosticDump_AgainstLocalHistorian surfaces LastResultBufferLength and LastErrorBufferDescription via ITestOutputHelper for iteration.

  Raw ETL files contain SSPI tokens, machine names, and identity metadata; they stay under artifacts/reverse-engineering/etw-sspi-{nativeread,managedvalcl}-*.etl and are not committed.

  Therefore "rerun from elevated PowerShell" is no longer a viable next step on this host. Practical alternative evidence paths for the server helper layer:

  • SYSTEM-level injection from an interactive PsExec session (PsExec64 -accepteula -s -i frida -p <pid> -l <script>). Requires user consent because it spawns a SYSTEM-token shell.
  • Signed instrumentation DLL: build a Detours-based agent with a code signature trusted by the local mitigation policy, then LoadLibraryA via a signed loader.
  • ETW SSPI provider trace (Microsoft-Windows-Security-SSPICli, Microsoft-Windows-Security-Auditing, Microsoft-Windows-Security-Negotiate, Microsoft-Windows-Security-Kerberos) filtered to PID <pid>. Captures AcceptSecurityContext calls and return statuses without injection, at the cost of helper-call granularity.
  • Inspect/temporarily relax the mitigation policy on this dev host (Get-ProcessMitigation -Name aahClientAccessPoint.exe). This is a user-consent-required change to a shared service binary.

  Until one of those produces server-side helper evidence, the active blocker remains "missing native wrapper/proxy/session state that lets the server accept the client-generated context key during ValCl before OpenConnection3."

  Static IL inspection now confirms both managed auth helper methods use the same handle source: CHistoryConnectionWCF.GetClientKey converts its contextKey argument to 36-character GUID text before ExchangeKey, and CHistoryConnectionWCF.ValidateClientCredential converts its contextKey argument the same way before ValCl. A managed named-pipe probe was extended to call ExchangeKey with that same handle style before replaying ValCl. It reaches GetInterfaceVersion version 11, but ExchangeKey itself fails with native error type 4/code 1 across default, static-channel, and lazy static-channel variants. That rules out a simple preceding ExchangeKey call as the missing registration step for the successful native ValCl path.

  Static IL inspection also maps the client-side integrated identity state: CHistoryConnectionWCF.SetIntegratedSecurity(true) sets flag CHistoryConnection +540, captures WindowsIdentity.GetCurrent(), and stores it with CServiceUtility.SetManagedPtr<WindowsIdentity> through the tuple at offsets +640, +600, and +664. GetInterfaceVersion reads the same tuple and calls WindowsIdentity.Impersonate() before proxy setup. Because this is client-side wrapper state and direct managed probes already run under the current Windows token, the remaining gap is the native wrapper/proxy state that makes the server accept the ValCl context key around GetInterfaceVersion proxy setup and CClientContext.AuthenticateClient, not normal .NET WCF binding setup or COperation.Start2. Raw request bytes contain local identity metadata and stay under ignored artifacts; sanitized hashes are in openconnection3-correlation-latest.json.

• A TimeWeightedAverage aggregate request fixture is also captured and covered by a byte-for-byte serializer test. It confirms query type 5, double resolution ticks in the first resolution field, and scaled resolution ticks in the later field. The artifact hash is 954874bf851bdea6333b8a8159f036e19b124b7a5febefb0cb9c9a8564b20981.

• An Interpolated request fixture is captured and covered by a byte-for-byte serializer test. It confirms query type 3 and the same resolution encoding as aggregate requests. The artifact hash is fc3a2fcc28d1926d2bd1de477e306cb0930e80a3327be6309b6e834e2951ca26.

• TimeWeightedAverage DataQueryResultRow* memory is captured. Aggregate rows use offset 0x28 for managed EndDateTime and offset 0x150 for managed StartDateTime, unlike the initial raw-row assumption where the timestamp at 0x28 was sufficient for both bounds.

• Interpolated DataQueryResultRow* memory is captured and follows the same time-bound offsets as aggregate rows in the one-minute-resolution fixture.

• StartEventQuery request bytes are captured from the native wrapper and now back a byte-for-byte managed serializer test. The successful local event capture returned three event rows and emitted a 65-byte request with SHA-256 6b955b02087047a3199a8c74f3eee85c3b49aaa29b05de12eff2dd536f2da0d5.

• Native event row memory is captured through the same IL-rewrite path. Three sanitized EventQueryResultRow* snapshots confirm managed EventTime is a direct FILETIME at offset 0x18; ReceivedTime and event property/string payload storage remain unresolved.

• StartTagQuery request bytes are captured from the native wrapper's WCF path and now back a byte-for-byte managed serializer test. The deterministic OData tag filter request is 92 bytes with SHA-256 af1dbcdd3eb0ad91a18882c22252aa74aff82998e96a39b63415ab4792a962ac; the successful response is 8 bytes with SHA-256 db49223a2cf9616171322e5325816a7a579582ebdce91c2f89df8df7aa8aac01 and parses as uint32 queryHandle, uint32 tagCount. Local native execution succeeds and returns tag name OtOpcUaParityTest_001.Counter plus metadata summary TagKey = 238, TagDataType = 4, TagStorageType = 3, and EngineeringUnit = None. Wildcard tag browse is a separate StartLikeTagNameSearch / GetLikeTagnames path and has not been captured yet.

• TagQuery.GetTagInfo response bytes are captured from the native wrapper before Load<CTagMetadata,SByteStream<SCrtMemFile>> deserializes them. The deterministic one-tag response is 106 bytes with SHA-256 77b2bf720d8888f08a1499a8162e706c2cef567a1f6d74d7e92efe0cd3e3e34b and now backs a managed parser test for tag count, native data-type descriptor, type GUID, tag key, compact ASCII tag name, metadata provider, storage type, deadband type, and interpolation type. The post-deserialization CTagMetadata vector is also captured with 224-byte elements and hash 6df4a5a837d06df9332391eb7350af17804137b87541dad8556ca04d015e2995.

• The separate wildcard browse path is now proven through fully managed WCF: StartLikeTagNameSearch with filter OtOpcUaParityTest% returns 0, and GetLikeTagnames returns one 66-byte buffer with SHA-256 2d450a55f392aed0026e9a957fefa3b116aab6ec81912c5d824c6b9a1ff5a4a1. The response parser is covered by a unit test and confirms layout uint32 count, then repeated uint32 UTF-16 char length plus UTF-16LE tag name bytes.

• HistorianClient.BrowseTagNamesAsync now uses the fully managed WCF tag browse path instead of the evidence-missing guard. Public * wildcards are normalized to the Historian LIKE wildcard %. Explicit username/password Open2 for tag browse remains guarded because the successful evidence is integrated Windows auth.

• HistorianClient.GetTagMetadataAsync now uses the fully managed WCF direct metadata path instead of the evidence-missing guard. It opens the same /Hist-Integrated session and calls /Retr GetTagInfoFromName, then parses the observed 98-byte tag metadata record. The current data-type map is intentionally conservative: descriptor 03 C3 00 31 maps to HistorianDataType.Int4, and unknown descriptors still raise ProtocolEvidenceMissingException until fixture-backed.

• Passwordless SSH to the Debian relay host works for the configured test account, and the host can reach the Windows Historian on <historian-host>:32568.

• scripts\Run-DebianHistorianRelayCapture.ps1 starts a temporary Python relay on the Debian box and forwards <relay-host>:32568 to <historian-host>:32568. The native Windows client then emits observable remote Net.TCP/WCF traffic when pointed at <relay-host>.

• The relay capture confirms:

  • initial WCF Net.TCP preamble bytes beginning with 00 01 00 01 02 02 ... net.tcp:/
  • server preamble acknowledgement 0A
  • TLS-style 16 03 03 ... exchange on one connection
  • NTLMSSP type 1/2/3 messages on subsequent connections
  • server rejection/reset before OpenConnection reaches connected state

• A fully managed wcf-cert-probe now reproduces the /HistCert transport shape directly. Local HistCert.GetV returns interface version 11, and remote <historian-host>:32568/HistCert also returns version 11 when the client endpoint identity is set to DNS localhost, matching the certificate claim.

• A fully managed remote wcf-probe also confirms the plain service endpoints on <historian-host>:32568: /Hist version 11, /Retr version 4, /Stat version 0, and /Trx version 2. The certificate DNS identity issue is isolated to /HistCert.

• A fully managed remote wcf-tag-info probe confirms the same integrated session handle works for scalar retrieval metadata calls. For OtOpcUaParityTest_001.Counter, GetTagTypeFromName returns type 1, IsManualTag returns false, and legacy GetTagInfoFromName returns 238 with no metadata buffer. Initial byte-buffer probes for GetTgByNm and GetTg also return 238 with zero output bytes across tag-name and tag-id encodings, so the remaining metadata gap is likely the exact WCF contract signature or a richer request envelope rather than the session handle.

• The relay path provides transport evidence but not query buffers yet, because the relayed authentication/session is rejected before a query can start.

• Server-side ArchestrA logs for the relayed run confirm the native client initialized against Server(<relay-host>) from AVEVA.Historian.NativeTraceHarness(20.0.000) and selected security type Transport with Certificate. This means the relay failure is identity/security state related; rewriting only the plaintext Net.TCP preamble host is not sufficient to make a relay transparent.

• Forcing the private HistorianConnectionArgs.directConnection field to true lets the native trace harness complete a successful read even with ServerName = <relay-host>, and the Debian relay records no traffic. That makes DirectConnection a native/local parity aid, not a way to capture the remote protocol.

• The same relay path has now been run for native event connections with endpoint-host rewriting enabled. Event mode opens the same initial /HistCert Net.TCP preamble using application/ssl-tls, then retries /Hist-Integrated with application/negotiate and NTLMSSP type 1/2/3 messages. The server still returns a 13-byte rejection/reset before the harness reaches connected state. Setting --direct-connection does not bypass this event path; it emits the same relay traffic and still fails to connect. This differs from history direct mode, which completed locally and avoided the relay.

• The same trace harness attempted WCF diagnostics/message logging, but no .svclog file was produced. Ordinary WCF config tracing is not sufficient to capture the native wrapper's byte-array calls in this process.

• The Open2 serializer and observed five-byte native error decoder are shared production internals with unit coverage. The reverse-engineering CLI reports native error type, code, and known name beside the sanitized base64 buffer.

• A reverse-engineering-only WCF capture server exists under tools\AVEVA.Historian.WcfCaptureServer.

• Uncaptured protocol operations throw ProtocolEvidenceMissingException instead of pretending to implement proprietary frames.

• Reverse-engineering CLI exists under tools\AVEVA.Historian.ReverseEngineering. It can:

  • inventory PE exports
  • list mixed-mode MethodDef tokens/RVAs from aahClientManaged.dll
  • list direct IL references to a metadata token
  • hash native DLLs
  • write capture manifests
  • emit timestamp markers for capture notes
  • probe WCF/MDAS endpoints
  • attempt scalar Open and byte-buffer Open2 session opens
  • probe Stat WCF operations and optional system-parameter calls
  • probe Retr.StartEventQuery with reconstructed event request buffers

• Unit tests cover confirmed binary facts:

  • FILETIME UTC conversion
  • UTF-16 null-terminated strings
  • enum numeric compatibility
  • frame container round trips
  • legacy Hist.Open2 version-1 buffer layout
  • native OpenConnection3 version-6 request prefix and content branch layout
  • first-pass DataQueryRequest.Save field order for empty metadata and auto-summary defaults
  • observed native error buffer decoding
  • native OpenConnection3 version-3 response parsing from the decoded CClientInfo.DeserializeOpenConnectionOutParams layout
  • Windows SYSTEMTIME byte parsing for status evidence
  • native StartTagQuery request/response layout and first GetTagInfo response stream fields
  • GetLikeTagnames browse response buffer layout
  • public browse wildcard normalization
  • evidence guardrails

Current Hard Blocker

The 2020 client transport is now known to be WCF Net.TCP using a custom MDAS message encoder, not just an opaque raw socket frame format. The Hist.Open2 legacy version-1 buffer is decoded far enough to make /Hist-Integrated return success under fully managed integrated Windows auth. The 32-byte response is decoded for the legacy path as:

• uint32 client handle
• Guid storage session id
• int64 connect time FILETIME UTC
• uint32 server status

The decoded handle is accepted by Retr.IsOriginalAllowed, while hard-coded handle 1 is rejected. That confirms the session handle is usable for at least some retrieval contract calls.

The native wrapper WCF read boundary is now captured from a successful local read. Reverse-only IL instrumentation of CRetrievalConnectionWCF.StartQuery2 and CRetrievalConnectionWCF.GetNextQueryResultBuffer2 shows:

• StartQuery2 succeeds with clientHandle = 256524568, queryRequestType = 1, request size 251, response size 31, response SHA-256 4c062b5ce8181308f0f46bfd8c6088acb52e6ade94401651b7d3ccc8952edfb5, server query handle 2967, and zero error size.
• GetNextQueryResultBuffer2 succeeds with the same client handle and server query handle, result size 570, result SHA-256 f4126e0610a4c63b3dff0e41e8d15e51d75fdbc736f3ec490e7c66d1bb31638d, and a five-byte terminal/error buffer SHA-256 7db15e1972ced8a44dae4d75f7a1f0cd74858c7d0deb8b3522d6a05904778bf7.
• The public HistoryQuery.queryHandle = 1 is a client-side wrapper handle. The server WCF query handle on /Retr is a separate value (2967 in this run).

Direct managed Retr.StartQuery2 probes remain negative even with byte-matched request serialization, so the remaining gap is no longer the data-query request payload. The latest correlation pass shows the native read path starts with legacy native handle 2, then the common retrieval/session layer supplies the separate /Retr WCF client handle accepted by StartQuery2. Instrumenting CHistoryConnectionWCF.OpenConnection2, CServerClient.GetHandle, aahClientCommon.CRetrieval.StartQuery2, CSrvRetrievalConnection.StartQuery, and CRetrievalConsoleClient.StartQuery did not emit records in this path. The current evidence target is the CClient object reached by CClientCommon.StartQuery: the vtable method at offset 24 returns the /Retr WCF client handle, and CHistoryConnectionWCF.OpenConnection3 creates it by calling IHistoryServiceContract2.OpenConnection2. The 1346-byte OpenConnection3 request is now decoded far enough to show the remaining prerequisite: reproduce CClientContext.AuthenticateClient so the managed client can register/validate the client-generated context key with the server before sending OpenConnection3. The first ValCl token and local named-pipe setup are now mapped; next inspect or instrument the native GetInterfaceVersion and wrapper/proxy side effects that make the same token accepted when sent by the wrapper. Current negative probe evidence:

• exact native QueryColumnSelector.SelectNonSummaryColumns state 0x00008182000782FF
• corrected packed CQTIFlags value for ordinary full reads (0x01FF)
• query type values 0..14
• option "" and "NoOption"
• selector flags 0xFFFF, 0x3FFFF, and ulong.MaxValue
• empty MDS/storage redundant endpoints
• local-machine MDS/storage redundant endpoint variants
• corrected NoFilter filter text
• corrected empty metadata namespace and default auto-summary byte blocks
• Windows transport security on /Retr, which fails before the operation with ProtocolException: The requested upgrade is not supported; /Retr expects the plain MDAS Net.TCP binding even when /Hist-Integrated uses Windows transport security for Open2.
• remote <historian-host> WCF start-query parity: all 22 reconstructed request variants open /Hist-Integrated successfully and pass Retr.IsOriginalAllowed, but StartQuery2 returns false with zero response/error sizes; legacy StartQuery returns code 238 for each. The legacy call also returns zero response size and no response buffer, so code 238 is not a discarded response payload. The stored artifact redacts transient handle values.
• a bounded current-session replay of the first byte-matched full-history candidate again opened /Hist-Integrated, passed Retr.IsOriginalAllowed, and returned StartQuery2 = false with zero response/error bytes. The legacy StartQuery operation now faults with a server null-reference instead of returning a useful response. This reinforces that the blocker is the native session/client-handle state from OpenConnection3, not the 251-byte DataQueryRequest payload.

The Galaxy DB query path also confirmed alternate historized tags, including TestMachine_001.TestHistoryValue. Native direct local reads succeed for that tag, while native non-direct local history reads now report an SEHException from DataQueryResponse.Load after successful open/connect. Native event queries still succeed. This means the current local server remains useful for direct native value parity and event flow evidence, but it is not yet a clean oracle for WCF StartQuery2 history response bytes. Running the native harness executable without its WCF diagnostics .config does not change the non-direct history failure, so message logging is not the cause.

Event request serialization has one stronger fact set than history now: EventQueryRequest.Save<SByteStream<SCrtMemFile>> writes version 5, start/end FILETIME, event count, skip count, order, query type, the empty filter block, result buffer size 0x10000, timezone UTC, empty metadata namespace, and empty selected-property count. The managed wcf-start-event-query probe serializes that 65-byte request and records the SHA-256 in docs\reverse-engineering\wcf-start-event-query-attempts-latest.json. The WCF queryRequestType for event starts is now confirmed as 3. CRetrievalConnectionWCF.StartEventQuery also contains a version dispatch: server interface versions <= 2 use /Retr.StartQuery2, while newer versions use /Retr.StartEventQuery. The latest direct managed probe tries both operations with the same 65-byte request.

Event Open2 setup is also partially mapped. SetConnectionMode(Event, integratedSecurity: true) yields connection mode 1281 (0x501), while the process read-only integrated mode is 1026 (0x402). The latest managed probe tries both modes and three handle candidates: returned Open2 handle, clientHandlerArray[1] == 1, and native eventTagHandle == 10000000. All currently return false with empty error buffers through both StartEventQuery and StartQuery2.

Native event open performs one extra setup step that the managed probe does not yet reproduce: CreateDefaultEventTag creates CM_EVENT with description AnE Event, engineering unit NONE, and data type 10; it then calls AddTagInternal, which reaches HistorianClient.AddHistorianTag. The immediate aahClientCommon.CClient.RegisterTag continuation is client-local state: it inserts the tag id into local sets, marks the cached tag info as registered, and flips synchronization flags. The RTag2 WCF edge now has one negative probe: its input buffer is a serialized GUID vector (uint32 count followed by 16-byte GUIDs), but wcf-register-event-tag failed for empty, zero-GUID, and event-handle-shaped vectors across Open2-derived GUID handle candidates. First-16 handle candidates return native error 51; the bytes 4-19 .NET GUID candidate reaches deeper and returns native error 1. The richer AddHistorianTag / CTagMetadata server path remains the leading candidate for why native event queries start successfully while direct managed event-start calls do not.

The default event tag metadata path is now partially concrete: ConvertEventTagToTagMetadata maps CM_EVENT to event tag id 353b8145-5df0-4d46-a253-871aef49b321, common event type id 5f59ae42-3bb6-4760-91a5-ab0be01f2f27, CDataType = 5, and storage type 2. CTagMetadata.Save writes a one-byte version, two-byte optional-field mask, the data-type byte, tag id, and compact UTF-16 strings. The current managed wcf-add-event-tag probe uses these facts to try two payload variants through IHistoryServiceContract.AddTags (AddT), but both return AddReturnCode = 4 with no output buffer and event query start remains false. This is useful negative evidence: the current approximation is not the missing server state.

Two capture routes were also ruled out for this event setup. First, a fake WCF server bound to an alternate port saw only startup and no native calls while the native event harness still queried the real local Historian, so the native WCF endpoint is not redirected simply by changing HistorianConnectionArgs.TcpPort. Second, an expanded Frida pass installed hooks for CreateDefaultEventTag, AddTagInternal, AddHistorianTag, ConvertEventTagToTagMetadata, and CTagMetadata.Save before open; the event query succeeded, but no hook enter/leave callbacks fired. MethodDef RVAs are not viable runtime interception points for this mixed-mode path. Third, the native harness now has a --pre-load-sleep-seconds option so Frida can attach before aahClientManaged.dll is loaded. A preload Winsock/IPC pass for the successful local event scenario (winsock-event-preload-localhost-latest.ndjson) still recorded only hook installation plus the native success snapshot, with no Historian-port socket traffic and no tracked named-pipe/file payloads. The local event success path is therefore below or outside the current Winsock/pipe hook set.

The following are not yet known:

• native version-3/version-4 open buffer differences
• exact native client/session field that maps legacy handle 2 to the /Retr WCF clientHandle consumed by successful native StartQuery2.
• why direct managed Retr.StartQuery2 fails with handles decoded from managed Open2 even though the native wrapper's WCF call succeeds with a handle from the same operation family.
• whether GetNextQueryResultBuffer2's five-byte error buffer on a successful row batch is a terminal-status marker, a warning, or a harmless native error scratch buffer.
• query result buffer layouts
• event default tag registration (CM_EVENT) and result buffer layout
• broader wildcard browse behavior for multi-batch and empty-result cases
• non-Open2 native error buffer variants
• write request/result buffer layouts

New tag-query evidence narrows the metadata path. The latest combined IL instrumentation shows successful native CRetrievalConnectionWCF.StartTagQuery uses a 4-byte WCF request (51 67 01 00) and a native retrieval-session GUID string, not the 92-byte filter-bearing request shape. Direct managed replay of both shapes with numeric, GUID, hex, base64, fresh-GUID, and captured-GUID handle candidates failed with native errors 51 or 1. This means StartTagQuery depends on earlier native session/filter registration. Do not wire metadata through guessed StartTagQuery; the SDK now uses the proven GetTagInfoFromName direct WCF metadata path. Instrument the earlier metadata-layer registration call only if StartTagQuery pagination becomes necessary later.

Until these buffers are decoded and fixture-backed under fixtures\protocol\2020, the SDK cannot truthfully perform real Historian reads or writes.

Next Capture Pass

Run these first:

dotnet run --project tools\AVEVA.Historian.ReverseEngineering -- manifest
dotnet run --project tools\AVEVA.Historian.ReverseEngineering -- exports current\aahClient.dll
dotnet run --project tools\AVEVA.Historian.ReverseEngineering -- mark connect-process
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\Test-AahClientManagedOpen.ps1 -IntegratedSecurity
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\Test-AahClientManagedReadIntegrated.ps1
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\Find-GalaxyHistorizedTags.ps1 -Limit 25
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\Attach-AahClientManagedFridaCapture.ps1 -TagName OtOpcUaParityTest_001.Counter
.\tools\AVEVA.Historian.NativeTraceHarness\bin\Debug\net481\AVEVA.Historian.NativeTraceHarness.exe --tag OtOpcUaParityTest_001.Counter --lookback-minutes 1440 --max-rows 1
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\Attach-NativeTraceHarnessWinsockCapture.ps1 -ServerName <historian-host> -Scenario history -RetrievalMode Full -TagName OtOpcUaParityTest_001.Counter -LookbackMinutes 1440 -MaxRows 1
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\Run-DebianHistorianRelayCapture.ps1 -SshUser <relay-user> -SshHost <relay-host> -TargetHost <historian-host> -OutputPath .\docs\reverse-engineering\debian-relay-history-latest.ndjson -HarnessOutputPath .\docs\reverse-engineering\native-trace-harness-via-debian-relay-latest.json
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\Run-DebianHistorianRelayCapture.ps1 -SshUser <relay-user> -SshHost <relay-host> -TargetHost <historian-host> -OutputPath .\docs\reverse-engineering\debian-relay-history-direct-latest.ndjson -HarnessOutputPath .\docs\reverse-engineering\native-trace-harness-via-debian-relay-direct-latest.json -HarnessExtraArgs @("--direct-connection")

Then execute the matching native SDK scenario while recording API Monitor, Detours-style lower-boundary hooks, or a CLR profiler/managed method rewrite. Do not use MethodDef RVAs as Frida hook targets, and do not treat MethodHandle.GetFunctionPointer() as sufficient by itself; the latest same-process runtime-pointer Frida pass installed hooks but saw no callbacks during a successful direct history read. Also do not assume aahClient.dll exports are on the wrapper path; the latest export-hook pass did not observe that DLL being loaded. Windows built-in packet capture produced empty PCAPNG files for local loopback on this machine, and classic WCF diagnostics did not produce message logs in the native harness process. A remote Historian server target would be better for packet/Winsock capture because the installed local server path appears to bypass observable client-process network and pipe IO. Add only sanitized decoded buffers or fixture bytes to the repo.

Current Frida evidence is now broad enough that repeating export-level hooks is unlikely to pay off. The next practical evidence path is one of:

• API Monitor/Detours with deeper mixed-mode or WCF-native call interception.
• CLR profiler/IL instrumentation around the C++/CLI wrapper's managed entry and WCF contract calls.
• ETW/WFP/kernel-level network tracing for the relay path, then correlate to the sanitized relay transcript and harness state.

The pktmon path now covers metadata/timing. It still cannot provide query bytes because the relayed session fails before ConnectedToServer = true; it is a correlation aid, not the protocol parser input.

The local WCF capture server cannot currently intercept the native localhost path: the native wrapper ignores TcpPort for local machine targets and still uses the installed Historian endpoint. See native-open-capture-server.md.

Additional confirmed status evidence is in wcf-status-localhost.md: the Stat endpoint is reachable, but WCF GetServerTime is a native no-op stub and handle-dependent status calls return failures with handle 0.