Jump to content











Photo
- - - - -

ImDisk Toolkit

imdisk toolkit ramdiskui discutils image file mount

  • Please log in to reply
300 replies to this topic

#226 v77

v77

    Silver Member

  • Team Reboot
  • 571 posts
  •  
    France

Posted 09 January 2016 - 11:24 AM

ImDisk Toolkit doesn't come within the imdisk installer anymore ?

http://reboot.pro/fi...disk-toolkit/  <-- outdated ?

 

I have no problem with the "Download" button... With it, you come to another page where you have to choose between the installer (ImDiskTk.exe) and the source.
Except the fact that it does not use the last version of the driver (yes, I'm late...), there is nothing "outdated".



#227 v77

v77

    Silver Member

  • Team Reboot
  • 571 posts
  •  
    France

Posted 31 January 2016 - 06:41 PM

I am about to make a new release, but Avast gives an alert for RamDiskUI.exe (and therefore the installation package): Win32:Evo-gen [Susp].
I can make it disappear by changing to optimisation level used with gcc, but it will add about 10KB to the executable.
Should I ignore Avast, which is one of the most popular antivirus, or add 10KB totally useless?

Of course, I can say that if you trust more a closed-source antivirus than an open-source software, there is a problem somewhere. But this will not prevent some people to complain...

#228 steve6375

steve6375

    Platinum Member

  • Developer
  • 7139 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 31 January 2016 - 06:51 PM

You know the answer! No you cannot ignore Avast!

What is 10K these days anyway!



#229 v77

v77

    Silver Member

  • Team Reboot
  • 571 posts
  •  
    France

Posted 31 January 2016 - 07:42 PM

You know the answer! No you cannot ignore Avast!

If I knew the answer, I would not have asked.
Why should I take care of the bad choices of the users?
 

What is 10K these days anyway!

This is 15% of the originale size of the executable.

If all the developers begin to ignore the false alerts, then the antivirus manufacturers would have serious issues... Of course, I am aware that I will never be followed, but I can still dream.
Perhaps I should play that to heads or tails... :)

 

By the way, I just asked something on StackOverflow. But this is to retrieve only 20KB...



#230 steve6375

steve6375

    Platinum Member

  • Developer
  • 7139 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 31 January 2016 - 07:47 PM

Do you want to get loads of emails and complaints and 'rants' from people who are convinced that you are distributing viruses in your software?

Do you want to have to reply and rebuff them all when they complain to loads of forums, twitter, facebook, etc. that you are distributing viruses?

It's not worth it!



#231 v77

v77

    Silver Member

  • Team Reboot
  • 571 posts
  •  
    France

Posted 31 January 2016 - 08:03 PM

Do not tempt me...
Moreover, this would not be the first time:
http://reboot.pro/to...e-3#entry176233
And there are always false alerts with ImDisk Toolkit. I never released a version with 0 as a result on VirusTotal. But it rarely concerns a popular antivirus.



#232 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1416 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 31 January 2016 - 08:11 PM

Have you notified Avast about it? In my opinion they should at least get a fair chance to fix their software, it's not your fault that this happens. Even if you find a workaround this time, you could very well end up with false positives in future versions.

https://www.avast.co...e-file-form.php

 

I have had this problem now and then with ImDisk and others of my software as well and I check now and then with virustotal.com and file false positive reports to the scanners that detect malware in my software. Particularly the big ones usually respond and fix their scanners within a few days or so. It could be a little worse with smaller ones though, for instance I have had frequent problems with Rising. They seem to never answer false positive reports at all.



#233 v77

v77

    Silver Member

  • Team Reboot
  • 571 posts
  •  
    France

Posted 31 January 2016 - 08:20 PM

Thanks for the link, but I am not the first developer to complain about this alert:
https://forum.avast....?topic=167649.0 (in french)
So I doubt that just sending an executable will be enough. Moreover, what will happen if I recompile it?



#234 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1416 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 31 January 2016 - 08:20 PM

Do you want to get loads of emails and complaints and 'rants' from people who are convinced that you are distributing viruses in your software?

Do you want to have to reply and rebuff them all when they complain to loads of forums, twitter, facebook, etc. that you are distributing viruses?

It's not worth it!

 

Well, this happens sooner or later anyway. I spend quite some time on answering e-mails, forum posts and similar about this all the time and there is unfortunately not much I can do about it other than try to file false positive reports so that antimalware software vendors can fix their scanners.

 

So, in my opinion it's pointless to try to find workarounds to avoid a particular malware detection. I think it's a lot better to keep a straight and clear policy that antivirus scanner developers should fix their problems and I will fix my problems. It's of course not possible for me anyway to predict what they will detect as malware and to make it worse, this can change over time. In some cases I have had the same software distributed for more than 10 years when some antivirus scanners suddenly detect malware in it.



#235 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1416 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 31 January 2016 - 08:22 PM

Thanks for the link, but I am not the first developer to complain about this alert:
https://forum.avast....?topic=167649.0 (in french)
So I doubt that just sending an executable will be enough. Moreover, what will happen if I recompile it?

 

Just keep sending them false positive reports if future versions get the same detection results. They will sooner or later need to fix their scanners. They have a bug in their scanner, not you.



#236 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1416 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 31 January 2016 - 08:40 PM

Btw, I had a similar problem with Avast and ImDisk 5 December 2015 when I released ImDisk 2.0.8:

https://twitter.com/...496897718030337

It all got sorted out pretty quickly by Avast support. Until they had fixed it, virustotal.com offered to grey out the Avast detection for this file to avoid the false positive detection to show in their scanner results.



#237 steve6375

steve6375

    Platinum Member

  • Developer
  • 7139 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 31 January 2016 - 08:44 PM

I don't know much about how these scanners work, but I assume that they look for a sequence of bytes (code) that they recognise.

 

If they get reports of false positives, I imagine that they have a CRC whitelist which they simply add to when you report a false positive.

They cannot change the 'byte sequence' because they would have to go back and check it works on all previous (real) viruses still.

 

So developers will keep on having to send them their false positive reports and they will have to keep adding it to their whitelist.

Every time you recompile/re-zip the byte sequences will change and a different byte sequence will give a false positive.

 

I don't see them changing their detection algorithms?

 

As I said, I don't really know how these scanners work, so please enlighten me if this is wrong or too simplistic?



#238 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1416 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 31 January 2016 - 08:59 PM

I don't know much about how these scanners work, but I assume that they look for a sequence of bytes (code) that they recognise.
 
If the gets reports of false positives, I imagine that they have a CRC whitelist which they simply add to when you report a false positive.
They cannot change the 'byte sequence' because they would have to go back and check it works on all previous (real) viruses still.

 

 

No, that's not the problem here. They have signatures of known viruses in the form of known byte sequences or similar that their scanners detect and such detections work pretty safe, there is no such detection triggered here. The problem here is the "heuristic analysis". They usually have a "point system" which could be triggered by almost anything these days. They don't recognize known byte sequences, or at least not as the only detection pattern, but rather combinations of lots of patterns like for instance API functions that are typical for malware to call, embedded data of certain sizes, patterns that look like executable code within embedded data sections, certain words and texts, small changes from known-good packages (to detect repackaged software) and similar. When combinations reach a certain total level, a "suspicious" detection is triggered in the scanner.

 

You can tell such detection by malware names that contain "susp", "gen" or similar. Such detections are not about any known malware, but simply something that could possibly contain malicious code.

 

From discussions with antimalware vendors I have learned that it's important to file false positive reports when this happens. That's the only way they could tune their detection logic to be more precise and so that they could avoid false detections with future versions of similar software. If, on the other hand, a known "named" virus or similar is detected it could be possible to avoid the detection by rewriting parts of the software to avoid a particular sequence of bytes to appear in a place where it's detected as this particular virus. But this happens extremely rarely I would say. It has never happened to me and I don't very often read about such cases in forums either.

 



#239 steve6375

steve6375

    Platinum Member

  • Developer
  • 7139 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 31 January 2016 - 09:12 PM

OK, thanks for that.

So when you report a false positive, are you saying that they investigate what bytes in your submitted code are causing it to flag up (or what routines are triggering), and then re-write their code to not trigger on your code and then re-test all the other test viruses packages that they have to make sure they still flag up real viruses and still do not flag up previous false-positive (benign) software and then re-release the updated virus definitions package.

 

And they do this for each and every false positive that is reported by each developer, each time?

 

Or do they just have an exception list specifically for your file, update the defs and release?  :dubbio:

 

Also bear in mind that most AV packages are picked by users based on the %age detection rates.



#240 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1416 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 31 January 2016 - 09:31 PM

OK, thanks for that.

So when you report a false positive, are you saying that they investigate what bytes in your submitted code are causing it to flag up (or what routines are triggering), and then re-write their code to not trigger on your code and then re-test all the other test viruses packages that they have to make sure they still flag up real viruses and still do not flag up previous false-positive (benign) software and then re-release the updated virus definitions package.

 

And they do this for each and every false positive that is reported by each developer, each time?

 

Or do they just have an exception list specifically for your file, update the defs and release?  :dubbio:

 

Also bear in mind that most AV packages are picked by users based on the %age detection rates.

 

Well, this is not exactly a precise business in that way. Detections that are not about already known viruses will of course always miss some real viruses and falsely detect clean software as possibly malicious. That's unfortunately the way such detections work. Therefore, they need to constantly tune this detection logic in response to several things, both detections of real viruses, their own lab research and of course also false positive reports from developers and users.

 

If this detection would detect a virus they knew about already, they would put a specific detection for that specific virus in their signature files. So it's important to say that this detection is about viruses and other potential malware that they don't know already about and for software that may possibly act in a suspicious way. The only way they can make such detections more safe is by analysing how frequently they detect real viruses and how frequently they get false positives and then tune their logic to raise the detection levels for the parts of the logic that have shown to detect real viruses and lower those that seem to trigger false positives.

 

They can of course temporarily add a specific file to a "known-good" list to make a quick fix for some software and I guess that's why they could respond so quickly with a fix. But it is important to mention that false positive reports are also an important piece in their long-term process of tuning detection logic.


  • steve6375 likes this

#241 cbeerse

cbeerse
  • Members
  • 5 posts
  •  
    Netherlands

Posted 31 January 2016 - 10:56 PM

About avast and different optimalisation levels in compiling ImDisk: If you can reproduce the way avast is triggered just by changing the optimalisation of the code, I'd say avast should be happy to receive this so they can optimize their stuff. I'd say create a nice package for avast:

  • the source code from which ImDisk is build
  • the used GCC compiler, including build number and such
  • the used settings to have avast trigger on the binary
  • the used settings to have avast accept the binary
  • the used build environment (os, version, patch level etc)
  • the binaries for both build settings

I'd say it is weird at least that a build-setting changes the way antivirus reacts to the binary.



#242 steve6375

steve6375

    Platinum Member

  • Developer
  • 7139 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 31 January 2016 - 11:33 PM

Cloud storage sites that use AV detection also give problems.

If I upload a .7z file to Google Drive using standard compression settings, it flags the file as malicious on download.

If i change the 7z parameters to use a different compression setting, it works OK.

If I upload the same files as ANY type of .7z file to MS One Drive, it flags it as malicious.

If I upload the same files compressed as a .zip file, MS One Drive does not complain.



#243 v77

v77

    Silver Member

  • Team Reboot
  • 571 posts
  •  
    France

Posted 01 February 2016 - 08:46 AM

From discussions with antimalware vendors I have learned that it's important to file false positive reports when this happens. That's the only way they could tune their detection logic to be more precise and so that they could avoid false detections with future versions of similar software.

Yes, but with that, we are doing their work. I make a legitimate software, I should not have to defend against false accusations. I receive nothing for the time I have to take to help them to maintain their business.


I'd say it is weird at least that a build-setting changes the way antivirus reacts to the binary.

Using a different optimization level changes a lot of things in the produced code. In fact, an "optimization level" is just a large set of predefined options, as you can see here.
The binary code is so changed that even heuristic detections can be fooled.
But in fact, it's worse than that: just compiling the executable as a "console" application (that is, a command line program) is often enough to make the false alerts disappear. And this is just a flag changed in the executable header...

#244 v77

v77

    Silver Member

  • Team Reboot
  • 571 posts
  •  
    France

Posted 02 February 2016 - 12:17 PM

Version 20160202
- updated to driver 2.0.9
- added russian language
- RamDiskUI.exe: added a warning message for issues related to the fast startup feature of Windows
- RamDiskUI.exe: improved tooltips
- fix in General Settings panel: "Restore hidden dialog boxes" button was not working
- fix in ImDisk-Dlg.exe: two buttons were not translated
- executables are now compiled with MinGW 5.3.0 (instead of 4.7.4)

 
This version brings a warning message for the issues related to the fast startup feature of Windows (Windows 8 and later):
 
160466Capture.png


Russian language is now supported. However, it is not finished because its author has not answered to my last requests. It will be updated as soon as I receive the last translations and fixes.

The last significant change is the use of the version 5.3.0 of MinGW. I didn't yet checked it on my other projects, but for ImDisk Toolkit, the results are rather good. Dynamic ramdisks shows a small slow-down for the sequential writes in the 32-bit version, but a slight speed-up in all other cases. Executable sizes are similar, except for setup.exe which is 20KB bigger. And I got no weird warning at the compilation, except for the swprintf function for which the standard has evolved.

And about this :censored: of Avast, as I don't want to help them in any way, I changed the optimization switch for RamDiskUI.exe, so the executable is 10KB bigger. Thanks Avast. :raygun:

#245 ericgl

ericgl

    Frequent Member

  • Expert
  • 315 posts
  •  
    Israel

Posted 02 February 2016 - 04:22 PM

v77,

 

My Symantec AV blocked the file and deleted it (Imdisk Toolkit 20160202).

So it's not only Avast to blame.

 

Perhaps you've added some code that acts like viruses do?



#246 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1416 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 02 February 2016 - 04:37 PM

My Symantec AV blocked the file and deleted it (Imdisk Toolkit 20160202).


Strange, it looks clean to Symantec at virustotal.com:
https://www.virustot...sis/1454414794/

Could you try updating your Symantec signature files and see if that helps? If not, it will probably help within a day or so.
 

So it's not only Avast to blame.

Perhaps you've added some code that acts like viruses do?


Right now, 3 out of 53 virus scanners detects the current ImDisk Toolkit setup package as malicious. So, it's obviously nothing in this file that looks like a virus to most scanners, just probably bugs in three different scanners.



#247 v77

v77

    Silver Member

  • Team Reboot
  • 571 posts
  •  
    France

Posted 02 February 2016 - 04:47 PM

v77,
 
My Symantec AV blocked the file and deleted it (Imdisk Toolkit 20160202).
So it's not only Avast to blame.
 
Perhaps you've added some code that acts like viruses do?

Strange, VirusTotal shows no alert for Symantec.

About the new code, there is a check of the existence of C:\hiberfil.sys, and a check of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled registry value. Nothing weird in my opinion...

Anyhow, without VirusTotal, as I cannot check anything, it will be difficult to get rid of this alert.



#248 ericgl

ericgl

    Frequent Member

  • Expert
  • 315 posts
  •  
    Israel

Posted 03 February 2016 - 07:09 AM

v77 / Olof,

 

My Symantec AV updates itself every few hours, but I made sure it has the latest signature update and tried to download the file again.

The file got blocked again:

 

screenshot_115.png

 

 

 

BTW, v77:

could you please add a signature to yourself with a link to the download page of Imdisk Toolkit (like Olof has for his tools)?

 

imdisk_download.png

 

It would be much easier to get to it this way.

Thanks.



#249 v77

v77

    Silver Member

  • Team Reboot
  • 571 posts
  •  
    France

Posted 03 February 2016 - 12:11 PM

My Symantec AV updates itself every few hours, but I made sure it has the latest signature update and tried to download the file again.
The file got blocked again:
 
screenshot_115.png

"Suspicious.Emit"? I know I am a bit suspicious :ph34r:  but to the point to see my file deleted... :wacko:
Or maybe Symantec considers that any file not digitally signed is suspicious.

 

That said, if you get alerts (especially the first one) while the version used on VirusTotal gives no alert, I would say that it comes from some settings that you may have changed. Is this possible?
 
 

BTW, v77:
could you please add a signature to yourself with a link to the download page of Imdisk Toolkit (like Olof has for his tools)?
 
It would be much easier to get to it this way.
Thanks.

Well, if this can help...



#250 ericgl

ericgl

    Frequent Member

  • Expert
  • 315 posts
  •  
    Israel

Posted 03 February 2016 - 12:18 PM

...I would say that it comes from some settings that you may have changed. Is this possible?

 

Well, I did change something Symantec calls BloodHound heuristic detection to "Aggressive" mode.

 

screenshot_118.png

 

I've just changed Bloodhound to "Automatic" and the file downloaded normally without getting deleted.

Interesting...  :dubbio:







Also tagged with one or more of these keywords: imdisk, toolkit, ramdiskui, discutils, image file, mount

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users