Have you ever encountered - EXE name's changed by the user's system and also caused DLL loading error?

[Edwin Yip 154]

The program in question uses madExcept to intercept and report exceptions.

 

From time to time I got error reports about SQLite DLLs (I use mORMot and I use DLL for a reason) couldn't be loaded.

 

All these error reports have the same characteristic - both the EXE name and the Windows account names are changed:

computer name      : NIBFGAO55910842
user name          : K1dtev0pKEBA0 <admin>

executable         : wjabrmqkin.exe

 

The EXE date is also strange because it doesn't match my program's version.

 

So I suspect that my program's run in a virtual environment (should be VM-for-program but not VM-for-OS like VirtualBox) on the end-user's system.

 

But I've no clue as to what is that, have you encountered similar issues? And how to avoid the DLL loading issue?

 

Thanks.

[FPiette 385]

Why don't you ask the user what configuration he is using?

 

[Edwin Yip 154]

Because the bug reports were submitted  through HTTPS and the email address is optional to fill in by the end user and none of them provided the email address...

2 hours ago, FPiette said:

Why don't you ask the user what configuration he is using?

 

 

Edited August 20, 2021 by Edwin Yip

[timfrost 79]

In a MadExcept bugreport there is nothing to stop you adding customer identification or licence details in the headings. No need for the customer to manually fill in anything.  There are examples in the MadExcept documentation on how to do this in your application which generates the report.

[Guest]

5 hours ago, Edwin Yip said:

But I've no clue as to what is that, have you encountered similar issues? And how to avoid the DLL loading issue?

Not sure 100%, but i think Kaspersky Sandbox or something like it, there is some security suites (AV) have such ability to run the application to analysis it in depth, last time i touched anything with Kaspersky was years back so i don't really remember if changing names was a thing, but this should not be a problem the problem or lets say the failure in loading the DLL is intriguing, my thoughts here is some sandbox changed all of these binary names and if not all will be everything have information to identify the user or the PC, so the idea of using customer identification or license details is most likely out of the question here, (not talking and including GDDR compliance, because once you send even a bug report that contain data to identify a user then you belong to that law realm )

 

Anyway, also i don't know about SQLite library in Mormot, but most likely it is dynamically loaded means there is no import section in the EXE, hence the sandbox might be buggy and didn't change the dll and correct the runtime loading, or simply it was blocked to begin with, also check of you are signing the DLL with the same certificate that signed the exe, building SQLite form sources wasn't a problem and should be easy, but not sure if Mormot library has a custom build, just to have the peace of mind if you are going to sign the dll, as i suggest to build it yourself then use your certificate.

(as a rule don't ever sign a binary not built by you with your code signing certificate)

 

So, as i think it is the case, then you don't need to do anything, you can ignore these reports, but the better solution is to find why there is an exception being raised when the dll is not found instead of handling this matter in a graceful way with message and no exception, i would also add these sandbox are intensively tested and used by thousands if not millions, so while they are good and can be trusted they tend be very harsh on the EXE, and this raise different question, how the report being sent ! this feature is almost exclusively done by the user manually, yet it could be a default setting on such sandbox, 

 

Here i would that if you have an application that connect form the internet i witnessed connections coming form unknown sources (IP) even the application distributed to few people, investigating this led me to discover that uploading an application to TotalVirus will allow many of these AV engines to send it to their labs and sandbox's and that explained these unknown connections.

[Joseph MItzen 252]

1 hour ago, timfrost said:

In a MadExcept bugreport there is nothing to stop you adding customer identification or licence details in the headings.

Except ethics. And GDPR.

[Edwin Yip 154]

9 hours ago, Kas Ob. said:

my thoughts here is some sandbox changed all of these binary names ... but most likely it is dynamically loaded means there is no import section in the EXE, hence the sandbox might be buggy and didn't change the dll and correct the runtime loading....

Hi Kas,

Thank you very much for your insightful thoughts, and I think you nailed it! The SQLite DLL is dynamically loaded in my case...

[Edwin Yip 154]

11 hours ago, timfrost said:

In a MadExcept bugreport there is nothing to stop you adding customer identification or licence details in the headings. No need for the customer to manually fill in anything.  There are examples in the MadExcept documentation on how to do this in your application which generates the report.

Actually I know that custom data can be inserted into madExcept report, but I don't have the user's license included because:

• For bug reporting you usually don't need that until this strange bug report is submitted... 
• The trial users don't have license info.
• The inclusion of that info might lead to the need of considerations for compliance with laws like GDPR or something like that.

Edited August 21, 2021 by Edwin Yip

[David Heffernan 2353]

12 hours ago, Kas Ob. said:

my thoughts here is some sandbox changed all of these binary names

That's implausible. If you start changing executable and dll filenames then the program will just stop working. 

[Guest]

2 hours ago, David Heffernan said:

That's implausible. If you start changing executable and dll filenames then the program will just stop working. 

Well, yes and no. 

It is long story, but let me explain it with my favorite example (rubber duck !),

for an exe that require a library (dll), it can be one of two method to be used, by

1) static declaration, the import table will be managed by the OS and guaranteed to be exist and all the function names-addresses found and resolved, or will fail to run the process.

2) dynamically loaded by using OS Api's like LoadLibrary , GetProcAddress...

That is known and clear 

 

Now lets talk about these secure Sandboxes, these are not the usual sandbox that been built for compatibility or portability, these specific sandboxes are evolved form tools developed internally as tools to help engineers and experts to analyze binary, some exe are protected and reversing them are time consuming, so you can shorten this process by capture and record their behaviour, what files are being access, registries key, low level API access like drivers, thread creating, scanning running application....

Anyway, these tools are evolved to the point where with small modification (they will not disclose their own internal tools) they made a full product that can help any user, these tools are logging and watching everything, almost hooking every single API from the OS,

 

And to the point of renaming of anything is not from the OS

1) for static declaration, the DLL should not matter for the EXE so, when the EXE loaded in most likely virtualized method by the sandbox, it loaded right but the file is there with its name, only the exe can't and will not find it, because all file access functions had already built tables to replace any library outside of the OS and will obey this table, meaning if your exe is using a dll with static declared API then the name of the dll should not be important for the exe, hence if the exe already using a dll with static imported API, then trying to resolve another API at runtime should be handled as red flag !, this extended to loading it.

2) About runtime loading and resolving, an exe calling LoadLibrary("MyDLL.dll") from this point only the handle should matter so, this API will be hooked and changed before sending to the OS, on EXE-OS(API) layer then hooked again on OS kernel layer to be resolved again and the kernel driver of the sandbox will decide resolve it back and load the real file or return it is not found, the whole renaming is happening in the memory nothing will be written on disk, and that is major point, another point is when the sandbox protection layer have failed and like many times someone found a way to deceive (workaround) the LoadLibrary or managed to disable the kernel driver and reverted to the OS default handler, then the real kernel function will report the file as not found, this is a protection scheme.

 

This was short explanation with small example, but the subject need pages and pages to explain the differences in layering and protection for different cases, and i am not claiming to know it all in that matter, now thinking again, well calling LoadLibrary twice on the same file might report file not found on the second call, as from the sandbox point of view that is wrong and better safe than sorry, while finding the exe module name itself will not be a problem just report the same changed one every time , the target here is if an exe managed to escape and lets say implemented malicious behavior (registry,files..) to run on startup, then it will be trying to run non existed file name.

 

Hope i explained it clear enough.

[Edwin Yip 154]

FYI: Just tested with Sandboxie and it's not the culprit. 

Edited August 21, 2021 by Edwin Yip

[David Heffernan 2353]

1 hour ago, Kas Ob. said:

Hope i explained it clear enough.

Nah, I don't really believe anything that you are saying here. 

[Edwin Yip 154]

13 minutes ago, David Heffernan said:

Nah, I don't really believe anything that you are saying here. 

Oh, this is the third time I heard you simply saying "I don't believe you". The first time I heard about that from you is on a stackoverflow question I asked about my Delphi IDE strangely reset my frame sizes after each project reload (or IDE reload), and you said the same thing which I didn't bother to explain more ;)

[David Heffernan 2353]

3 hours ago, Edwin Yip said:

this is the third time I heard you simply saying "I don't believe you"

Well, sometimes I think people say things that aren't correct. And I have had that thought multiple times.