Date   

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


Re: Windows Defender

Mike Kasrich
 

Just restore the file defender checks and save on the reinstall

On 4/12/2020 9:13 AM, Bob Lukaszewski wrote:

 

As of Friday it seems my window defender doesn’t like DXKeeper running on my machine.  I have had to reinstall it three times and every time I do the defender pops up and says that the infected files are being removed.  After getting my backup of the database and re-installing it, it does the same thing.  It starts with 71.9 Archive then installed update 15.4.9.

 

I stopped the real time protection and it stays installed.

 

Am I missing something, this has been working flawlessly for a couple years on this machine.

 

Thanks

 

Bob K4HA


Re: Windows Defender

g4wjs
 

On 12/04/2020 14:13, Bob Lukaszewski wrote:

As of Friday it seems my window defender doesn’t like DXKeeper running on my machine.  I have had to reinstall it three times and every time I do the defender pops up and says that the infected files are being removed.  After getting my backup of the database and re-installing it, it does the same thing.  It starts with 71.9 Archive then installed update 15.4.9.

 

I stopped the real time protection and it stays installed.

 

Am I missing something, this has been working flawlessly for a couple years on this machine.

 

Thanks

 

Bob K4HA

Bob,

you are missing the numerous posts here about recent Windows Defender actions on some DX Lab Suite applications. The minimum you should do is to open Defender, go to History, view quarantined items, select the entry for DXKeeper, and restore it.

You can also make an exception in Defender to exclude the directory where you have DX Lab Suite applications installed. This is optional depending on how you feel about limiting the actions of your AV product.


--
73

Bill

G4WJS.


Windows Defender

Bob Lukaszewski
 

 

As of Friday it seems my window defender doesn’t like DXKeeper running on my machine.  I have had to reinstall it three times and every time I do the defender pops up and says that the infected files are being removed.  After getting my backup of the database and re-installing it, it does the same thing.  It starts with 71.9 Archive then installed update 15.4.9.

 

I stopped the real time protection and it stays installed.

 

Am I missing something, this has been working flawlessly for a couple years on this machine.

 

Thanks

 

Bob K4HA


Re: Clublog Upload TImeout

ND9G Mike
 

No this isn't normal. Even with the shift in computing resources on the Club Log side, they are still processing the normal workload, it just takes longer. I've uploaded numerous times since the announcements. I just did another upload and it went fine.

73,
Mike ND9G


On Sun, Apr 12, 2020 at 7:24 AM Sherman Banks <w4atl@...> wrote:
I've been getting the "the connection with ClubLog terminated before the upload completed" message when trying to upload to Clublog. Is this normal until the Clublog servers get back to normal from doing the CoVID-19 research?

From the ErrorLog.txt

2020-04-12 11:44:48.137 > ClubLogModule.UploadFile: upload initiated
2020-04-12 11:44:48.138 > ClubLogModule.UploadFile: OperationCompleted = false in upload completion loop
2020-04-12 11:44:48.138 > ClubLogModule.HandleInetStateChange, theState = 3(Connecting), OperationCompleted = False
2020-04-12 11:44:48.139 > ClubLogModule.HandleInetStateChange: connecting to Club Log host
2020-04-12 11:44:48.140 > ClubLogModule.UploadFile: OperationCompleted = false in upload completion loop
2020-04-12 11:44:48.141 > ClubLogModule.UploadFile: OperationCompleted = false in upload completion loop


Clublog Upload TImeout

Sherman Banks
 

I've been getting the "the connection with ClubLog terminated before the upload completed" message when trying to upload to Clublog. Is this normal until the Clublog servers get back to normal from doing the CoVID-19 research?

From the ErrorLog.txt

2020-04-12 11:44:48.137 > ClubLogModule.UploadFile: upload initiated
2020-04-12 11:44:48.138 > ClubLogModule.UploadFile: OperationCompleted = false in upload completion loop
2020-04-12 11:44:48.138 > ClubLogModule.HandleInetStateChange, theState = 3(Connecting), OperationCompleted = False
2020-04-12 11:44:48.139 > ClubLogModule.HandleInetStateChange: connecting to Club Log host
2020-04-12 11:44:48.140 > ClubLogModule.UploadFile: OperationCompleted = false in upload completion loop
2020-04-12 11:44:48.141 > ClubLogModule.UploadFile: OperationCompleted = false in upload completion loop


Re: Prop View

Sherman Banks
 

I fixed my problem with Propview accessing data by  
  • Opening Windows Defender Firewall
  • Click Allow an app or feature through Windows Defender Firewall
  • Change Settings
  • Allow another App...
  • Enter your path to Propview
Reboot the computer.


Re: Lost Commander

Dave AA6YQ
 

+ AA6YQ comments below

On Sat, Apr 11, 2020 at 05:01 PM, Robie wrote:

Your virus protection software has quarantined Commander.  Most likely you use MS Defender.  A recent change has made this package identify Commander as containing a virus.  Search the archives and you will find the solution to this issue. I has been discussed extensively over the past 10 days

+ Recovery instructions are here:

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

     73,

            Dave, AA6YQ