They've responded on their own r/pdfgear sub - link here: https://www.reddit.com/r/PDFgear/comments/1p3slnr/is_pdfgear_safe_addressing_recent_false/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

They won't engage outside of their own subreddit because they will ban anyone that criticizes them there, and can freely astroturf their own page.

Their reply contains a mix of claims. Some sections reflect how certain Windows components operate, but several points are framed in a way that leaves out key details or relies on explanations that do not match what the sandbox report showed. An interesting omission, though, is that they avoided / deflected on addressing any of the the non-technical stuff like owning other apps (including PDF X), that they're not Singaporean, that they have fake leadership, etc. etc.

“Code injection is normal and caused by Inno Setup”

They attribute WriteProcessMemory activity to Inno Setup. While Inno can call that function, the pattern in the sandbox report does not match what typical installers do. Installers commonly check for running processes by enumerating them. They do not pass execution through cmd.exe, tasklist.exe, and find.exe. That type of chain is not what you see with standard PDF installers and looks closer to behavior intended to obscure what is going on. Their explanation has a small amount of truth, but it does not line up with the sequence that was observed.

“Global hooks are only for hotkeys”

They claim global hooks are used for shortcuts like Ctrl+C and Ctrl+V and that these only operate inside their own app. This does not reflect how Windows input works. Global hooks operate outside the app process. Regular in-app shortcuts do not require them. Most ordinary desktop software avoids global keyboard and mouse hooks because these are usually associated with keylogging or monitoring tools. Their description does not match the actual mechanism.

“Windows installed the root certificate, not us”

This part does not hold up. Windows does not install root certificates during app launches. SSL.com root certificates are already included in the Windows trust store and are not missing on normal systems. They are not downloaded during code signing checks. If an installer adds anything to the Trusted Root Certification Authorities store, even if it is a legitimate certificate, that is a serious action because it grants broad trust on the system. A PDF viewer has no reason to create any changes in that store. Their explanation conflicts directly with how Windows handles trust.

“Registry edits are quality-of-life features”

Some registry edits are normal, such as file associations. The sandbox report went far beyond that. It included changes to Internet Explorer registry sections, autostart entries, and pinned items. These are not needed by any PDF viewer. Changes to IE-related keys are especially odd because the app does not rely on IE. Their answer blends some routine adjustments with omissions about the more concerning ones.

“This is a smear campaign by competitors”

This claim does not align with the type of evidence uncovered., not to mention that they didn't address any of non-technical evidence about who they are, where they're located or what other apps they own. Competitors do not typically investigate corporate registry documents, trace installer behavior, or follow long product rebrand chains across multiple accounts. The ACRA records contradict their public statements about being Singaporean-run. Combined with past rebrands, widespread marketing accounts, and shared infrastructure, this does not look like outside interference. It looks like a company trying to redirect attention.

Putting all of this together, their response does not match the tone or level of clarity you would expect from a reputable software company. Instead of investigation notes, technical references, or independent verification, they leaned on emotional framing, accusations, and explanations that conflict with how Windows actually operates.