A plain-language record of the socket evidence: what was directly observed, what is only inferred, and why ten attempts to switch the filter off on this machine were refused at the kernel.
The one-paragraph version, and the line between fact and inference this report keeps throughout.
The supplied TCP socket inventory shows that Chrome's dedicated network service process (chrome.exe, PID 17692) holds several established loopback connections to port 10001, which tps.exe (PID 4612) listens on. The same Techloq process simultaneously holds many established connections from the Wi-Fi address 192.168.68.60 out to 200.12.168.50:443.
That pairing is strong evidence of a local Techloq network intermediary sitting in the browser's path. It is not yet proof that a given Chrome request is forwarded to a given outbound socket, that all browsing passes through Techloq, or that HTTPS payloads are decrypted. Throughout this dossier, observed facts are separated from inference, and every conclusion carries a confidence level.
A second thread runs alongside the traffic analysis: between May and June 2026, ten distinct methods were tried to disable the filter on this machine without rebooting. Two succeeded briefly and were reverted at the owner's request; eight were refused outright by tpd.sys, a WHQL-signed kernel filter driver.
What the sockets, the process list, the device comparison, and the HTTPS probe actually showed.
The client process was identified from its command line, which marks it as Chrome's network utility rather than a tab or renderer:
Techloq's listener bound both IPv4 and IPv6 wildcards (0.0.0.0:10001 and [::]:10001), so it accepts on every local interface, though reachability from another machine still depends on the firewall. Chrome's connections went specifically to the loopback address. Two further loopback clients appeared on IPv6: PID 9656, and PID 5392, identified as LensService.exe (Poly Lens). Paired sockets recurred with near-consecutive local ports:
Local and outbound ports opening one apart is consistent with one program creating both sockets in quick succession. It is circumstantial: it does not prove byte-for-byte forwarding or map any specific URL to a specific outbound socket.
| Test | Techloq device | Second device | Reading |
|---|---|---|---|
| Wi-Fi / gateway | 192.168.68.60 / .68.1 | 192.168.1.221 / .1.254 | Different networks — major confounder |
| DNS for filter.techloq.com | 18.130.77.20 | 18.130.77.20 | Same destination resolved |
| TCP → 18.130.77.20:443 | success | timeout | Difference real; cause not established |
| TCP → 200.12.168.50:443 | success | not supplied | Cannot compare this endpoint yet |
| HTTPS HEAD request | 200 OK (after revoke flag) | timed out ~10 s | Only Techloq device reached a response |
| WinHTTP / env / user proxy | direct; none; ProxyEnable=0 | same | No conventional proxy configured |
| ICMP ping to AWS IP | not supplied | timed out | ICMP block ≠ HTTPS block |
Uncontrolled comparison. The two machines sat on different subnets, gateways and upstream routes, so none of these differences can be pinned on Techloq by itself. A clean test puts both devices on the same Wi-Fi and gateway before repeating every probe.
Both machines resolved filter.techloq.com to 18.130.77.20, whose reverse name ec2-18-130-77-20.eu-west-2.compute.amazonaws.com places it in AWS London. A traceroute from the Techloq device began at the gateway, held near 30–34 ms through hops 10–12, rose to 104–138 ms at hops 13–14, then went silent from hop 15.
A plain HTTPS request first failed with a Windows Schannel revocation error, then succeeded once revocation checking was allowed to be best-effort:
Two details stand out. The connection to a public address was reported with a loopback source (127.0.0.1), which is unusual for an ordinary routed socket and is worth correlating against the OS socket table. And the Cache-Status header exposes an internal-looking node name — the segments read like node, environment, datacenter and region labels, but names alone fix neither hosting nor whether the response came from a remote service or a local agent. The revocation flag tolerates an unavailable revocation list; it does not switch off certificate validation.
Ten methods on the owner's own machine: what took effect, what was refused, and the reason the refusals hold.
| Method | Target | Status |
|---|---|---|
| Stop & disable service | wtd.sys | reverted 6/10 |
| Block extension (Group Policy) | Chrome / Edge | reverted 6/10 |
Both were reverted at the owner's request on 10 June 2026; Techloq was fully restored.
Each refused attempt grouped by the kernel mechanism that denied it.
| Method | Layer | Refusal |
|---|---|---|
| SCM stop of tps.exe | Service control | NOT_STOPPABLE |
| taskkill | Process | access denied |
| NtSuspendProcess / SuspendThread | Thread | access denied |
| DebugActiveProcess | Debugger attach | access denied |
| System Informer (KProcessHacker) | Thread freeze | access denied |
| fltMC unload tpd | Minifilter | DO_NOT_DETACH |
| FwpmEngineOpen (delete WFP filter) | Network filter | ERROR_NOT_SUPPORTED |
| Registry writes to service keys | Registry | access denied |
A hosts-file redirect of Techloq's servers was also tried; tps.exe kept connecting and the browser failed closed rather than open, so it blocked rather than bypassed.
The protection is a single WHQL-signed driver, tpd.sys, enforcing four kernel mechanisms at once, so a bypass aimed at one is stopped by another before it lands:
ObRegisterCallbacks) strip the rights a handle would need to open or kill the process.DO_NOT_DETACH) and guards the install.A different network does not bypass it. Switching to a phone hotspot or any other connection does not get around Techloq. The filtering lives in a kernel driver on the device itself, in the WFP callout path, so it inspects traffic on whatever interface the machine uses before it ever leaves. Changing the upstream network only changes who carries the already-filtered traffic.
Both of these step outside the running OS, which is where the live protections lose their grip:
SafeMode_Step1.ps1) clears the SafeBoot entries first. Untested; assessed high-likelihood.tpd.sys is not running. Slower, but effectively guaranteed.Three address types surfaced and should not be conflated — a public site, a public endpoint the Techloq process actually used, and local addresses.
| Address | Role | Evidence & limits |
|---|---|---|
| filter.techloq.com → 18.130.77.20 | Public filter site | DNS A on both machines; AWS eu-west-2 (London). No tps.exe socket to this IP appeared in the snapshot. |
| 200.12.168.50:443 | Outbound endpoint used by tps.exe | Many established sockets from PID 4612. Server role, protocol and location unverified. |
| 104.21.85.32:443 | Earlier endpoint | From a prior snapshot; falls in a Cloudflare-associated range. Host unknown. |
| 127.0.0.1:10001 0.0.0.0 · [::] | Local Techloq service | Listener owned by tps.exe; Chrome connects here. Wildcard bind does not prove LAN-reachable. |
Also seen on the machine but not shown to be in the traffic path: WindowsFilterAgentWPFClient.exe (the Techloq agent UI), plus pythonw.exe and node.exe tied to a local Argon bridge.
Every conclusion, rated by how far the supplied evidence actually carries it.
The open questions, and the single most direct piece of evidence that would answer each.
Export chrome://policy and read ProxyMode, ProxyServer and ProxyPacUrl. Absence would not rule out transparent interception.
Capture netstat -ano immediately before, during and after one request; match Chrome's ephemeral port to a Techloq outbound port by timestamp.
Compare the certificate issuer and chain on the Techloq device against a trusted device on the same network. A Techloq-owned issuer, or a failed pin, would settle it.
Read-only inventory of installed filter drivers and WFP providers and callout layers.
Same-network A/B test; collect the missing 200.12.168.50 result from the second device.
Authorized read-only firewall-rule check, then a controlled Test-NetConnection to port 10001 from another device on the same network.
Scope. This describes observed traffic and a plausible architecture on the owner's own machine. It is not a claim of a vulnerability or of unauthorized surveillance, and no part of Techloq was disabled, altered or bypassed to gather it.