Malware Warning for Windows & Mac

      No Comments on Malware Warning for Windows & Mac

I have encountered two malware situations regarding software that my students are using. I might have called these viruses but it is most likely due to being tricked into downloading and running a program without knowing the harm it will do. I also want to point out an anti-virus program that should never be used.

Let’s begin with an unusual target, the Apple Macintosh. A student working on a exercise that required searching with Google could not get the expected results. When they shared their screen I noticed that in Safari and in Chrome that when a search string was entered into the address bar the string was rewritten with a prefix that read “search baron” and the search engine used was Bing and not Google. In both browsers the default search engine was Google. Search Baron is a recognized piece of malware that redirects all searches to Bing so that its authors can receive payments from Microsoft. True, Microsoft will pay you to use Bing. For this student the workaround was to go to and enter the search string in the search field on the page and not the address bar. If you see Search Baron on your Mac you must remove it. You will have to research how to do this on a Mac.

Next up is a Windows problem. Two of the 39 students I have in a course downloaded a zip file of a web server. These two students were unable to run the server and the error messages implied that files were missing. When working with one student we noticed that when we unzipped the file after downloading it, Windows Security briefly displayed a message declaring that it found a trojan script. The warning was quite brief and when we looked at Windows Security it showed no current threats. When we looked at the threat history we found the problem. When the file was being unzipped Windows Security spotted a problem it named trojan:script/Foretype.a!ml. As far as we could tell, in cleaning out this threat it also blocked certain files from being unzipped.

A scan of the student’s computer with Windows Security revealed nothing. The student then downloaded and ran the MalwareBytes scanner and it uncovered an issue with a Chrome plugin. The student deleted the plugin. The student then switched to FireFox to download the zip file and it unzipped successfully and the server ran without incident. I have asked the student to use Chrome again, now that the extension is supposed to be gone, to verify that this extension was the problem. I will update this post once I hear from the student.

I will finish this post with a warning about one of the free anti-virus scanners. This scanner is frequently attached to freeware and requires that you opt out, something too many users miss, otherwise it is installed. Last semester I needed to ban this anti virus program because it blocked the Java keystore so that SSH keys, in our case for Gmail, could not be found. The program is called Avast. Please warn students and developers against ever using this anti-virus scanner.

UPDATE 2021-02-05

Two students expressed the Windows trojan issue. Student number one is discussed in the blog. Student number two ran MalwareBytes but they were told that the trojan script was hiding in their installation of FileZilla, a widely used SSH client. The script was cleaned out by MalwareBytes and a fresh download of the software, downloaded with the existing installation of Chrome, unzipped without any issues and the software functioned properly. Conclusion, the source of the trojan script may be widespread but where it came from remains unknown.

It Works On My Machine

      No Comments on It Works On My Machine

As a developer the worst 5 words that can ever come from your mouth is “It Works On My Machine”. Your code works, passes all its tests, but when the client runs it the code fails in some way and you can’t replicate the problem.

No need to wait for a conclusion before the story. Its your fault. Get used to it. It is unlikely that you have discovered a bug in Java or any language you are using. No need to waste time googling “Bugs in Java”. Look at your code, its your fault.

I had such an experience and thanks to the eagle eyes of one of my students the error was found quickly. Here is what happened.

I asked my students to run sample code that will send and receive a plain text email using the Jodd Email library. This program was initially written in 2015 but had not been updated since then. When I reviewed it for use this semester, I had to deal with changes to the Jodd API. Nothing serious, just annoying. With the changes made I ran the code. It only uses a unit test to send and receive. Success, it worked, and so I pushed the update to the repository and told my students about it.

It did not take long to get a report about the unit test failing. How could this be? I ran the code again and it worked fine for me “on my machine”. This is where a student spotted the problem. In the unit test I had a line that read:


I had used a literal string to define the To: field. The problem was that this address was going to be different for every student as they were told to use their Gmail accounts. The repo had my Gmail credentials removed. By neglecting this line I had a program that could only pass its test if it’s To: field read “” which is what I used. Therefore, it always worked on my machine.

The fix was easy. The new line reads:


Case closed. Another case of “It works on my machine” resolved.