2

First of all I want to explain my scenario a little bit: I have to maintain a legacy software product (25+ years old) based on plain old WinAPI. The difficulty is, that we have no code for that, and the original author company is long gone (RIP @ 1997), but they left us a plugin API, and some statements like we are free to do with it what we want. So we did some x86 reverse engineering and have written a lot of plugin code and theoretically everything is fine. And the application still does its job perfectly. It even does its job perfectly on Windows 10 beside one little issue:

As soon as a user tries to save its data to the user documents folder the application sometimes (not always!) has no access to create&write/overwrite a file there. We have tracked that down to some old fopen, fwrite, fprintf calls, which are prevented when the Windows 10 Defender ransomware protection is enabled.

e.g.

mov     ecx, [esp+3Ch+access]
push    ecx
lea     edx, [esi+eax+400h]
push    edx
call    _fopen

Or

push    offset SomeDataOffset
push    eax
push    edx
push    offset FormatOffset
push    ebx
call    _fprintf

(And many more.)

The thing is that I don't want to tell the users to run the application in administrator mode to (maybe?) bypass that, because in some cases the even can't. And I'm not even sure whether this works. So my best choice would be some replacement code, which does some elevation or general asking for permission to the system/user, which then allows to write the data to that directory/file.

So the question is, what can I do about it? I know how to replace that code, but not by what.

TL;DR

Is there any magical WinAPI or whatever function/code, that allows me requesting permission (maybe with a system popup for the user) to write to a specific file path? (But which does not require administrator permissions)

Christoph Meißner
  • 1,371
  • 2
  • 18
  • 40
  • Elevation is required at program startup, you can't ask for it half-way through. – Mark Ransom Aug 27 '20 at 18:44
  • 1
    I know that I can't elevate a process after start. But the point is that I don't want to require administrator permissions, as it just wants to write a file to a directory owned by the current user. It should be simply not required. And it probably doesn't help, as the virus scanner is blocking some call - not UAC. – Christoph Meißner Aug 27 '20 at 18:46
  • Contact the virus scanner company and have your software be put on their white list. Then if they are thorough, you will be informed that your software will not be blocked starting in version (x) of their software. – PaulMcKenzie Aug 27 '20 at 19:06
  • 2
    You should also make sure it is the virus scanner that is causing the issue by turning off their software and see if your program no longer has an issue. That's the formal process of getting any software from not being detected -- verify, then contact the company. Of course you will have to prove you're the author of your program, but that's another story. – PaulMcKenzie Aug 27 '20 at 19:13
  • 2
    [The COM Elevation Moniker](https://docs.microsoft.com/en-us/windows/win32/com/the-com-elevation-moniker) allows you to perform operations with elevated privileges on behalf of a client, without requiring the client to be elevated. Though it would probably be advisable to diagnose, why the file I/O fails to begin with. A process running under a user's account should have full access to that user's private data store (like the Documents folder). – IInspectable Aug 27 '20 at 20:49
  • Another option is to move the operation into a separate process, and then use `ShellExecute/Ex("runas")` to run that process elevated, without having to elevate the main process. – Remy Lebeau Aug 27 '20 at 21:31
  • 1
    You should not need elevation to write to the user's profile folder. Over-zealous antivirus is a common problem. You could try signing the app to see if it encourages Defender to leave you alone. – Jonathan Potter Aug 28 '20 at 02:11
  • @IInspectable: After a failing `fopen` `errno` returns 13 (EACCES) so well, something is preventing the access. And turning off ransomware protected always helped AFAIK. So I believe we found the guilty one. ;-) But I'll investigate the COM Elevation Moniker a little bit. This sounds interesting. @JonathanPotter: The application and also the loaded plugins are already signed with our companies certificate. So this should not be the problem. – Christoph Meißner Aug 28 '20 at 09:16

0 Answers0