Date   

Updated eQSL AG and LoTW databases are available...

Dave AA6YQ
 

...via the Databases tab of DXView's Configuration window.

     73,

           Dave, AA6YQ


Re: Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

neil_zampella
 

Joe,

I've been using AVG for over since 2003 and have NOT had 'meltdowns' nor
have I had programs arbitrarily deleted without the program notifying me
before it did anything.   Of course, I made sure that I had the program
settings setup to notify me before any actions are taken, so YMMV.

As far as Norton ... totally agree.

As far as Defender ... I see more issues with that program removing
executables without any advance notice than any other AV program, not
only here, but with other programs which have a small user base.

Neil, KN3ILZ

On 4/12/2020 4:50 PM, Joe Subich, W4TV wrote:

I also agree with Gil.  The Windows anti-malware has given me far
less problems than either Norton or AVG - both of which have been
banned from my systems after resulting in major melt downs *MULTIPLE*
times.

The recent issue with Defender quarantining Commander was entirely
my own fault for not excluding the DXLab Suite folder from Defender
scanning.  However in my defense, I have been using Defender since
it was introduced and this is the first false positive I have
encountered.  As the recovery was relatively painless (as documented
here): <https://groups.io/g/DXLab/message/192460>, I consider this
recent false positive to be a learning experience (and reminder to
always exclude the folders of trusted applications like DXLab Suite
and JtAlert).

In the future, I will add the folders of "niche" applications to
Defender's exclusions once I have evaluated them and decided to add
them to my roster of "production" software.

73,

   ... Joe, W4TV


On 2020-04-12 2:34 PM, Gilbert Baron W0MN wrote:
I have to agree but I doubt there is an anti malware application in
existence that would not be susceptible to this problem and since
defender has only given me this one problem over the years I will
stick with it. Free and for the most part as effective as any
antivirus can be. I think not running as an admin and effective
backups are the real protection even though they are a real pain at
times.

Outlook Laptop Gil W0MN
Hierro candente, batir de repente
44.08226N 92.51265W EN34rb

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Sunday, April 12, 2020 13:02
To: DXLab@groups.io
Subject: Re: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus
/ Anti-Malware Solutions like Defender etc...

Regarding the lengthy post from Max NG7M appended below,

1. Windows is vulnerable to malware because it fails to implement
well-known operating system security measures; correcting this
architectural defect would break many existing Windows applications,
some of which can no longer be updated because their source code or
unique development tools no longer exist. Microsoft has chosen to
live with this defect and mitigate it with anti-malware applications,
which are provided by many software companies and Microsoft itself.

2. During Microsoft's two unsuccessful attempts to recruit me (once
to lead the Visual Studio organization, once to lead the Windows
Mobile organization), I interviewed with several senior Windows
developers and executives. They acknowledged that "protected folders"
and "User Account Control" (UAC) provide little actual security
value; these mechanisms were introduced to visibly demonstrate that
Microsoft was taking security concerns seriously. "Oh, so you want a
secure operating system, do you?" one of them joked.

3. There is no evidence that installing DXLab applications in

c:\Program Files

or digitally signing them would protect them from mis-identification
by Microsoft anti-malware applications.

4. Since there is no malware in any DXLab application, Microsoft
anti-malware applications that identify them as malware are by
definition defective. If you chose to use a defective anti-malware
application, enable it to autonomously upgrade itself, and enable it
to autonomously quarantine applications it considers malware, then
you should not be surprised when one of you applications suddenly
stops working.

5. Microsoft's "solution" to their defective anti-malware is to
accept submissions of executables incorrectly identified as malware
for reconsideration. Over the past several days, multiple attempts to
submit the 4.5 megabyte executable for Commander 14.5.5 stalled; the
Microsoft submission site was evidently over-subscribed. Last night, 
the submission site took less than a minute to accept Commander's
executable; today, the submission status shows "not malware". How
long it will take for this updated determination to reach deployed
instances of Windows Defender is anybody's guess. Will this stop the
next public version of Commander from being mis-identifed as malware?
Unknown.

My inclination at this point is to add Microsoft anti-malware to the
list of applications that can interfere with DXLab applications in

<https://www.dxlabsuite.com/dxlabwiki/ApplicationInteference>

Control your computing environment, or it will control you.

        73,

               Dave, AA6YQ



-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Max NG7M
Sent: Sunday, April 12, 2020 11:53 AM
To: DXLab@groups.io
Subject: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus /
Anti-Malware Solutions like Defender etc...

As we can see, the FUD (Fear, Uncertainty and Doubt) regarding Anti
Virus / Anti Malware solutions (MS Defender in this case) have
reached a new rhetorical level in regards to DXLab applications /
exe's. (based on the number of posts)

First off, I'm not suggesting Dave AA6YQ change anything at this
point because the effort would be rather high and the migration of
currently installed application exe's to the proper location for a
modern day operating system bring a level of complexity along with
the change... installer changes and proper use of User Access Control
(UAC) would be required along with changes to the installer code used
by DXLab (digital signing of exe code etc...).  So I'm happy with the
way things are and I know that I need to exclude the directory where
DXLab applications are installed in my Anti Virus software.  So let
me make that clear, I'm not complaining or suggesting that Dave do
anything to address why this topic keeps coming up over and over and
over and over and over again. Well, other than repeating the current
solution and referring users to how you need to exclude the DXLab
installation path from your anti-virus / anti-malware solution. The
bitching and complaining about controls that are put in place to
protect you and other users in what is in effect a shared network
(the Internet) is rather comical at this point.

If you want to know why DXLab executables are getting identified as
having problems, the problem is not Windows Defender or any other
anti-virus / malware solution.  Identifying Defender as the problem,
just exposes your ignorance around this topic. In a nut shell, the
problem is where the exe's (any any other executable code like dll's)
for DXLab are getting installed along with the fact that the exe's
are not digitally signed.  If you don't agree, ask a software
engineer who has been coding and helping release commercial Windows
exe based (rich client) applications for over 30 years.  And it helps
if the engineer you are asking has had extensive experience related
to using industry standard practices which are designed to help users
keep their computers safe. Your lack of understanding about bad
actors out there that are trying to exploit executable code and at
what OS level this code can execute, is not helpful to the
discussion.  Stop acting like you are a 'safe computing expert' when
you are not one... especially when you are disparaging solutions that
have been put in place to protect you and others despite your own
stupidity.

So for DXLab users at this stage of the game... which I am one of
them and very happy with the amazing job Dave has and continues to do
an amazing job with this free software offering!  I'm perfectly happy
excluding the default directory location where DXLab exe's are
installed from my anti-virus software solution as an exclusion.  I'm
trusting Dave to not deliver exe based code that is malicious. And
even if it pains me so, I'm letting the DXLab installation process
install this executable code (that is not digitally signed) in a
read/write location.

If you are happy with what you have and have excluded your DXLab
installation path from your anti-virus / malware solution's scans,
then you can stop reading now... or you probably never made it this
far anyway.  If you want more of the details as to what the industry
standard has been for decades now, keep reading.  DXLab has been
around so long, it may be hard for Dave to justify a big change (and
personal expense to digitally sign things) at this point.  I total
get that as I have stated above. However, when other users spew out
fear, uncertainty and doubt regarding this topic, they should be
corrected and their ignorance should be exposed.

Solutions like Windows Defender (a darn good free solution) are
designed to protect you despite your, ignorance and laziness. You can
give someone a Twenty Dollar Bill for free and then based on their
ignorance, they will complain that you didn't give them two Ten
Dollar Bills.

For decades now, the industry and creators of commercial operating
systems in use in business and at home have tried and tried to make
commercial and home computing safer. Linux / Unix based OS's and even
MS Windows (make your silly evil sounds and wiggle your fingers in
the air), have been trying to get software developers to locate
executable code in a OS level protected directory structure.  i.e.
for Linux it would be /bin, or /usr/bin etc... for Windows it would
be C:\Program Files (x86) for 32bit executables, and or C:\Program
Files for 64bit executables.  Constrains are put in place to protect
the executable code in these directories using an OS level of User
Access Control to keep code from executing at a 'root' level or
administrator level (in the case of windows) where bad / malicious
code could do all kinds of bad things... install key loggers to steal
you passwords, or execute code to encrypt all your data and hold you
hostage to ransomware schemes.  Or just help use your computing power
and network bandwidth to jump start other evil bad things without you
even knowing day after day and week after week.

For the above reasons and many others not even listed, modern OS's
and their designers do all they can to try and get software installed
into protected areas of the file system and to only be run at levels
where other bad code can't do bad things without you knowing.  Is it
perfect?  nope but it's better than nothing and it's better than just
burying your head in the sand and turning off all the protection.

So what is a Mother to do?  The best practices which have been in
place for decades now (and are not enforced with a draconian solution
yet) are to install executable code in protected directories like,
you guessed it: C:\Program Files etc... AND to locate application
down a path specific to data like c:\Documents\YourUserName where
read write access to data is based on user privilege's.   AND in the
case of executable data you digitally sign your executable code with
a signature that can be verified by a known good certificate
authority. (do a google search on PKI infrastructure if you want to
learn more) this is what virus scanning software is looking at when
it scan for issues.  If the exe code of application A is properly
signed and in the proper directories, then it's less likely to report
a false positive. (yes a pretty simple description of what is going on)

Older software that has been around for a long time gets a bit of a
pass on the above, but users are still required to know what is going
on when they trust this software.  DXLab applications fall into this
category.  Exclude the installation paths from virus scan's / malware
scans.  It's just the way it is right now, and only Dave can decide
if the effort and cost is worth it to revamp the install locations
and incur the cost of executable code signing into his build routines
of the VB application in question, not to mention move all the
read/write data to User/Document paths and deal with UAC.  The arm
flailing and weeping and wailing and gnashing of teeth from existing
users of an amazing and free application, would reach an exponential
level if they had to move their data around etc.... even if automated
in the installer.  I shudder at the flood of questions if this change
were made and I'm guessing Dave would fear the same thing on the
groups.io list here.  I certainly don't speak for Dave at all.

An example of another amazing and free Ham related application that
has adopted most if not all of the above standards is N1MM Logger+. 
Multiple developers in this case are coding on the N1MM project. N1MM
Logger+ exe's are signed (see the link at the end of this post) and
N1MM's installer tries to get you to install the exe's down the
proper path in a Windows operating system.  However, as we all
know... you can override all of this and in effect disable all the
efforts to try and protect you from yourself.  But there is a cost
here... time, money and laborious education.  And this requires
dealing with a new set of questions from uninformed users.

So, at the end of the day... DXLab users need to understand the
current state of how DXLab is coded and how and where it is installed
and understand that the exe's are not signed.  It's okay if you
understand that Dave clearly isn't out to deliver malicious code, but
DXLab, like many other older exe based applications install into a
directory structure that violates current best practices in the
software industry.  It's just the nature of the technical debt
incurred with an older application that has been around for a long
time. Again, I'm not suggesting Dave stop the train and crack this
nut.  We get the benefit of using DXLab which is an amazing suite of
applications written by one super human developer and we just need to
understand that the legacy nature of the installation and location of
the data and exe's will make it suspect for industry standard virus
scanning / malware scanning / bad actor detection software. Stop
blaming Windows and modern virus / malware scanning / detection
solutions and start understanding and why things were created they
way they are.

In the ending of this massive diatribe of mine, executable code on a
modern OS needs to be installed in OS / UAC locations and the exe
code needs to be signed.  Data needs to be installed in OS / UAC
controlled locations where read/write is possible for the processes
that need access to this data.  And all executable code should be
signed with a known digital certificate that is trusted by a known
certificate authority so you a user knows where the code comes from
in the first place.  Is it all 100% fool proof?  Nope, but it's
better to understand how things work rather than spewing out the
continued FUD around this ongoing topic.

Image showing the digital signature on the main N1MM exe
<http://www.nc7j.com/downloads/N1MM/N1MM%20digital%20signature.png>
http://www.nc7j.com/downloads/N1MM/N1MM%20digital%20signature.png

Max NG7M






--
This email has been checked for viruses by AVG.
https://www.avg.com


Re: Cat control

Carl - WC4H
 

Hi Nigel.

While I mainly use WSJT-X, I also use JTDX & MSHV.  I recall that happening a long time ago but not now or even recently.

Are you on the latest version of Commander as well as JTDX? 
What are your settings on the radio?

73,
Carl - WC4H


Responding to Anti-virus Report than an Application is Infected

Dave AA6YQ
 

1. Don't panic! 

1a. Don't direct Windows to uninstall and then re-install application

1b. Don;t delete the application's folder

 

2. To determine whether or not the file reported as infected is actually infected, see

<https://www.dxlabsuite.com/dxlabwiki/FalsePositive>

 

3. To recover from an erroneously quarantined or deleted file, see

<https://www.dxlabsuite.com/dxlabwiki/RecoverMissingExecutable>

 

4. If you choose to continue using an anti-malware application with a history of reporting false positives, consider configuring it to consider your DXLab applications to be safe.

 

       73,

                Dave, AA6YQ


Re: DXKeeper Update Failure

n6rsh
 

Thanks Jim. I will then repair DXKeeper. I don't know what I would do without it.

Steve - N6RSH  ;)


Re: Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

Sidney Shusterman
 

I usually abstain from adding bandwidth but in this case I second the platitudes!

73 Sid K3SX

On 4/12/2020 3:50 PM, Jeff Schwartz via groups.io wrote:
I must say I learn more from reading these threads than I got from any computer course in college. Of course back then there were no personal computers. The one thing I do know is that without DX Labs hamming would not be as enjoyable as it is for me and without Windows I couldn't run DX Labs. So on this Covid 19 Easter Sunday I give thanks to both and the ongoing challenges they provide. Thanks for all  you do Dave.
73 Jeff / KI0KB


Re: DXKeeper Update Failure

Jim McPhee
 

Steve,

Yes, that is the same threat that has been reported here by many others. I didn't try, but I suspect you can search this forum for that label and get many returns.
--
Jim McPhee
Placitas, NM
W5ABA


Re: DXKeeper Update Failure

n6rsh
 

Dave,

 I see all of the remedies listed above but before I do all of that I have one issue. Defender labels the threat as "Trojan:Win32/Azden.B!cl" Do I have a different issue or is this what everyone had been seeing with the DXKeeper upgrade? If so, I assume it is okay to perform the fixes listed above.

Steve - N6RSH


Re: Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

Joe Subich, W4TV
 

I also agree with Gil. The Windows anti-malware has given me far
less problems than either Norton or AVG - both of which have been
banned from my systems after resulting in major melt downs *MULTIPLE*
times.

The recent issue with Defender quarantining Commander was entirely
my own fault for not excluding the DXLab Suite folder from Defender
scanning. However in my defense, I have been using Defender since
it was introduced and this is the first false positive I have
encountered. As the recovery was relatively painless (as documented
here): <https://groups.io/g/DXLab/message/192460>, I consider this
recent false positive to be a learning experience (and reminder to
always exclude the folders of trusted applications like DXLab Suite
and JtAlert).

In the future, I will add the folders of "niche" applications to
Defender's exclusions once I have evaluated them and decided to add
them to my roster of "production" software.

73,

... Joe, W4TV

On 2020-04-12 2:34 PM, Gilbert Baron W0MN wrote:
I have to agree but I doubt there is an anti malware application in existence that would not be susceptible to this problem and since defender has only given me this one problem over the years I will stick with it. Free and for the most part as effective as any antivirus can be. I think not running as an admin and effective backups are the real protection even though they are a real pain at times.
Outlook Laptop Gil W0MN
Hierro candente, batir de repente
44.08226N 92.51265W EN34rb
-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Sunday, April 12, 2020 13:02
To: DXLab@groups.io
Subject: Re: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...
Regarding the lengthy post from Max NG7M appended below,
1. Windows is vulnerable to malware because it fails to implement well-known operating system security measures; correcting this architectural defect would break many existing Windows applications, some of which can no longer be updated because their source code or unique development tools no longer exist. Microsoft has chosen to live with this defect and mitigate it with anti-malware applications, which are provided by many software companies and Microsoft itself.
2. During Microsoft's two unsuccessful attempts to recruit me (once to lead the Visual Studio organization, once to lead the Windows Mobile organization), I interviewed with several senior Windows developers and executives. They acknowledged that "protected folders" and "User Account Control" (UAC) provide little actual security value; these mechanisms were introduced to visibly demonstrate that Microsoft was taking security concerns seriously. "Oh, so you want a secure operating system, do you?" one of them joked.
3. There is no evidence that installing DXLab applications in
c:\Program Files
or digitally signing them would protect them from mis-identification by Microsoft anti-malware applications.
4. Since there is no malware in any DXLab application, Microsoft anti-malware applications that identify them as malware are by definition defective. If you chose to use a defective anti-malware application, enable it to autonomously upgrade itself, and enable it to autonomously quarantine applications it considers malware, then you should not be surprised when one of you applications suddenly stops working.
5. Microsoft's "solution" to their defective anti-malware is to accept submissions of executables incorrectly identified as malware for reconsideration. Over the past several days, multiple attempts to submit the 4.5 megabyte executable for Commander 14.5.5 stalled; the Microsoft submission site was evidently over-subscribed. Last night, the submission site took less than a minute to accept Commander's executable; today, the submission status shows "not malware". How long it will take for this updated determination to reach deployed instances of Windows Defender is anybody's guess. Will this stop the next public version of Commander from being mis-identifed as malware? Unknown.
My inclination at this point is to add Microsoft anti-malware to the list of applications that can interfere with DXLab applications in
<https://www.dxlabsuite.com/dxlabwiki/ApplicationInteference>
Control your computing environment, or it will control you.
73,
Dave, AA6YQ
-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Max NG7M
Sent: Sunday, April 12, 2020 11:53 AM
To: DXLab@groups.io
Subject: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...
As we can see, the FUD (Fear, Uncertainty and Doubt) regarding Anti Virus / Anti Malware solutions (MS Defender in this case) have reached a new rhetorical level in regards to DXLab applications / exe's. (based on the number of posts)
First off, I'm not suggesting Dave AA6YQ change anything at this point because the effort would be rather high and the migration of currently installed application exe's to the proper location for a modern day operating system bring a level of complexity along with the change... installer changes and proper use of User Access Control (UAC) would be required along with changes to the installer code used by DXLab (digital signing of exe code etc...). So I'm happy with the way things are and I know that I need to exclude the directory where DXLab applications are installed in my Anti Virus software. So let me make that clear, I'm not complaining or suggesting that Dave do anything to address why this topic keeps coming up over and over and over and over and over again. Well, other than repeating the current solution and referring users to how you need to exclude the DXLab installation path from your anti-virus / anti-malware solution. The bitching and complaining about controls that are put in place to protect you and other users in what is in effect a shared network (the Internet) is rather comical at this point.
If you want to know why DXLab executables are getting identified as having problems, the problem is not Windows Defender or any other anti-virus / malware solution. Identifying Defender as the problem, just exposes your ignorance around this topic. In a nut shell, the problem is where the exe's (any any other executable code like dll's) for DXLab are getting installed along with the fact that the exe's are not digitally signed. If you don't agree, ask a software engineer who has been coding and helping release commercial Windows exe based (rich client) applications for over 30 years. And it helps if the engineer you are asking has had extensive experience related to using industry standard practices which are designed to help users keep their computers safe. Your lack of understanding about bad actors out there that are trying to exploit executable code and at what OS level this code can execute, is not helpful to the discussion. Stop acting like you are a 'safe computing expert' when you are not one... especially when you are disparaging solutions that have been put in place to protect you and others despite your own stupidity.
So for DXLab users at this stage of the game... which I am one of them and very happy with the amazing job Dave has and continues to do an amazing job with this free software offering! I'm perfectly happy excluding the default directory location where DXLab exe's are installed from my anti-virus software solution as an exclusion. I'm trusting Dave to not deliver exe based code that is malicious. And even if it pains me so, I'm letting the DXLab installation process install this executable code (that is not digitally signed) in a read/write location.
If you are happy with what you have and have excluded your DXLab installation path from your anti-virus / malware solution's scans, then you can stop reading now... or you probably never made it this far anyway. If you want more of the details as to what the industry standard has been for decades now, keep reading. DXLab has been around so long, it may be hard for Dave to justify a big change (and personal expense to digitally sign things) at this point. I total get that as I have stated above. However, when other users spew out fear, uncertainty and doubt regarding this topic, they should be corrected and their ignorance should be exposed.
Solutions like Windows Defender (a darn good free solution) are designed to protect you despite your, ignorance and laziness. You can give someone a Twenty Dollar Bill for free and then based on their ignorance, they will complain that you didn't give them two Ten Dollar Bills.
For decades now, the industry and creators of commercial operating systems in use in business and at home have tried and tried to make commercial and home computing safer. Linux / Unix based OS's and even MS Windows (make your silly evil sounds and wiggle your fingers in the air), have been trying to get software developers to locate executable code in a OS level protected directory structure. i.e. for Linux it would be /bin, or /usr/bin etc... for Windows it would be C:\Program Files (x86) for 32bit executables, and or C:\Program Files for 64bit executables. Constrains are put in place to protect the executable code in these directories using an OS level of User Access Control to keep code from executing at a 'root' level or administrator level (in the case of windows) where bad / malicious code could do all kinds of bad things... install key loggers to steal you passwords, or execute code to encrypt all your data and hold you hostage to ransomware schemes. Or just help use your computing power and network bandwidth to jump start other evil bad things without you even knowing day after day and week after week.
For the above reasons and many others not even listed, modern OS's and their designers do all they can to try and get software installed into protected areas of the file system and to only be run at levels where other bad code can't do bad things without you knowing. Is it perfect? nope but it's better than nothing and it's better than just burying your head in the sand and turning off all the protection.
So what is a Mother to do? The best practices which have been in place for decades now (and are not enforced with a draconian solution yet) are to install executable code in protected directories like, you guessed it: C:\Program Files etc... AND to locate application down a path specific to data like c:\Documents\YourUserName where read write access to data is based on user privilege's. AND in the case of executable data you digitally sign your executable code with a signature that can be verified by a known good certificate authority. (do a google search on PKI infrastructure if you want to learn more) this is what virus scanning software is looking at when it scan for issues. If the exe code of application A is properly signed and in the proper directories, then it's less likely to report a false positive. (yes a pretty simple description of what is going on)
Older software that has been around for a long time gets a bit of a pass on the above, but users are still required to know what is going on when they trust this software. DXLab applications fall into this category. Exclude the installation paths from virus scan's / malware scans. It's just the way it is right now, and only Dave can decide if the effort and cost is worth it to revamp the install locations and incur the cost of executable code signing into his build routines of the VB application in question, not to mention move all the read/write data to User/Document paths and deal with UAC. The arm flailing and weeping and wailing and gnashing of teeth from existing users of an amazing and free application, would reach an exponential level if they had to move their data around etc.... even if automated in the installer. I shudder at the flood of questions if this change were made and I'm guessing Dave would fear the same thing on the groups.io list here. I certainly don't speak for Dave at all.
An example of another amazing and free Ham related application that has adopted most if not all of the above standards is N1MM Logger+. Multiple developers in this case are coding on the N1MM project. N1MM Logger+ exe's are signed (see the link at the end of this post) and N1MM's installer tries to get you to install the exe's down the proper path in a Windows operating system. However, as we all know... you can override all of this and in effect disable all the efforts to try and protect you from yourself. But there is a cost here... time, money and laborious education. And this requires dealing with a new set of questions from uninformed users.
So, at the end of the day... DXLab users need to understand the current state of how DXLab is coded and how and where it is installed and understand that the exe's are not signed. It's okay if you understand that Dave clearly isn't out to deliver malicious code, but DXLab, like many other older exe based applications install into a directory structure that violates current best practices in the software industry. It's just the nature of the technical debt incurred with an older application that has been around for a long time. Again, I'm not suggesting Dave stop the train and crack this nut. We get the benefit of using DXLab which is an amazing suite of applications written by one super human developer and we just need to understand that the legacy nature of the installation and location of the data and exe's will make it suspect for industry standard virus scanning / malware scanning / bad actor detection software. Stop blaming Windows and modern virus / malware scanning / detection solutions and start understanding and why things were created they way they are.
In the ending of this massive diatribe of mine, executable code on a modern OS needs to be installed in OS / UAC locations and the exe code needs to be signed. Data needs to be installed in OS / UAC controlled locations where read/write is possible for the processes that need access to this data. And all executable code should be signed with a known digital certificate that is trusted by a known certificate authority so you a user knows where the code comes from in the first place. Is it all 100% fool proof? Nope, but it's better to understand how things work rather than spewing out the continued FUD around this ongoing topic.
Image showing the digital signature on the main N1MM exe <http://www.nc7j.com/downloads/N1MM/N1MM%20digital%20signature.png>
http://www.nc7j.com/downloads/N1MM/N1MM%20digital%20signature.png
Max NG7M


Re: Cat control

ve3ki
 

If the "Split Operation" setting in JTDX (assuming it is the same as WSJT-X, which I believe it probably is) is set to "Rig", try changing it to "Fake It". With some radios, and especially when controlling the radio through a separate program like Commander, the switch from RX to TX seems to take much longer when using "Rig" than when using "Fake It". For all I know, the reverse may be true for some other radios, so if you are using "Fake It" already and it is slow, try switching to "Rig" to see whether that improves the response.

73,
Rich VE3KI


On Sun, Apr 12, 2020 at 12:58 PM, <nigee.gardner@...> wrote:
Good morning. I have been using the DXlabs suit for a  while now to control my Icom IC7300. I like it very much. Main use is doing data modes, FT8 PSK31 etc. It has been working well controlling JTDX via Commander. Just lately I have been getting an error message from JTDX saying its lost control, rig error, I click on retry and starts working again. The other thing I noticed is when the transmit period starts the rig isn't being keyed until about 5 or 6 seconds into the cycle. I did initially think it may be RF getting in, but then noticed this error always happened during RX. So, I shut down Commander, reconfigured JTDX to control the rig directly, and all works fine again. So I am assuming theres suddenly and issue between JTDX and Commander?. BTW Commander also works ok standaloan. Any ideas?

73 Nigel G0CQZ


Re: Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

John Kludt
 

All,

Indeed - thank you Dave for your excellent work and our patience with us.

John

On Sun, Apr 12, 2020 at 3:50 PM Jeff Schwartz via groups.io <ki0kb=icloud.com@groups.io> wrote:
I must say I learn more from reading these threads than I got from any computer course in college. Of course back then there were no personal computers. The one thing I do know is that without DX Labs hamming would not be as enjoyable as it is for me and without Windows I couldn't run DX Labs. So on this Covid 19 Easter Sunday I give thanks to both and the ongoing challenges they provide. Thanks for all  you do Dave.
73 Jeff / KI0KB


Re: Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

Jeff Schwartz
 

I must say I learn more from reading these threads than I got from any computer course in college. Of course back then there were no personal computers. The one thing I do know is that without DX Labs hamming would not be as enjoyable as it is for me and without Windows I couldn't run DX Labs. So on this Covid 19 Easter Sunday I give thanks to both and the ongoing challenges they provide. Thanks for all  you do Dave.
73 Jeff / KI0KB


Re: Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

Gilbert Baron W0MN
 

I have to agree but I doubt there is an anti malware application in existence that would not be susceptible to this problem and since defender has only given me this one problem over the years I will stick with it. Free and for the most part as effective as any antivirus can be. I think not running as an admin and effective backups are the real protection even though they are a real pain at times.

Outlook Laptop Gil W0MN
Hierro candente, batir de repente
44.08226N 92.51265W EN34rb

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Sunday, April 12, 2020 13:02
To: DXLab@groups.io
Subject: Re: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

Regarding the lengthy post from Max NG7M appended below,

1. Windows is vulnerable to malware because it fails to implement well-known operating system security measures; correcting this architectural defect would break many existing Windows applications, some of which can no longer be updated because their source code or unique development tools no longer exist. Microsoft has chosen to live with this defect and mitigate it with anti-malware applications, which are provided by many software companies and Microsoft itself.

2. During Microsoft's two unsuccessful attempts to recruit me (once to lead the Visual Studio organization, once to lead the Windows Mobile organization), I interviewed with several senior Windows developers and executives. They acknowledged that "protected folders" and "User Account Control" (UAC) provide little actual security value; these mechanisms were introduced to visibly demonstrate that Microsoft was taking security concerns seriously. "Oh, so you want a secure operating system, do you?" one of them joked.

3. There is no evidence that installing DXLab applications in

c:\Program Files

or digitally signing them would protect them from mis-identification by Microsoft anti-malware applications.

4. Since there is no malware in any DXLab application, Microsoft anti-malware applications that identify them as malware are by definition defective. If you chose to use a defective anti-malware application, enable it to autonomously upgrade itself, and enable it to autonomously quarantine applications it considers malware, then you should not be surprised when one of you applications suddenly stops working.

5. Microsoft's "solution" to their defective anti-malware is to accept submissions of executables incorrectly identified as malware for reconsideration. Over the past several days, multiple attempts to submit the 4.5 megabyte executable for Commander 14.5.5 stalled; the Microsoft submission site was evidently over-subscribed. Last night, the submission site took less than a minute to accept Commander's executable; today, the submission status shows "not malware". How long it will take for this updated determination to reach deployed instances of Windows Defender is anybody's guess. Will this stop the next public version of Commander from being mis-identifed as malware? Unknown.

My inclination at this point is to add Microsoft anti-malware to the list of applications that can interfere with DXLab applications in

<https://www.dxlabsuite.com/dxlabwiki/ApplicationInteference>

Control your computing environment, or it will control you.

73,

Dave, AA6YQ




-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Max NG7M
Sent: Sunday, April 12, 2020 11:53 AM
To: DXLab@groups.io
Subject: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

As we can see, the FUD (Fear, Uncertainty and Doubt) regarding Anti Virus / Anti Malware solutions (MS Defender in this case) have reached a new rhetorical level in regards to DXLab applications / exe's. (based on the number of posts)

First off, I'm not suggesting Dave AA6YQ change anything at this point because the effort would be rather high and the migration of currently installed application exe's to the proper location for a modern day operating system bring a level of complexity along with the change... installer changes and proper use of User Access Control (UAC) would be required along with changes to the installer code used by DXLab (digital signing of exe code etc...). So I'm happy with the way things are and I know that I need to exclude the directory where DXLab applications are installed in my Anti Virus software. So let me make that clear, I'm not complaining or suggesting that Dave do anything to address why this topic keeps coming up over and over and over and over and over again. Well, other than repeating the current solution and referring users to how you need to exclude the DXLab installation path from your anti-virus / anti-malware solution. The bitching and complaining about controls that are put in place to protect you and other users in what is in effect a shared network (the Internet) is rather comical at this point.

If you want to know why DXLab executables are getting identified as having problems, the problem is not Windows Defender or any other anti-virus / malware solution. Identifying Defender as the problem, just exposes your ignorance around this topic. In a nut shell, the problem is where the exe's (any any other executable code like dll's) for DXLab are getting installed along with the fact that the exe's are not digitally signed. If you don't agree, ask a software engineer who has been coding and helping release commercial Windows exe based (rich client) applications for over 30 years. And it helps if the engineer you are asking has had extensive experience related to using industry standard practices which are designed to help users keep their computers safe. Your lack of understanding about bad actors out there that are trying to exploit executable code and at what OS level this code can execute, is not helpful to the discussion. Stop acting like you are a 'safe computing expert' when you are not one... especially when you are disparaging solutions that have been put in place to protect you and others despite your own stupidity.

So for DXLab users at this stage of the game... which I am one of them and very happy with the amazing job Dave has and continues to do an amazing job with this free software offering! I'm perfectly happy excluding the default directory location where DXLab exe's are installed from my anti-virus software solution as an exclusion. I'm trusting Dave to not deliver exe based code that is malicious. And even if it pains me so, I'm letting the DXLab installation process install this executable code (that is not digitally signed) in a read/write location.

If you are happy with what you have and have excluded your DXLab installation path from your anti-virus / malware solution's scans, then you can stop reading now... or you probably never made it this far anyway. If you want more of the details as to what the industry standard has been for decades now, keep reading. DXLab has been around so long, it may be hard for Dave to justify a big change (and personal expense to digitally sign things) at this point. I total get that as I have stated above. However, when other users spew out fear, uncertainty and doubt regarding this topic, they should be corrected and their ignorance should be exposed.

Solutions like Windows Defender (a darn good free solution) are designed to protect you despite your, ignorance and laziness. You can give someone a Twenty Dollar Bill for free and then based on their ignorance, they will complain that you didn't give them two Ten Dollar Bills.

For decades now, the industry and creators of commercial operating systems in use in business and at home have tried and tried to make commercial and home computing safer. Linux / Unix based OS's and even MS Windows (make your silly evil sounds and wiggle your fingers in the air), have been trying to get software developers to locate executable code in a OS level protected directory structure. i.e. for Linux it would be /bin, or /usr/bin etc... for Windows it would be C:\Program Files (x86) for 32bit executables, and or C:\Program Files for 64bit executables. Constrains are put in place to protect the executable code in these directories using an OS level of User Access Control to keep code from executing at a 'root' level or administrator level (in the case of windows) where bad / malicious code could do all kinds of bad things... install key loggers to steal you passwords, or execute code to encrypt all your data and hold you hostage to ransomware schemes. Or just help use your computing power and network bandwidth to jump start other evil bad things without you even knowing day after day and week after week.

For the above reasons and many others not even listed, modern OS's and their designers do all they can to try and get software installed into protected areas of the file system and to only be run at levels where other bad code can't do bad things without you knowing. Is it perfect? nope but it's better than nothing and it's better than just burying your head in the sand and turning off all the protection.

So what is a Mother to do? The best practices which have been in place for decades now (and are not enforced with a draconian solution yet) are to install executable code in protected directories like, you guessed it: C:\Program Files etc... AND to locate application down a path specific to data like c:\Documents\YourUserName where read write access to data is based on user privilege's. AND in the case of executable data you digitally sign your executable code with a signature that can be verified by a known good certificate authority. (do a google search on PKI infrastructure if you want to learn more) this is what virus scanning software is looking at when it scan for issues. If the exe code of application A is properly signed and in the proper directories, then it's less likely to report a false positive. (yes a pretty simple description of what is going on)

Older software that has been around for a long time gets a bit of a pass on the above, but users are still required to know what is going on when they trust this software. DXLab applications fall into this category. Exclude the installation paths from virus scan's / malware scans. It's just the way it is right now, and only Dave can decide if the effort and cost is worth it to revamp the install locations and incur the cost of executable code signing into his build routines of the VB application in question, not to mention move all the read/write data to User/Document paths and deal with UAC. The arm flailing and weeping and wailing and gnashing of teeth from existing users of an amazing and free application, would reach an exponential level if they had to move their data around etc.... even if automated in the installer. I shudder at the flood of questions if this change were made and I'm guessing Dave would fear the same thing on the groups.io list here. I certainly don't speak for Dave at all.

An example of another amazing and free Ham related application that has adopted most if not all of the above standards is N1MM Logger+. Multiple developers in this case are coding on the N1MM project. N1MM Logger+ exe's are signed (see the link at the end of this post) and N1MM's installer tries to get you to install the exe's down the proper path in a Windows operating system. However, as we all know... you can override all of this and in effect disable all the efforts to try and protect you from yourself. But there is a cost here... time, money and laborious education. And this requires dealing with a new set of questions from uninformed users.

So, at the end of the day... DXLab users need to understand the current state of how DXLab is coded and how and where it is installed and understand that the exe's are not signed. It's okay if you understand that Dave clearly isn't out to deliver malicious code, but DXLab, like many other older exe based applications install into a directory structure that violates current best practices in the software industry. It's just the nature of the technical debt incurred with an older application that has been around for a long time. Again, I'm not suggesting Dave stop the train and crack this nut. We get the benefit of using DXLab which is an amazing suite of applications written by one super human developer and we just need to understand that the legacy nature of the installation and location of the data and exe's will make it suspect for industry standard virus scanning / malware scanning / bad actor detection software. Stop blaming Windows and modern virus / malware scanning / detection solutions and start understanding and why things were created they way they are.

In the ending of this massive diatribe of mine, executable code on a modern OS needs to be installed in OS / UAC locations and the exe code needs to be signed. Data needs to be installed in OS / UAC controlled locations where read/write is possible for the processes that need access to this data. And all executable code should be signed with a known digital certificate that is trusted by a known certificate authority so you a user knows where the code comes from in the first place. Is it all 100% fool proof? Nope, but it's better to understand how things work rather than spewing out the continued FUD around this ongoing topic.

Image showing the digital signature on the main N1MM exe <http://www.nc7j.com/downloads/N1MM/N1MM%20digital%20signature.png>
http://www.nc7j.com/downloads/N1MM/N1MM%20digital%20signature.png

Max NG7M







--
W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop


Re: Cat control

Dave AA6YQ
 

+ AA6YQ comments below

Good morning. I have been using the DXlabs suit for a while now to control my Icom IC7300. I like it very much. Main use is doing data modes, FT8 PSK31 etc. It has been working well controlling JTDX via Commander. Just lately I have been getting an error message from JTDX saying its lost control, rig error, I click on retry and starts working again. The other thing I noticed is when the transmit period starts the rig isn't being keyed until about 5 or 6 seconds into the cycle. I did initially think it may be RF getting in, but then noticed this error always happened during RX. So, I shut down Commander, reconfigured JTDX to control the rig directly, and all works fine again. So I am assuming theres suddenly and issue between JTDX and Commander?. BTW Commander also works ok standaloan. Any ideas?

+ I know little about JTDX beyond the fact that it is a hostile fork of WSJT-X., which can use Commander's TCP API to control and track your transceiver. I suggest that you forward your report to the JTDX support organization. If they need my assistance in resolving it, I will be happy to provide it.

73,

Dave, AA6YQ


Re: Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

Dave AA6YQ
 

Regarding the lengthy post from Max NG7M appended below,

1. Windows is vulnerable to malware because it fails to implement well-known operating system security measures; correcting this architectural defect would break many existing Windows applications, some of which can no longer be updated because their source code or unique development tools no longer exist. Microsoft has chosen to live with this defect and mitigate it with anti-malware applications, which are provided by many software companies and Microsoft itself.

2. During Microsoft's two unsuccessful attempts to recruit me (once to lead the Visual Studio organization, once to lead the Windows Mobile organization), I interviewed with several senior Windows developers and executives. They acknowledged that "protected folders" and "User Account Control" (UAC) provide little actual security value; these mechanisms were introduced to visibly demonstrate that Microsoft was taking security concerns seriously. "Oh, so you want a secure operating system, do you?" one of them joked.

3. There is no evidence that installing DXLab applications in

c:\Program Files

or digitally signing them would protect them from mis-identification by Microsoft anti-malware applications.

4. Since there is no malware in any DXLab application, Microsoft anti-malware applications that identify them as malware are by definition defective. If you chose to use a defective anti-malware application, enable it to autonomously upgrade itself, and enable it to autonomously quarantine applications it considers malware, then you should not be surprised when one of you applications suddenly stops working.

5. Microsoft's "solution" to their defective anti-malware is to accept submissions of executables incorrectly identified as malware for reconsideration. Over the past several days, multiple attempts to submit the 4.5 megabyte executable for Commander 14.5.5 stalled; the Microsoft submission site was evidently over-subscribed. Last night, the submission site took less than a minute to accept Commander's executable; today, the submission status shows "not malware". How long it will take for this updated determination to reach deployed instances of Windows Defender is anybody's guess. Will this stop the next public version of Commander from being mis-identifed as malware? Unknown.

My inclination at this point is to add Microsoft anti-malware to the list of applications that can interfere with DXLab applications in

<https://www.dxlabsuite.com/dxlabwiki/ApplicationInteference>

Control your computing environment, or it will control you.

73,

Dave, AA6YQ

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Max NG7M
Sent: Sunday, April 12, 2020 11:53 AM
To: DXLab@groups.io
Subject: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

As we can see, the FUD (Fear, Uncertainty and Doubt) regarding Anti Virus / Anti Malware solutions (MS Defender in this case) have reached a new rhetorical level in regards to DXLab applications / exe's. (based on the number of posts)

First off, I'm not suggesting Dave AA6YQ change anything at this point because the effort would be rather high and the migration of currently installed application exe's to the proper location for a modern day operating system bring a level of complexity along with the change... installer changes and proper use of User Access Control (UAC) would be required along with changes to the installer code used by DXLab (digital signing of exe code etc...). So I'm happy with the way things are and I know that I need to exclude the directory where DXLab applications are installed in my Anti Virus software. So let me make that clear, I'm not complaining or suggesting that Dave do anything to address why this topic keeps coming up over and over and over and over and over again. Well, other than repeating the current solution and referring users to how you need to exclude the DXLab installation path from your anti-virus / anti-malware solution. The bitching and complaining about controls that are put in place to protect you and other users in what is in effect a shared network (the Internet) is rather comical at this point.

If you want to know why DXLab executables are getting identified as having problems, the problem is not Windows Defender or any other anti-virus / malware solution. Identifying Defender as the problem, just exposes your ignorance around this topic. In a nut shell, the problem is where the exe's (any any other executable code like dll's) for DXLab are getting installed along with the fact that the exe's are not digitally signed. If you don't agree, ask a software engineer who has been coding and helping release commercial Windows exe based (rich client) applications for over 30 years. And it helps if the engineer you are asking has had extensive experience related to using industry standard practices which are designed to help users keep their computers safe. Your lack of understanding about bad actors out there that are trying to exploit executable code and at what OS level this code can execute, is not helpful to the discussion. Stop acting like you are a 'safe computing expert' when you are not one... especially when you are disparaging solutions that have been put in place to protect you and others despite your own stupidity.

So for DXLab users at this stage of the game... which I am one of them and very happy with the amazing job Dave has and continues to do an amazing job with this free software offering! I'm perfectly happy excluding the default directory location where DXLab exe's are installed from my anti-virus software solution as an exclusion. I'm trusting Dave to not deliver exe based code that is malicious. And even if it pains me so, I'm letting the DXLab installation process install this executable code (that is not digitally signed) in a read/write location.

If you are happy with what you have and have excluded your DXLab installation path from your anti-virus / malware solution's scans, then you can stop reading now... or you probably never made it this far anyway. If you want more of the details as to what the industry standard has been for decades now, keep reading. DXLab has been around so long, it may be hard for Dave to justify a big change (and personal expense to digitally sign things) at this point. I total get that as I have stated above. However, when other users spew out fear, uncertainty and doubt regarding this topic, they should be corrected and their ignorance should be exposed.

Solutions like Windows Defender (a darn good free solution) are designed to protect you despite your, ignorance and laziness. You can give someone a Twenty Dollar Bill for free and then based on their ignorance, they will complain that you didn't give them two Ten Dollar Bills.

For decades now, the industry and creators of commercial operating systems in use in business and at home have tried and tried to make commercial and home computing safer. Linux / Unix based OS's and even MS Windows (make your silly evil sounds and wiggle your fingers in the air), have been trying to get software developers to locate executable code in a OS level protected directory structure. i.e. for Linux it would be /bin, or /usr/bin etc... for Windows it would be C:\Program Files (x86) for 32bit executables, and or C:\Program Files for 64bit executables. Constrains are put in place to protect the executable code in these directories using an OS level of User Access Control to keep code from executing at a 'root' level or administrator level (in the case of windows) where bad / malicious code could do all kinds of bad things... install key loggers to steal you passwords, or execute code to encrypt all your data and hold you hostage to ransomware schemes. Or just help use your computing power and network bandwidth to jump start other evil bad things without you even knowing day after day and week after week.

For the above reasons and many others not even listed, modern OS's and their designers do all they can to try and get software installed into protected areas of the file system and to only be run at levels where other bad code can't do bad things without you knowing. Is it perfect? nope but it's better than nothing and it's better than just burying your head in the sand and turning off all the protection.

So what is a Mother to do? The best practices which have been in place for decades now (and are not enforced with a draconian solution yet) are to install executable code in protected directories like, you guessed it: C:\Program Files etc... AND to locate application down a path specific to data like c:\Documents\YourUserName where read write access to data is based on user privilege's. AND in the case of executable data you digitally sign your executable code with a signature that can be verified by a known good certificate authority. (do a google search on PKI infrastructure if you want to learn more) this is what virus scanning software is looking at when it scan for issues. If the exe code of application A is properly signed and in the proper directories, then it's less likely to report a false positive. (yes a pretty simple description of what is going on)

Older software that has been around for a long time gets a bit of a pass on the above, but users are still required to know what is going on when they trust this software. DXLab applications fall into this category. Exclude the installation paths from virus scan's / malware scans. It's just the way it is right now, and only Dave can decide if the effort and cost is worth it to revamp the install locations and incur the cost of executable code signing into his build routines of the VB application in question, not to mention move all the read/write data to User/Document paths and deal with UAC. The arm flailing and weeping and wailing and gnashing of teeth from existing users of an amazing and free application, would reach an exponential level if they had to move their data around etc.... even if automated in the installer. I shudder at the flood of questions if this change were made and I'm guessing Dave would fear the same thing on the groups.io list here. I certainly don't speak for Dave at all.

An example of another amazing and free Ham related application that has adopted most if not all of the above standards is N1MM Logger+. Multiple developers in this case are coding on the N1MM project. N1MM Logger+ exe's are signed (see the link at the end of this post) and N1MM's installer tries to get you to install the exe's down the proper path in a Windows operating system. However, as we all know... you can override all of this and in effect disable all the efforts to try and protect you from yourself. But there is a cost here... time, money and laborious education. And this requires dealing with a new set of questions from uninformed users.

So, at the end of the day... DXLab users need to understand the current state of how DXLab is coded and how and where it is installed and understand that the exe's are not signed. It's okay if you understand that Dave clearly isn't out to deliver malicious code, but DXLab, like many other older exe based applications install into a directory structure that violates current best practices in the software industry. It's just the nature of the technical debt incurred with an older application that has been around for a long time. Again, I'm not suggesting Dave stop the train and crack this nut. We get the benefit of using DXLab which is an amazing suite of applications written by one super human developer and we just need to understand that the legacy nature of the installation and location of the data and exe's will make it suspect for industry standard virus scanning / malware scanning / bad actor detection software. Stop blaming Windows and modern virus / malware scanning / detection solutions and start understanding and why things were created they way they are.

In the ending of this massive diatribe of mine, executable code on a modern OS needs to be installed in OS / UAC locations and the exe code needs to be signed. Data needs to be installed in OS / UAC controlled locations where read/write is possible for the processes that need access to this data. And all executable code should be signed with a known digital certificate that is trusted by a known certificate authority so you a user knows where the code comes from in the first place. Is it all 100% fool proof? Nope, but it's better to understand how things work rather than spewing out the continued FUD around this ongoing topic.

Image showing the digital signature on the main N1MM exe <http://www.nc7j.com/downloads/N1MM/N1MM%20digital%20signature.png>
http://www.nc7j.com/downloads/N1MM/N1MM%20digital%20signature.png

Max NG7M


Re: Cat control

Gilbert Baron W0MN
 

I do not know what is happening but I do not have either problem here. I have seen the lost control error but that is only if I turn off the rig before terminating DxKeeper and doing the retry get all working again.

 

I am using a TS90-SG and if you are using something else I do not know if that is part of your experience with the code. Obviously hard to make a QSO if you are 5 or 6 seconds off.

 

Outlook Laptop Gil W0MN

Hierro candente, batir de repente

44.08226N 92.51265W EN34rb

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of nigee.gardner@...
Sent: Sunday, April 12, 2020 06:26
To: DXLab@groups.io
Subject: [DXLab] Cat control

 

Good morning. I have been using the DXlabs suit for a  while now to control my Icom IC7300. I like it very much. Main use is doing data modes, FT8 PSK31 etc. It has been working well controlling JTDX via Commander. Just lately I have been getting an error message from JTDX saying its lost control, rig error, I click on retry and starts working again. The other thing I noticed is when the transmit period starts the rig isn't being keyed until about 5 or 6 seconds into the cycle. I did initially think it may be RF getting in, but then noticed this error always happened during RX. So, I shut down Commander, reconfigured JTDX to control the rig directly, and all works fine again. So I am assuming theres suddenly and issue between JTDX and Commander?. BTW Commander also works ok standaloan. Any ideas?

73 Nigel G0CQZ


--

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop


Cat control

Nigel
 

Good morning. I have been using the DXlabs suit for a  while now to control my Icom IC7300. I like it very much. Main use is doing data modes, FT8 PSK31 etc. It has been working well controlling JTDX via Commander. Just lately I have been getting an error message from JTDX saying its lost control, rig error, I click on retry and starts working again. The other thing I noticed is when the transmit period starts the rig isn't being keyed until about 5 or 6 seconds into the cycle. I did initially think it may be RF getting in, but then noticed this error always happened during RX. So, I shut down Commander, reconfigured JTDX to control the rig directly, and all works fine again. So I am assuming theres suddenly and issue between JTDX and Commander?. BTW Commander also works ok standaloan. Any ideas?

73 Nigel G0CQZ


Re: Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

Salvatore Besso
 

NOD32, no fear and you forget it.

73 de
Salvatore (I4FYV)


Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

Max NG7M
 

As we can see, the FUD (Fear, Uncertainty and Doubt) regarding Anti Virus / Anti Malware solutions (MS Defender in this case) have reached a new rhetorical level in regards to DXLab applications / exe's. (based on the number of posts)

First off, I'm not suggesting Dave AA6YQ change anything at this point because the effort would be rather high and the migration of currently installed application exe's to the proper location for a modern day operating system bring a level of complexity along with the change... installer changes and proper use of User Access Control (UAC) would be required along with changes to the installer code used by DXLab (digital signing of exe code etc...).  So I'm happy with the way things are and I know that I need to exclude the directory where DXLab applications are installed in my Anti Virus software.  So let me make that clear, I'm not complaining or suggesting that Dave do anything to address why this topic keeps coming up over and over and over and over and over again. Well, other than repeating the current solution and referring users to how you need to exclude the DXLab installation path from your anti-virus / anti-malware solution. The bitching and complaining about controls that are put in place to protect you and other users in what is in effect a shared network (the Internet) is rather comical at this point.

If you want to know why DXLab executables are getting identified as having problems, the problem is not Windows Defender or any other anti-virus / malware solution.  Identifying Defender as the problem, just exposes your ignorance around this topic. In a nut shell, the problem is where the exe's (any any other executable code like dll's) for DXLab are getting installed along with the fact that the exe's are not digitally signed.  If you don't agree, ask a software engineer who has been coding and helping release commercial Windows exe based (rich client) applications for over 30 years.  And it helps if the engineer you are asking has had extensive experience related to using industry standard practices which are designed to help users keep their computers safe. Your lack of understanding about bad actors out there that are trying to exploit executable code and at what OS level this code can execute, is not helpful to the discussion.  Stop acting like you are a 'safe computing expert' when you are not one... especially when you are disparaging solutions that have been put in place to protect you and others despite your own stupidity. 

So for DXLab users at this stage of the game... which I am one of them and very happy with the amazing job Dave has and continues to do an amazing job with this free software offering!  I'm perfectly happy excluding the default directory location where DXLab exe's are installed from my anti-virus software solution as an exclusion.  I'm trusting Dave to not deliver exe based code that is malicious. And even if it pains me so, I'm letting the DXLab installation process install this executable code (that is not digitally signed) in a read/write location.

If you are happy with what you have and have excluded your DXLab installation path from your anti-virus / malware solution's scans, then you can stop reading now... or you probably never made it this far anyway.  If you want more of the details as to what the industry standard has been for decades now, keep reading.  DXLab has been around so long, it may be hard for Dave to justify a big change (and personal expense to digitally sign things) at this point.  I total get that as I have stated above. However, when other users spew out fear, uncertainty and doubt regarding this topic, they should be corrected and their ignorance should be exposed. 

Solutions like Windows Defender (a darn good free solution) are designed to protect you despite your, ignorance and laziness.  You can give someone a Twenty Dollar Bill for free and then based on their ignorance, they will complain that you didn't give them two Ten Dollar Bills.

For decades now, the industry and creators of commercial operating systems in use in business and at home have tried and tried to make commercial and home computing safer. Linux / Unix based OS's and even MS Windows (make your silly evil sounds and wiggle your fingers in the air), have been trying to get software developers to locate executable code in a OS level protected directory structure.  i.e. for Linux it would be /bin, or /usr/bin etc... for Windows it would be C:\Program Files (x86) for 32bit executables, and or C:\Program Files for 64bit executables.  Constrains are put in place to protect the executable code in these directories using an OS level of User Access Control to keep code from executing at a 'root' level or administrator level (in the case of windows) where bad / malicious code could do all kinds of bad things... install key loggers to steal you passwords, or execute code to encrypt all your data and hold you hostage to ransomware schemes.  Or just help use your computing power and network bandwidth to jump start other evil bad things without you even knowing day after day and week after week.

For the above reasons and many others not even listed, modern OS's and their designers do all they can to try and get software installed into protected areas of the file system and to only be run at levels where other bad code can't do bad things without you knowing.  Is it perfect?  nope but it's better than nothing and it's better than just burying your head in the sand and turning off all the protection.

So what is a Mother to do?  The best practices which have been in place for decades now (and are not enforced with a draconian solution yet) are to install executable code in protected directories like, you guessed it: C:\Program Files etc... AND to locate application down a path specific to data like c:\Documents\YourUserName where read write access to data is based on user privilege's.   AND in the case of executable data you digitally sign your executable code with a signature that can be verified by a known good certificate authority. (do a google search on PKI infrastructure if you want to learn more)  this is what virus scanning software is looking at when it scan for issues.  If the exe code of application A is properly signed and in the proper directories, then it's less likely to report a false positive. (yes a pretty simple description of what is going on)

Older software that has been around for a long time gets a bit of a pass on the above, but users are still required to know what is going on when they trust this software.  DXLab applications fall into this category.  Exclude the installation paths from virus scan's / malware scans.  It's just the way it is right now, and only Dave can decide if the effort and cost is worth it to revamp the install locations and incur the cost of executable code signing into his build routines of the VB application in question, not to mention move all the read/write data to User/Document paths and deal with UAC.  The arm flailing and weeping and wailing and gnashing of teeth from existing users of an amazing and free application, would reach an exponential level if they had to move their data around etc.... even if automated in the installer.  I shudder at the flood of questions if this change were made and I'm guessing Dave would fear the same thing on the groups.io list here.  I certainly don't speak for Dave at all.

An example of another amazing and free Ham related application that has adopted most if not all of the above standards is N1MM Logger+.  Multiple developers in this case are coding on the N1MM project. N1MM Logger+ exe's are signed (see the link at the end of this post) and N1MM's installer tries to get you to install the exe's down the proper path in a Windows operating system.  However, as we all know... you can override all of this and in effect disable all the efforts to try and protect you from yourself.  But there is a cost here... time, money and laborious education.  And this requires dealing with a new set of questions from uninformed users.

So, at the end of the day... DXLab users need to understand the current state of how DXLab is coded and how and where it is installed and understand that the exe's are not signed.  It's okay if you understand that Dave clearly isn't out to deliver malicious code, but DXLab, like many other older exe based applications install into a directory structure that violates current best practices in the software industry.  It's just the nature of the technical debt incurred with an older application that has been around for a long time. Again, I'm not suggesting Dave stop the train and crack this nut.  We get the benefit of using DXLab which is an amazing suite of applications written by one super human developer and we just need to understand that the legacy nature of the installation and location of the data and exe's will make it suspect for industry standard virus scanning / malware scanning / bad actor detection software. Stop blaming Windows and modern virus / malware scanning / detection solutions and start understanding and why things were created they way they are.

In the ending of this massive diatribe of mine, executable code on a modern OS needs to be installed in OS / UAC locations and the exe code needs to be signed.  Data needs to be installed in OS / UAC controlled locations where read/write is possible for the processes that need access to this data.  And all executable code should be signed with a known digital certificate that is trusted by a known certificate authority so you a user knows where the code comes from in the first place.  Is it all 100% fool proof?  Nope, but it's better to understand how things work rather than spewing out the continued FUD around this ongoing topic.

Image showing the digital signature on the main N1MM exe
http://www.nc7j.com/downloads/N1MM/N1MM%20digital%20signature.png

Max NG7M  

 


Re: Windows Defender

wb6bee
 

https://groups.io/g/DXLab/message/192460

Worked for me.  Second section.

Don
WB6BEE