Virus in build 878

User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Virus in build 878

Post by Robert »

Josef Templ wrote:We have added ... additional text files that contain an SHA-256 hash code ... This allows for checking the file integrity at least manually.
A loosely related topic for manually increasing ones confidence that you know what is going on is to have correct timestamps on the distribution files (I have raised this topic before).
Should we reconsider if this is desirable or practical?

I have a module (on CPC: WandsTimeStamp) that does this from a text file of time values. Obtaining this file is a bit tedious (see the instructions below). Can some, or all, of this process be automated as part of the standard build engine?
TimeStamp.pdf
Docu for WandsTimeStamp
(76.01 KiB) Downloaded 287 times
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: Virus in build 878

Post by Zinn »

Robert,
TimeStamp will not solve the problem. It introduce another problem which I have since Microsoft Windows exist. There are different rules about storing time on NTFS and FAT. One use the Greenwich Time and the other the local time. When the local time changes from winter to summer or vice versa the time are not equal between NTFS and FAT. There are one hour difference.

The only way will be to use some hash code. It doesn't matter which one we choose e.g. MD5, SHA-256 or any other secure one.
- Helmut
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Virus in build 878

Post by Robert »

Yes, FAT times are a pain.

And sometimes, when you copy a file, the time changes by a few seconds.

BUT, sometimes I want to know what files have changed in the last six months, or three weeks, or whatever, and even Windows timestamps are adequate for that.
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: Virus in build 878

Post by Zinn »

In my list you can see the date and and the md5 checksum
e.g.:

Code: Select all

-> D:/Beta1707
BlackBox.exe	      28.07.2017	271ed5d13dbd37f7180e5f1ff4936211
BlackBox.exe.manifest	 2.12.2005	c0d4a514050a833386ebc056d5bee8d9
Empty.odc	               10.12.2005	 107c4c874839799a0742f4e9e347c6bc

-> D:/Beta1707/Com/Code
Aggregate.ocf	28.07.2017	 4b1b3fa5edf1c78062f6cdf63d1aa554
Connect.ocf	28.07.2017	 f6ca7a5d95f77b8658da4570b258073d
...
and is written in Courier and looks not so terrible as above
- Helmut
cfbsoftware
Posts: 204
Joined: Wed Sep 18, 2013 10:06 pm
Contact:

Re: Virus in build 878

Post by cfbsoftware »

I fear that this is becoming a wild goose chase. I believe it is time to stop and rethink what problem it is that we are trying to solve. The basic problem is that there are unreliable anti-virus products in existence. I have been investigating and came across the site:

https://www.av-comparatives.org/false-alarm-tests/

"With AV testing it is important to measure not only detection capabilities but also reliability – one of reliability aspects is certainly product’s tendency to flag clean files as infected."

"False alarms can sometimes cause as much troubles as a real infection."

We have a certificate for digitally signing BlackBox don't we?

"A digital signature, also sometimes called self-signed certificate, is a way for a software, application, or plug-in publisher to verify the authenticity of its own code when provided for download.

If so we should be distributing the software as a signed installation file. As long as that is stated on the website and a statement that the product has been passed by a named reliable AV product (or two) that should be sufficient to allay the fears of the average user.

If there is also a desire to distribute the software as a zip file or whatever then the users who choose to go that route would not be so easily put off by false alarms and assume the risk. A hash of the entire zip file should be sufficient.
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Virus in build 878

Post by Robert »

This morning Windows Defender deleted BlackBox.exe, build 911, and made the desktop link "anonymous" - ie it lost the BlackBox icon and was disabled.
I restored it.
This afternoon Windows Defender deleted both BlackBox.exe, build 911, and the desktop link (and a couple of other builds).

It does this with no warning.

This is getting tedious.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: Virus in build 878

Post by Josef Templ »

Does it make a difference if BB is installed in the Windows "Programs" folder or somewhere else?

Is there any possibility to 'white list' an application in Windows Defender?

Is there an option in Windows Defender that lowers its level of aggressivity?

- Josef
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Virus in build 878

Post by Robert »

I don't know the answers to these questions.

The programme is simply copied into "D:\BlackBox_911" from the zip file, and used in a Client / Server configuration with all my private files in "D:\BlackBoxClient".

There is an old copy that has been "Installed", so the registry and file associations know about it.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: Virus in build 878

Post by Josef Templ »

On my Win10 Laptop there is an option for Windows Defender:
In english it may be called something like "add exclusion".

It allows to specify individual files and also folders to be excluded from Windows Defender.

- Josef
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Virus in build 878

Post by Robert »

Found that - I've "white listed" build 915 (the beta). I'll report if there are any more problems.

Thanks.
Post Reply