Scummy Scammers

Yesterday morning I received an email claiming to come from a “WannaCry Hack Team”. WannaCry, you may remember, is the name of the cryptographic malware that locked away files on hundreds of thousands of computers worldwide.

Here is the text of the email I received:-

“Hello! WannaCry is back! All your devices were hacked with our program installed on them. We have perfected operation of our program, so you will not be able to restore your data after the attack.
All the information will be encrypted and then erased. Antivirus software will not be able to detect our program, while firewalls will be marrowless against our unique code.
Should your files be encrypted, you will lose them forever.
Our program also covers the local network, erasing data on all network-connected computers and remote servers, all cloud-stored data, and freezing website operation. We have already deployed our program on your devices.
Deletion of your data will take place on June 22, 2018, at 5:00 – 10:00 PM. All data stored on your computers, servers, and mobile devices will be destroyed. Devices working on any version of Windows, iOS, macOS, Android, and Linux are subject to data erasion.
So as to ensure against data demolition, you can pay 0.1 BTC (~$650) to the bitcoin wallet:16xFDaKkqZ7KMJbUu3aA8ZjMYF3GBywmWw
You must pay at the proper time and notify us about the payment via email until 5:00 PM on June 22, 2018. After payment confirmation, we will send you instructions on how to avoid data erasion and such situations at any time thereafter. In case you try to delete our program yourself, data erasion will commence shortly.
To pay with bitcoins, please use localbitcoins.com or other similar platforms, or just google for other means. After payment write to us: support_wc@bitmessage.ch “

To be clear, this is utter garbage.

WannCry, once it is active, puts up a very large, very clear “lock screen” when a user switches on their computer. You can see an example of it here.

It looks as though this email was being sent in the hope that it could act as a confidence trick… to fool people into sending money to a random bitcoin wallet.

In the event that you get either an email or a warning message on your computer, can I suggest that the first thing that you do is reach out to a computer specialist that you trust, and get them to take a look. It would seem that we’re now moving in to time where people are using psychological tricks into separating you from your cash.

Be careful!

Update: confirmed scam. See here. Bastards.

When It Ain’t Broke – systemd and Unavailable Drives

I’ve been using Mint Linux since some time in late 2013, early 2014, when I saw what a complete and utter disaster ubuntu were making of their distro with the 12.10 and later releases.

I’d been using ubuntu since some time in mid-2005, experimenting with 5.04 Hoary Hedgehog before getting serious with 5.10 Breezy Badger.

Prior to that I had used Mandrake Linux [a Red-Hat based distro] which eventually merged with the Brazilian Connectiva to form Mandriva, but which ultimately whithered and died.

And before that I’d actually bought one of the first packaged versions of Red Hat (2.1 Bluesky, which shipped in 1995 and ran kernel 1.2.13…

So: a while…

I’m a fan of Mint; they have worked hard to take all that is good about ubuntu, but drop the horrible succession of ubuntu desktops [starting with Unity] and made a clean, simple, solution.

All has been well in Mint world. At least, mostly. I first downloaded [and still have the ISO for] “Maya” (Mint 13, released May23rd, 2012) and got terrific stability from all versions up to Mint 17.3, Rosa, released on December 4th, 2016. Then things got weird.

The next major release of Mint (18.0/Sarah, 18.1/Serena and 18.2/Sonya) were all desperately unreliable and buggy [for me, at least]. It turns out that chief among the problems with this latest edition were changes brought by the introduction of systemd, a component of the system which manages the boot process.

Rather than follow the traditional unix philosophy of writing “small, sharp tools”, which “do one thing, but do it well”, the designers of systemd have produced a godawful mess of bloatware that makes a mess of lots of things. It writes binary logs [so if you’re system won’t boot, you need special tools to parse log files]; it over-rides audio settings [because it knows better than you do where your speakers are connected]; and it has unilaterally changed the way that a booting system interprets the contents of the “fstab” file system table file…

In simple terms, if you have a machine which expects to mount a remote nfs partition, systemd will deem that to be “mandatory” unless you tell it otherwise, in complete contradiction to the way that sysvinit [ the old boot manager] works. Which means that migration from sysvinit to systemd requires you to figure out and then edit a bunch of changes in to various configuration files.

Because, of course, the authors of systemd refused to interpret configuration file parameters “as they had been written” and instead unilaterally decided that earlier interpretations of parameters “were wrong” and that they would just fix everything. OK, a tidy-up is understandable. IF said tidy-up comes with a warning, a migration tool, or useful hints. Nope. Zip. Zilch. Nada. Nothing.

You go figure it out. Your computer, meanwhile, won’t boot if any of your declared file systems are missing. Rather than “boot with error message”, the new model is “don’t boot”. Rather than warn you that your file system config needs to be amended, the new model is “go screw yourself.”

for anyone struggling with this issue, the answer is to insert the following text into the parameters of the fstab mount string:-

nofail,x-systemd.device-timeout=5

such that,

192.168.1.41:Public /media/459 nfs rw,hard,intr 0 2

changes to look like this…

192.168.1.41:Public /media/459 nfs rw,hard,intr,nofail,      x-systemd.device-timeout=5 0 2

 

Pop Quiz: When Is An Error Message Not An Error Message?

Answer: when it is a complete and utter pack of lies.

Yes, this is about Microsoft. How did you guess?

Back in 2012, after an Apple Time Capsule I’d previously purchased decided to die on me, I got serious about my data and purchased a QNAP TS459 Pro II NAS box. This turned out to be such a wise investment that I subsequently purchased a larger TS-670 and now use that as my “main” network storage device, with the original serving as a “daily backup” server for critical files, with a 7-generation set of backup scripts running at 02:00 every morning…

Peachy.

Except. Any time I try and open any Microsoft Office file that has macros in it, where that file is stored on a NAS, I get a little “warning strip” with a scary-looking message about the dangers of macro viruses. Never used to. This is another one of those Microsoft “improvements”.

Because I can just click the “OK” button and make the problem go away, I’ve ignored it for a while. This might have something to do with my reporting the issue to Microsoft [when I upgraded to Office 2016 for the princely sum of £389] and being told that although they couldn’t offer me the solution for free, I could buy the fix off of them.

Wait, what? No. Just: no.

Being a stubborn so-and-so, I’ve been returning to this problem from time to time, trying to figure out what needs to be done to fix it. This evening I was trawling the web, looking for suggestions, when I found this thread. Buried in there was a post from “philbo2112” [obviously a keen Rush fan] who suggested that the problem could be fixed by right-clicking on Access and selecting “Run as Administrator”.

Well, not quite. However, after doing this and then attempting once more to navigate my way through the Office “Trust Center” and “Trusted Locations”, I discovered that, as “Administrator”, I was no longer able to “see” my network-mapped drives that connect my desktop to my NAS boxes…

Meh. I’ll just use Network Browse and go in that way… And – there was the solution to the problem. Going in “the long way”, revealed that CIFS required the full [canonical?] path name of

\\NAS1\Public\Data\Office Files\

when, of course, Windows Explorer would show the exact same thing as

\\NAS1\Data\Office Files\

The “name of the share” [i.e. “Public”] is “lost” by Windows Explorer once the mapping is made. So… it turns out that all I had to do was hand-hack the path name back to the fill value and that looks to have solved the problem.

Clearly, the programmer[s] who wrote “Windows Explorer” felt they were being helpful by hiding/masking the name of the network share to which my network drive was being mapped. The programmer[s] who wrote the code for Office Trust Center were somewhat more pedantic and wanted the full network path to be explicitly recorded.

If these two products had been written by different vendors, you could sort-of understand how this might have happened. [i.e. because the OS vendor had failed to give clear guidelines on the mapping of network file systems.] But when the programmers for Office and Windows both work for Microsoft, this is inexcusable.

Idiots.

Lies, Damned Lies, and Amazon Parcel Shipping Announcements

On April 2nd this year, I ordered a copy of “Star Wars: The Last Jedi” on Bluray.

At 14:17 on Sunday April 8th, I received notification that it had shipped, via Amazon’s own, in-house courier service.

At noon on Monday April 9th, I checked the delivery status via the Amazon ordering page and was told that the parcel was out for delivery and would be with me by 20:00. I checked again at 19:55 – just 5 minutes before the deadline and was able to confirm that it was still expected.

At 20:05 (and, largely curious to see if stepping past the anticipated delivery date would cause anything to happen with the shipping details) I checked again. I was told that the parcel was now still in transit, but that Amazon were “sorry” that it was delayed and that if it had not arrived by Thursday, I should contact them for assistance. Uh-uh. Where’s my parcel?

So I contacted a representative via a chat window. Top tip – if you ever have to contact Amazon, use a chat window. You will get the chance to receive an email copy of the entire transcript – which is useful evidence.

As to be expected, the loyal Amazon helper fell over himself to apologise – and did really well. To be fair, this was a rather unusual event. However, coming hot on the heels of some flat out lying and deceptive practices from Amazon regarding a printer order, I was inclined to be careful… This was what I got from the Amazon helper:

Please allow me to explain what seems to have happened. We do our best to ensure that all orders are delivered by the date provided when you place your order, but occasionally due to the volume of orders dispatched, there are rare occasions when a carrier receives an order that wasn’t originally assigned to them. However, we still expect your order to arrive as expected.

Be assured, this is not an common occurrence and our transportation team is working hard to eliminate these issues and continually monitor instances like this.”

When I expressed relief that the helper suggested the parcel would arrive on Tuesday April 10th, I got a bit of a surprise:

I don’t want to set any false expectation to your but as the parcel arrive to the carrier facility which was not assign to the order so there might be 1-2 days of delay as we have to ask the carrier to locate your parcel which takes 1-2 days.”

Wait, what? What’s this “locate my parcel” lark? You’ve just spent 10 minutes telling me that the parcel is with the courier and is in the van that delivers to my local area. So there was quite a bit more bluff and bluster about how everything was all in hand, but, basically, that was it.

Or was it? Take a look at the photograph, below, which is the shipping envelope in which it arrived today… See the dispatch date, at the top? “09/04”. Monday. [You might notice I’ve blanked the delivery address, just for the sake of privacy…]

So all that lovely detail about how it had been dispatched on Sunday morning was just complete fabrication. Typical.

Bastards.

Trouble Comes In Threes – Part Four: Microsoft

What, don’t tell me you were only expecting to see three issues within a “Trouble Comes In Threes” montage? Do keep up.

Having more-or-less recovered from the Windows 10 update nightmare, having ordered a replacement printer and having calmed down, yesterday I thought it might be nice to actually grab an hour or two of PC gaming…

You know, what with that being one of the reasons I spent so much money on the thing in the first place…

So there I am, enjoying a decent bit of fun in Skyrim, when my PC performs an instant and full-on crash and gives me a “Blue Screen of Death”.  Now, in fairness to Microsoft, these have become extremely rare since the arrival of Windows 10. This, then, was a big deal. I waited for an error code, but got,

WHEA Unrecoverable Error

In other words, nothing useful. The system rebooted and I had just re-loaded Skyrim from the most recent save when… another blue screen. Same error code.

Grr…

Nothing for it but to wait, reboot, and try again. Whilst obviously checking the logs files and looking for obvious problems – nothing on show…

When the computer crashed for a third time, the Blue Screen Of Death gave me a “new” error code – certainly not one I’ve seen before. This time I got,

Clock Watchdog Timeout

Interesting. And that was it…

There’s nothing in the “Update” logs to suggest that anything has changed in the build, but then Microsoft aren’t exactly truthful. Or it could be that they had reached out and turned on a piece of their spyware that isn’t normally active and that this occasionally-run piece of code was clashing with the gaming environment. That’s the problem of Windows 10. You just can’t know what it’s doing. When it does tell you anything [which is a pretty rare event these days] then the information is minimal. Even Event Log has become largely useless.

Is this it?

The end of the shambles that has been the latest Windows 10 Update? who can tell? This is part of the charm of Windows 10 – you just don’t know what is going to screw up next – or when.

Sigh.

Bastards.