#ifdef 12 Posted Tuesday at 04:49 PM Do you remember that show last summer? 😶 Well. These same guys recently launched their own "VirusTotal" analog and, obviously, their new service is very stupid and dangerous too: But I suppose it's gaining popularity and/or is being actively promoted, because recently some clients (suffering from a special form of paranoia) started complaining: "VirusTotal" and "Hybrid Analysis" have started marking my signed (say "Hi" to CrowdStrike!) app as malicious: As you can see, the problem is specifically with the "wine_get_version" string, which Delphi for some reason includes even in a completely empty EXE (to verify, you can create a new empty "VCL, 32-bit, Release" project without a single line of code): Of course I reported this to CrowdStrike, but these guys definitely know how to make a problem out of nothing: So... Any ideas why Delphi does this, and how to avoid it? I don't need the "IsWine" check from SysInit.pas, but I can't figure out how to disable it: Yes, I know this string can be fixed in HEX, but I need a more reliable solution, I don't want to patch each of my files every release 🥲 Share this post Link to post
DelphiUdIT 200 Posted Tuesday at 06:11 PM This is a method to detect if it's running under wine emulation. Look this: https://stackoverflow.com/questions/27413641/how-to-detect-if-delphi-program-runs-in-playonmac Share this post Link to post
Remy Lebeau 1461 Posted Tuesday at 08:04 PM (edited) The RTL looks for Wine as part of its check to know whether it can use the Win32 API to access TLS (thread local storage) data, instead of using direct access to the GS register. Edited Tuesday at 08:05 PM by Remy Lebeau Share this post Link to post
#ifdef 12 Posted yesterday at 03:10 AM (edited) Ok, thank you. And how can I permanently remove the "wine_get_version" string from my EXE? Because with this string CrowdStrike considers my EXE "malicious": ... but without this string (when I remove it in a HEX editor) it's just "suspicious" I suspect that CrowdStrike has been reading others' blogs and set up a simple trigger for this string, thus shifting this burden from their head to mine, because Delphi adds this string to all EXEs by default 😞 Right now, I'm patching each file, but what if I want to both get rid of the string and don't want to patch the file each time? Edited yesterday at 03:15 AM by #ifdef Share this post Link to post
David Heffernan 2357 Posted yesterday at 05:55 AM I personally want my program to run on Wine. Seems like Crowdstrike is the problem. Do you sign your executables? 2 Share this post Link to post
Remy Lebeau 1461 Posted yesterday at 06:45 AM 3 hours ago, #ifdef said: And how can I permanently remove the "wine_get_version" string from my EXE? You can't, without patching the EXE or recompiling the RTL. Nor should you be doing so. You should be complaining to CrowdStrike instead. And code-signing your EXE. 1 Share this post Link to post
#ifdef 12 Posted yesterday at 06:59 AM (edited) Of course, my code is signed: And it has always been signed: And yes, I contacted CrowdStrike. Everything is useless, that's why I'm here. For the guys at CrowdStrike it doesn't matter how exactly the "wine_get_version" string is used — they hate the very fact of its presence, so by default they consider any executable file containing it to be "malicious". This is the root of the problem, but they don't see any problem with this approach and therefore have no intention of fixing it, they're completely fine with it 😑 Edited yesterday at 07:07 AM by #ifdef Share this post Link to post
David Heffernan 2357 Posted yesterday at 07:49 AM What actual problem does this cause? How does this affect what you do? Share this post Link to post
#ifdef 12 Posted yesterday at 08:13 AM Clients have a system for selecting the software they use: according to the rules and regulations, at the selection stage they are forced to give priority to software that is impeccable in terms of security. When selecting, they do not figure out whether the software is actually dangerous or not, the verdict of competent and proven online services is enough for them. If the online services unanimously recognize the file as safe, the software goes to the next stage, and so on. It's like a face control 🙂 These are their rules, I cannot change them. All that is required of me is simply to comply with them and provide code that 100% passes any security checks. As is: Should be: Share this post Link to post
#ifdef 12 Posted yesterday at 08:20 AM (edited) In fact, the problem is idiotic, and it should not exist at all: CrowdStrike cannot even prove their false accusations (I asked what kind of danger this "wine_get_version" string carries and how exactly my application exploits it, but they, of course, ignored all my questions), but customers do not need any evidence from me — software from other providers successfully passes all checks, and my software is considered dangerous, and this is enough for any bureaucratic machine. I would never trust a heuristic that considers a file version to be an IPv4 address, and moreover — considers "0.0.0.0" to be a valid IPv4 address: But "the customer is always right" 🥲 Edited yesterday at 08:27 AM by #ifdef Share this post Link to post
pyscripter 703 Posted yesterday at 11:38 AM (edited) Out of curiosity, I tried the CrowdStrike analyzer on the PyScripter setup program (signed). Whilst Falcon and MetaDefender gave a clean record, their Falcon Sandbox report gave a threat score 100/100! The report included the following: This report has 268 indicators that were mapped to 106 attack techniques and 11 tactics - Calls an API typically used to query local/system time as file time - Reads configuration files (.ini files) - Marks file for deletion - Contains ability to load/free library (API string) - Contains ability to modify registry key/value (API string) - Contains ability to set file time (API string) etc. Micorsoft's "MicrosoftEdgeWebview2Setup.exe" fails miserably as well. I am not sure any real-world compiled program would pass all these tests. I don't think there is much to worry about here. Edited yesterday at 11:39 AM by pyscripter 2 Share this post Link to post
#ifdef 12 Posted yesterday at 01:57 PM Thank you! I wasn't worried either. Until my application was rejected, citing the report of this service 😞 Share this post Link to post
Brandon Staggs 303 Posted yesterday at 08:51 PM This reminds me of "registry cleaners" that do things like automatically remove entries that it determines are paths to files that no longer exist, as if it knows how those would be used if it even did understand how to properly check those things. I actually had this problem with some customers -- they used a snake-oil "registry cleaner" that was removing items my software needed from the registry, causing unexpected behavior. I told the customers that they were using software that was corrupting their system registry under the guise of "cleaning it" and if they needed to use my software, they'd have to stop running bogus "registry cleaners" that indiscriminately removed entries it did not understand. I moved on. I have also dealt with virus scanners and false positives. One of the worst was/is "webroot" that would do more than report false-positives -- it disabled basic Windows functionality for any application it didn't understand, including the Windows clipboard. Hours of diagnosing problems that I should have been able to bill to webroot. In the end, I told the customers, don't use that horribly designed software unless you are willing to whitelist my software. I do understand your problem is competitors whose software doesn't trigger these false-positives. But in the end all you can do is try to make this CrowdStrike's problem by making their customers aware of the issue and complain. After CrowdStrike bricked thousands of PCs across the globe I don't know why anyone would be willing to trust it any more, but I gather most of them are governments or companies fettered by government regulations, and where government bureaucracy exists, sanity and reason flees. Maybe you can write a batch file that obfuscates the string in question post-build. It's not a Delphi bug and should not be treated as a bug in the RTL. 2 Share this post Link to post
#ifdef 12 Posted 18 hours ago 5 hours ago, Brandon Staggs said: After CrowdStrike bricked thousands of PCs across the globe I don't know why anyone would be willing to trust it 🔥 My problem is exclusively and only in CrowdStrike (not in clients, and certainly not in Delphi), but in the absence of ways to influence CrowdStrike, I am now trying to remove the line using Delphi, that's all. It looks like I'm confusing cause and effect, I know, but I can't fight them alone 🙂 Share this post Link to post
Sherlock 666 Posted 6 hours ago I thought they had gone under, due to gross incompetence. But as one can see, that is no reason to die as a business anymore...quite the opposite even. Share this post Link to post
Brandon Staggs 303 Posted 3 hours ago 14 hours ago, #ifdef said: My problem is exclusively and only in CrowdStrike (not in clients, and certainly not in Delphi), but in the absence of ways to influence CrowdStrike, I am now trying to remove the line using Delphi, that's all. If I had to do this, I would write a tiny little console app that replaces wine_get_version with some other deterministic text in a binary file, and add it as a build event. Then I would have to test the theory that the problem is that specific function name, rather than the code around it triggering some heuristics. Writing a console app to do it would at build be less maintenance and headache than rebuilding the RTL to remove it. Share this post Link to post
salvadordf 34 Posted 3 hours ago One quick and extremely dirty solution for this issue would be to increase the executable size. That web page has a 100MB limit. Share this post Link to post