LogRAM

AI Security Review

Evidence context: threat category none; evidence quality moderate.

What the plugin does, and what access that requires

LogRAM opens multi-gigabyte log files in its own two-pane source/results window and runs an in-memory SIMD and multicore search over them, with UTF-8/GBK handling, regex and include/exclude queries, and result export. Reading log files from disk and running a search process are the job itself, not extras bolted around it. The package also ships the .NET 8 runtime so it runs without a separate install, and that is what fills it with Microsoft assemblies: System.Private.CoreLib.dll, System.Net.Sockets.dll, System.Net.Requests.dll, System.Private.Xml.Linq.dll, System.ObjectModel.dll and their siblings. Every critical-severity item in the results is the same rule, OBFUSCATION-supply_chain_binary, reported once per assembly at offset 0. That rule is firing on the redistributable runtime, which is metadata-dense and compressed by design. Nothing in the finding separates LogRAM's own code from the CLR it carries.

Credential access

No finding in the package targets a credential store. There is nothing against .env files, .ssh keys, .git/config, cloud credential files, or Notepad++'s own saved configuration. The System.Net.* assemblies present are the framework's HTTP and socket stack, which appears in every self-contained .NET build whether or not a line of plugin code calls it. A log viewer reading the log path a user selected is the whole filesystem story here, and the export feature explains the writes.

The network endpoint list

This is the weakest part of the evidence. The list holds entries like 3vf.mg, 9q.bv, 36v.hm, a0x905732ed.sa and 0system.drawing.graphics. None is a resolvable hostname; 0system.drawing.graphics is a namespace-qualified type name split on a dot. Strings such as acm.org, alumni.caltech.edu, asp.net and apis.in are dotted text lifted out of binary string tables. A four-character run like 9q.bv is not a registrable domain. The volume of these entries describes how much text sits in a .NET runtime folder, not where the plugin talks.

The strongest counterargument

A Notepad++ plugin is a native DLL, not sandboxed JavaScript, so any finding inside it deserves more weight than the same finding in a webview bundle, and a wall of critical-severity ratings reads as alarming. Both points hold in general and neither changes this case. The critical ratings all carry the same title and all sit on Microsoft's own runtime assemblies, and none of the scanner's malware family rules matched a file anywhere in the package. The low-severity code-quality hits are the pattern matches that fire on compiled code of any kind. What remains is a viewer that reads the logs you point it at.

Key Reasons

• All critical-severity findings are the single rule OBFUSCATION-supply_chain_binary at offset 0 on standard .NET 8 runtime assemblies (System.Private.CoreLib.dll, System.Net.Requests.dll, System.Net.Sockets.dll) bundled for self-containment
• Reported network endpoints are unresolvable string fragments carved from compiled binaries (3vf.mg, 9q.bv, 0system.drawing.graphics), not hostnames
• No malware family signature matched any file, and no finding touches .env, .ssh, .git/config or cloud credential paths
• Filesystem and process activity matches the stated purpose: a log viewer must read user-selected logs and run its own search engine

False Positive Considerations

• OBFUSCATION-supply_chain_binary rule firing on signed Microsoft .NET runtime redistributable DLLs
• IoC extractor treating dotted type names and binary string-table text (0system.drawing.graphics, asp.net, acm.org) as network endpoints
• Short character runs like 3vf.mg and 9q.bv misread as domains
• Low-severity code-quality matches on compiled native/.NET code with no malware rule backing them

Reviewed 2026-10-18; recommended action: suppress false positive; model confidence 90%.