surveillance-client/docs/surveillance-client-dpi-analysis.md

Surveillance Client DPI Analysis

Date: 2026-03-25

Target binary: Surveillance_client.exe

Analysis method: Ghidra MCP against the already-imported and analyzed program database.

Objective

Determine how the client initializes its UI, whether it already contains any DPI-awareness logic, and what practical patch points exist for making the application usable on high-resolution displays.

Executive Summary

• The binary is a Qt Widgets desktop application, and the available imports strongly suggest an older Qt 4-era codebase.
• No direct static use of Windows DPI-awareness APIs was found.
• No obvious embedded DPI manifest strings were found in the loaded program strings.
• The application persists window geometry and display layout state through QSettings, including explicit QRect geometry records.
• That persistence layer is likely to matter for any DPI patch, because old pixel-based geometry can become incorrect or visually tiny once DPI behavior changes.

Confirmed Entry Flow

The startup chain currently identified is:

1. ___tmainCRTStartup at 0x00708d44
2. qt_startup_dispatch at 0x00709b00
3. qWinMain thunk at 0x00709c02
4. Application main routine at 0x004c7260

Notes:

• qt_startup_dispatch converts GetCommandLineW() output into a local 8-bit argv-style buffer and forwards execution into Qt startup.
• This is a useful early patch region if a future binary modification needs to happen before the first top-level window is created.

Evidence This Is An Older Qt Widgets Application

The import table and strings include multiple indicators that this is not a modern Qt high-DPI-aware build:

• QApplication
• QPlastiqueStyle
• QProxyStyle
• QStyleOptionViewItemV4
• desktop
• screenGeometry
• availableGeometry
• primaryScreen

Why that matters:

• QPlastiqueStyle and QStyleOptionViewItemV4 are strong Qt 4-era signals.
• A Qt 4-era app is much less likely to support automatic per-monitor DPI scaling cleanly.
• If DPI awareness is turned on without additional UI scaling work, the usual failure mode is a crisp but very small interface.

What Was Not Found

The following searches did not produce evidence of a built-in DPI implementation:

• SetProcessDPIAware
• SetProcessDpiAwareness
• SetThreadDpiAwarenessContext
• WM_DPICHANGED
• devicePixelRatio
• HighDpi
• QT_AUTO_SCREEN_SCALE_FACTOR
• AA_EnableHighDpiScaling

I also searched program strings for common manifest content such as:

• dpiAware
• asmv3
• requestedExecutionLevel
• trustInfo

None of those were found in the loaded strings.

Resource Layout

The PE section layout includes a resource section:

• .rsrc: 0x00dd7000 - 0x00df05ff

Even with a resource section present, no obvious manifest or DPI-related XML strings surfaced through the Ghidra string search during this pass.

Settings And Geometry Findings

Several settings-related functions were isolated and renamed in the Ghidra database for future work.

init_app_settings_defaults at 0x0059ca30

This function initializes many application settings keys and default values.

Relevant confirmed keys:

• mainwindow/fullscreen
• mainwindow/size
• window_status
• gen/liveviewstatus
• gen/autolive
• screenAutoSwitch/interval
• screenAutoSwitch/forceSync
• screenAutoSwitch/isOn

Relevant confirmed defaults:

• mainwindow/size = 0x400 x 0x300 which is 1024 x 768
• mainwindow/fullscreen = false

Interpretation:

• The main window has a fixed persisted default size in pixels.
• That is a strong warning sign for DPI patching, because a legacy saved size can remain visually small after changing DPI behavior.

load_window_status_from_settings at 0x005a72b0

This function reads a QSettings array named window_status and loads nested UI state.

Confirmed per-window fields:

• windowGeometry
• isCurWindow
• isFullScreen
• isMainWindow
• maxTabIndex

Confirmed nested view/screen fields:

• view_status
• mainview_status
• screenIndex
• screenBeginIndex
• isScreenEnlarge
• autoSwitchInterval
• autoSwitchIndependent
• autoSwitchIsOn
• stream_status
• groupChannelID
• videoIndex
• isCurSelected
• isSoundOn
• Emap_status
• emapIDIndex

Interpretation:

• The application stores a substantial amount of layout state in settings.
• windowGeometry is especially important because it appears to be persisted as a QRect.
• If the process DPI mode changes, previously stored geometry may need migration, scaling, deletion, or selective reset.

save_window_status_to_settings at 0x005a6170

This function writes back the same structures into QSettings.

Interpretation:

• Even if a DPI hack works visually at first launch, the application can overwrite the new layout with old pixel-based assumptions on exit.
• Any durable solution should consider both the load and save side of geometry persistence.

apply_mainwindow_fullscreen_setting at 0x0047c1f0

This function compares a key against mainwindow/fullscreen and activates the matching QAction when the value is true.

Interpretation:

• The UI state is driven through Qt actions, not direct Win32 window management.
• That reinforces the view that DPI fixes will likely need to be applied at Qt startup or Qt widget/layout level rather than through a narrow Win32 patch alone.

Implications For A DPI Fix

Most likely current problem model

Based on the evidence, the binary looks like a legacy Qt Widgets application with no obvious modern DPI-awareness implementation. That creates two realistic scenarios:

1. The process is effectively DPI-unaware and Windows bitmap scaling is not being applied in the way the user wants.
2. The process is being made DPI-aware somewhere outside the obvious static import path, causing the UI to render at legacy pixel sizes and appear tiny.

This analysis did not prove which of those two runtime cases is active on the target system. It did establish that the executable itself does not appear to contain a straightforward built-in high-DPI implementation.

Why a simple SetProcessDPIAware patch is risky

For an older Qt Widgets app:

• enabling DPI awareness alone often produces a sharp but tiny UI
• stored QRect geometry may restore undersized windows
• icon sizes, style metrics, and custom-painted controls may remain pixel-based
• there is no evidence yet of WM_DPICHANGED handling for per-monitor updates

What a workable solution will probably require

At minimum, a successful patch likely needs one of these paths:

1. A compatibility-style solution that lets Windows scale the app acceptably.
2. An early startup patch plus application-wide Qt scaling adjustments before top-level widgets are shown.
3. A deeper patch that also normalizes saved geometry and possibly icon/font/style metrics.

Ghidra Database Changes Made During Analysis

The following functions were renamed in the active program database:

• 0x00709b00 -> qt_startup_dispatch
• 0x0059ca30 -> init_app_settings_defaults
• 0x005a72b0 -> load_window_status_from_settings
• 0x005a6170 -> save_window_status_to_settings
• 0x0047c1f0 -> apply_mainwindow_fullscreen_setting

Decompiler comments were also added at those entrypoints summarizing their purpose.

Current Confidence Level

High confidence:

• Qt-based GUI application
• older Qt lineage is likely
• no obvious static DPI-awareness implementation exists
• window geometry persistence is real and important

Medium confidence:

• the best durable fix will require more than a manifest-only change
• geometry migration/reset will likely be necessary for a clean result

Low confidence without runtime testing:

• whether the best final mode is DPI-unaware with OS scaling, system-DPI-aware, or a custom Qt-side scaling patch

Recommended Direction

Treat this as a legacy-Qt DPI retrofit problem, not just a missing API call problem.

The next pass should focus on:

• locating the QApplication construction site inside 0x004c7260
• locating first top-level window creation/show
• tracing where windowGeometry is applied to the main window
• deciding whether to pursue an OS-scaling strategy or a real application-side scaling patch