Oh crap... PB ransomware

For everything that's not in any way related to PureBasic. General chat etc...
User avatar
DeanH
Enthusiast
Enthusiast
Posts: 223
Joined: Wed May 07, 2008 4:57 am
Location: Adelaide, South Australia
Contact:

Re: Oh crap... PB ransomware

Post by DeanH »

That's crazy! But I'm not surprised. I wonder what byte sequence is the trigger.

I tried a digital signature but it made no difference.

Providing a 64-bit version was the major part of the solution for me. That move reduced the incidence but did not eliminate it. I still get reports from users about AV interference and have even experienced it myself at my workplace. Queensland state schools have the worst problem I have encountered. I've instructed my users to exclude the Bookmark folder / mapped drive, as Microsoft has recommended, but that isn't always possible as some have no control due to corporate network policies.

I tried compiling with the C-backend but that actually seemed to generate more false positives than the ASM backend.

I suspected Virus Total caused the number of false positives to multiply, so I stopped using it. That definitely reduced the frequency.

I did try submitting the compiled programs to many AV companies but only Kaspersky acknowledged the submission. Since then I have not seen a false positive report by their system.

Another trick that has worked has been to pack the exe's using PureBasic's LZBrief format for downloading updates. The update file also has a txt extension. I have not yet seen an AV system suspect anything until after the exe's are unpacked and opened. I tried zip and lzm, but that considerably slowed the download and were flagged before unpacking. Lzh was much better but not 100%, so I use that and lzb.
User avatar
DeanH
Enthusiast
Enthusiast
Posts: 223
Joined: Wed May 07, 2008 4:57 am
Location: Adelaide, South Australia
Contact:

Re: Oh crap... PB ransomware

Post by DeanH »

I introduced 64-bit versions of my library system back in 2019 to combat the increasing false positives. That move helped a lot, but I still maintain 32-bit versions as about 5% of my userbase still has 32-bit XP and W7 systems. I also stopped using VirusTotal because any suspicious flags were soon spread to a large number of AV systems. This info is shared. It is like VT is a virus itself. I submitted the EXE's to a large number of AV companies. Kaspersky was the only company who ever got back to me when I submitted exe's and have not had a problem with their system since. I tried certificates but that made no difference. The problem sort-of died down but has reared its head again, even with 64-bit exe's.

Since switching recently to PB 6.02 in the last two weeks I have noticed a very sharp increase in false positives reported by my users. I'm not convinced it is due to 6.02 but am suspicious of the timing and am seriously considering going back to 6.01 or even 5.73. I have tried compiling with the C- compiler but the FP's seem even worse. Exe's are being actively erased without notification to the user, or some type of block is being put on them producing "Access denied" errors. Because of that, the exe's cannot be deleted or overwritten. In some cases, providing the exe with a different filename has worked, but then it gets flagged later. The only practical solution I found is to have the AV system exclude the folder. However, that is not always possible due to central control by government authorities who refuse to exclude anything. Their solution is to tell the school user to change to another, cloud-based system.

Or re-write with a different language, something I am absolutely loath to do. I have started re-developing as browser-based (exe's written in PB) but it is a very hard, slow slog with loss of functionality due to the way browsers work.
User avatar
Caronte3D
Addict
Addict
Posts: 1027
Joined: Fri Jan 22, 2016 5:33 pm
Location: Some Universe

Re: Oh crap... PB ransomware

Post by Caronte3D »

Very big problem :cry:
I don't see a definitive solution for PB programs.
BarryG
Addict
Addict
Posts: 3292
Joined: Thu Apr 18, 2019 8:17 am

Re: Oh crap... PB ransomware

Post by BarryG »

One thing I learned is NOT to make your app do everything when it's first run, because that's when the automated anti-virus tools can see what it does.

So, I changed my app to show a EULA prompt when first run, which trips a lot of AVs up because the app hasn't actually done anything yet. The message box just sits there and the AV thinks the app is done. That's a good tip in itself, but I go further: because my app does auto-complete for what the user types, I switched from installing the keyboard hook when it runs to making it an app setting that the user has to enable before the hook is installed. This means the hook is not started (and thus seen) when an automated AV runs my app, because it isn't enabled by default anymore (so the AV doesn't report that the app is a "keylogger").

Do things like that.
benubi
Enthusiast
Enthusiast
Posts: 113
Joined: Tue Mar 29, 2005 4:01 pm

Re: Oh crap... PB ransomware

Post by benubi »

You can't always "blame" PureBasic executables per se. The executables aren't falsely positive because of identifying the used programming language (normally, or it would be sabotage if they did).

- I noticed that import zlib will trigger it. I wrote an SFX head/launcher for self extracting zips. The AV would not like it, but once I re-declared the extraction procedure in which I use the zlib API to ProcedureDLL (in an .exe) the AV's would not complain. I only had to re-declare that one procedure type and it would pass the test.

- Other packers like older JCal can also be suspected of being some malware, only because the JCal algorithm has been found

- IPGadget() - AV's react the most sensibly to this one, probably for "historic" and rather obvious reasons. Perhaps exporting the procedure in which the IPGadget/Window is created may fix it (as it did with my zlib problem).

- Compiling a "Windows" application without opening any window (better use console and open/close it even if you won't write anything ?) e.g. when compiling a program that mostly consists of a few procedure calls and Debug's.

- I wouldn't be surprised if AV's react sensibly with other static and dynamic libraries linked in/to the executable, and API-calls (network, cryptography, packers, keyloggers/GetAsyncKeyState_() etc).

The attackers use many standard libraries, and those cause the FP. As for the IPGadget() I don't know if it's the specific PB implementation code that is recognized as a threat or if it concerns all IPGadgets (the so called window class, which wouldn't be surprising either).

I shortly searched on the site with the malware warning for other PureBasic malware and this ransomware seems to be luckily the only one recorded. PB exists for many years now, and the AV programs work the same way.

When you export those "suspicious" procedures with ProcedureDLL and ProcedureCDLL, it seems you have nothing to hide, and the AV's trust you again. :lol:
User avatar
mk-soft
Always Here
Always Here
Posts: 5335
Joined: Fri May 12, 2006 6:51 pm
Location: Germany

Re: Oh crap... PB ransomware

Post by mk-soft »

But these are all problems of the "great anti-virus programmes" suspecting everything and not a problem of Purebasic.
My Projects ThreadToGUI / OOP-BaseClass / EventDesigner V3
PB v3.30 / v5.75 - OS Mac Mini OSX 10.xx - VM Window Pro / Linux Ubuntu
Downloads on my Webspace / OneDrive
nsstudios
Enthusiast
Enthusiast
Posts: 274
Joined: Wed Aug 28, 2019 1:01 pm
Location: Serbia
Contact:

Re: Oh crap... PB ransomware

Post by nsstudios »

benubi wrote: Mon May 29, 2023 6:17 pm When you export those "suspicious" procedures with ProcedureDLL and ProcedureCDLL, it seems you have nothing to hide, and the AV's trust you again. :lol:
How do you mean exporting? Wrapping often detected funcs in a dll, and then calling that dll instead of calling the funcs directly?
benubi
Enthusiast
Enthusiast
Posts: 113
Joined: Tue Mar 29, 2005 4:01 pm

Re: Oh crap... PB ransomware

Post by benubi »

@nsstudios:
It worked when adding "DLL" after Procedure, like this:

Code: Select all

ProcedureDLL OpenWindow_With_IPGadget()
 ; ....
EndProcedure

ProcedureDLL extract_zip_file()
; ....
EndProcedure
nsstudios
Enthusiast
Enthusiast
Posts: 274
Joined: Wed Aug 28, 2019 1:01 pm
Location: Serbia
Contact:

Re: Oh crap... PB ransomware

Post by nsstudios »

Oh! Gotcha. That makes sense. Thank you for clarifying.
User avatar
DeanH
Enthusiast
Enthusiast
Posts: 223
Joined: Wed May 07, 2008 4:57 am
Location: Adelaide, South Australia
Contact:

Re: Oh crap... PB ransomware

Post by DeanH »

Just to make sure I have this right: changing Procedure to ProcedureDLL stopped your exe's from being flagged? But it is possible to compile a program with no procedure and it still gets pinged.

I have worked out the latest problem with AV systems I have encountered has to do with Cylance. The education department of the state of Victoria, Australia has recently implemented it state-wide. They are refusing to white list my school library management system's exe's on a state-wide basis despite over 600 schools using it. Schools can individually do this, however. Despite this solution, two schools informed me they are changing to another cloud-based system just because of this problem. In both cases, the techs made the decision to change, not library staff.
BarryG
Addict
Addict
Posts: 3292
Joined: Thu Apr 18, 2019 8:17 am

Re: Oh crap... PB ransomware

Post by BarryG »

DeanH wrote: Sun Jun 04, 2023 12:34 amtwo schools informed me they are changing to another cloud-based system
That sucks. I feel so bad for you and you didn't deserve this. So this is all due to Cylance? They can't (or won't) white-list it?

With my app, I'm not doing updates as often anymore. I need to get mine white-listed with SecureAge all the time, and they do it, but it's so annoying as it takes a few days for them to action it. So now I intend to update maybe only once or twice a year (if at all!) instead of monthly. Or unless a show-stopping bug is reported. I've come to the conclusion it's better to have one stable white-listed version out there and not do updates as often.
benubi
Enthusiast
Enthusiast
Posts: 113
Joined: Tue Mar 29, 2005 4:01 pm

Re: Oh crap... PB ransomware

Post by benubi »

@nsstudios @DeanH

I can't certify you that it will always work. There are those online AV's that will check your exe over multiple AV's (something like 15-20 or more), and often there are one or two that still will throw a heuristic tantrum until you become a master or worse - they "won".

It's somewhat logical, even if I never wrote a virus or an AV, don't know the details.

First of all, classical viruses don't write many procedures, they insert "jump codes" pointing to the end of the file where they added themselves for injection, and then return from where they jumped to resume the program start up as if nothing happened.

Code running outside of procedures is more suspicious than inside. Since viruses normally want to hide their activities and inner workings, exported "DLL" functions are the least suspicious. All procedures that use network, encryption and packers and "GetAsyncKeyState" are suspicious because of the potential for abuse (could be all sorts of malware); maybe other corruptible interfaces like the registry API and audio/video codecs, "malicious fonts", password protect zip files ...

Some standard libraries like zlib are well known and abused by bad boy hackers, those libs have their own "signatures" that can be misdiagnosed as being THE threat's signature. For example if an executable contains a string "zlib version 123" it can be always seen as a "backdoor.X/blabla" because the AV heuristics are messed up, inaccurate, have "allergic" reactions to that specific string. I suppose the problem is amplified because some viruses have the capacity to mutate, and perhaps the most stable pieces of code they have are those standard libraries they carry. The compiler signature may also be misdiagnosed or associated wrongly, but I think this would rather happen on purpose or as a bug/glitch, because it doesn't tell anything about the qualities of the executed code itself.
Fred
Administrator
Administrator
Posts: 16619
Joined: Fri May 17, 2002 4:39 pm
Location: France
Contact:

Re: Oh crap... PB ransomware

Post by Fred »

Every languages are plagged with this, it's not PureBasic only. I wrote a C++ program for a company which was falsely flagged by defender, even if it was signed which is absurd. If it's possible to submit a lot of exe to a virus test tool, we could write an exe generator to create one program per library command, and see if a specific command is flagged. Then I can try to modify the code to avoid this, but it's really silly if you ask me.
nsstudios
Enthusiast
Enthusiast
Posts: 274
Joined: Wed Aug 28, 2019 1:01 pm
Location: Serbia
Contact:

Re: Oh crap... PB ransomware

Post by nsstudios »

That sounds like a lot of work but could be worth it.
I fear it's not a good look when you have to start asking your users to trust that your apps aren't malicious if everything claims it is. If you further have to package your executables inside password-protected zip files so browsers and/or hosting providers don't have issues with them, that looks even more sus IMO, and I at least would think twice before opening anything like that.
A game engine I used to use had a problem where everything would flag the executables if you were using its network functionality, i.e., downloading a file, or setting up a UDP server.
It makes me wonder if the removal of InitNetwork() and making the network lib always present has anything to do with some detections?
It could help if a lot more libraries could be explicitly included/excluded (if possible).
BarryG
Addict
Addict
Posts: 3292
Joined: Thu Apr 18, 2019 8:17 am

Re: Oh crap... PB ransomware

Post by BarryG »

Fred wrote: Sun Jun 04, 2023 6:39 pmIf it's possible to submit a lot of exe to a virus test tool, we could write an exe generator to create one program per library command, and see if a specific command is flagged. Then I can try to modify the code to avoid this, but it's really silly if you ask me.
VirusTotal supports automatic submissions with their API support. Yes, it costs money and is silly and annoying for you, but what you suggested seems like something you might have to eventually do; otherwise PureBasic's reputation may get tarnished - people won't trust it to produce "clean" code. Look at DeanH's post - he's already started to lose government clients because of it.
Post Reply