Security review of the Windows app
Use this article when a sandbox, antivirus, or proxy review asks why the Mobile Locker Windows installer looks suspicious. The current Windows app is a signed desktop app (version 5.x). It is not the previous Windows app (version 2.x).
For the host allow-list, see IT Considerations for the Windows App. For Intune or another MDM, see Deploy the Windows app with Intune. If sign-in or sync fails with a certificate problem, see Amazon SSL certificate trust (Windows).
A high sandbox score on this installer is a sum of signatures on a normal per-user install. Setup starts its own program. It does not read Windows credentials, and it does not place code inside another program.
On this page
Where the app is installed
Setup installs per user. It does not need elevation. The app is self-contained. It does not install a separate .NET Desktop Runtime.
| Item | Location |
|---|---|
| Install folder | %LocalAppData%\MobileLocker\ |
| Main program | %LocalAppData%\MobileLocker\current\MobileLocker.exe |
| Update program | %LocalAppData%\MobileLocker\Update.exe |
Setup is a 32-bit bootstrap (Velopack). It installs the 64-bit Mobile Locker app. MobileLocker.exe, Update.exe, and Setup are Authenticode-signed as Vorenus Ventures LLC. Microsoft and Nutrient files that already have a valid signature keep that signature.
Writes into MobileLocker.exe
A sandbox often reports that Setup writes into MobileLocker.exe and calls that process injection.
That write is Windows starting the program Setup just extracted. Windows fills the new process with its startup block, then a short pointer. The process that runs is the signed Mobile Locker app. There is no remote thread, and there is no second payload.
Mobile Locker does not call WriteProcessMemory, VirtualAllocEx, or CreateRemoteThread.
Handle to lsass.exe
A sandbox can report that Setup opened a handle to lsass.exe and title that finding as credential dumping.
The same process walk also opens explorer.exe, winlogon.exe, and svchost.exe. The signature class for that walk is process discovery. Setup is checking what is already running.
Mobile Locker does not read LSASS memory and does not collect Windows credentials. After a real sign-in, the API token is stored in Windows Credential Locker.
Hooks and guard pages
API hook. A scan may show Wow64Transition in ntdll and call it credential API hooking. Setup is 32-bit, and the PC is 64-bit. Windows inserts that hook so the 32-bit bootstrap can call the 64-bit kernel. Mobile Locker does not hook credential APIs.
Guard pages. A scan may show PAGE_GUARD inside Setup. That allocation is in Setup's own process. The .NET runtime and the standard library use guard pages in the current process. It is not a guard placed on another process.
Network
Allow the hosts in IT Considerations for the Windows App. This section says what those calls are.
Before sign-in
app.mobilelocker.com is the same Mobile Locker service the iOS app already uses. eu.mobilelocker.com is the EU API.
Before anyone signs in, the Windows app can open the public login page and send support logs. Those logs cover events such as the theme, opening the login page, and touch mode. They include the app version, the Windows version, and the computer name. They do not include an email address, a contact, or a presentation.
After sign-in
After an employee signs in, app.mobilelocker.com is the product: approved content, contacts, email, leads, and CRM context when a call is linked. The S3 hosts in the allow-list serve presentations and other files.
Diagnostics
These hosts are listed on the IT article under Diagnostics. Sign-in and content still work if they are blocked. Allow them when the proxy is default-deny, so a later review does not treat them as unknown.
https://otel.mobilelocker.netreceives operations telemetry: traces, warning-level logs, and metrics. It does not receive customer content. Authorized Mobile Locker staff can open that collector. It is not a customer console.https://notify.bugsnag.comandhttps://sessions.bugsnag.comare the crash reporter. A release build sends a session when it starts, and a report if the app crashes.Bugsnag.dllin the install folder is that client.
Registry, shortcuts, and the protocol
A scan often marks the installer's registry writes as boot autostart. The values are Add/Remove Programs, two shortcuts, and the mobilelocker:// handler. Nothing is in the Startup folder, and nothing is in a logon Run key.
| What the scan shows | Purpose |
|---|---|
| Uninstall key for Mobile Locker | Add/Remove Programs. The icon is MobileLocker.exe. Uninstall runs Update.exe. |
mobilelocker:// protocol, per user |
Lets Veeva, CATS, or a browser open a presentation. It does not run at logon. |
| Desktop and Start Menu shortcuts | Launch the app. The Start Menu shortcut is under Programs, not Startup. |
On a managed fleet, set DisablePublicAutoUpdate=1 so the app does not update itself. The preferred value is HKLM\SOFTWARE\Mobile Locker\Updates\DisablePublicAutoUpdate. Setup does not create that value. See Deploy the Windows app with Intune.
DLLs in the install folder
A scan may call the DLLs beside MobileLocker.exe a side-loading risk. Every file it lists is under %LocalAppData%\MobileLocker\current\.
Those files are the self-contained .NET runtime, the Nutrient .NET PDF library, and the other assemblies the app needs. Examples include coreclr.dll, clrjit.dll, e_sqlite3.dll, GdPicture.NET.14 files, and Bugsnag.dll.
Setup does not copy them to System32, SysWOW64, or Program Files. WebView2 uses Microsoft's Evergreen runtime, not a private browser DLL beside the program.
Only that user and administrators can write the install folder. AppLocker or WDAC can allow that folder for the publisher Vorenus Ventures LLC.