Top 50 DOS Problems Solved: Whoops, I Deleted Everything

Q: I accidentally deleted all the files in the root directory of my hard disk for the second time this month. I managed to reinstall everything, but is there a way of avoiding the problem?

A: There are two approaches you could try, both of which have applications for other things too:

  • Modify the files so that they cannot be deleted without first explicitly making them deletable. You can do this with the DOS utility Attrib which was supplied with your system. … To protect the file use the command:

    ATTRIB +R filename

    The +R switch means “make this file read-only”.

  • Stop using the DEL command to delete files. Use a batch file instead which will prompt you before taking action.

    … <batch file code is given> …

    This batch file has a useful enhancement beyond the precautionary message. You can use it to specify multiple files, for example:

    DF *.BAK FRED.BAS ?.DOC

    With one command this would delete all .BAK files, FRED.BAS, and all .DOC files whose names begin with a single letter.

A delete command which takes multiple arguments – wow…

Top 50 DOS Problems Solved: Shrinking Hard Disk

Q: My hard disk seems to be getting smaller! There is a megabyte less free space than there was a month ago, yet I have not saved anywhere near 1MB’s worth of files. What’s going on?

A: This is quite a common problem, but most sufferers don’t realise they’ve got it. What happens is that some of the free space gets allocated to a non-existent file.

In other words the disk filing system has, in your case, a megabyte allocated to one or more files that don’t have a directory entry. They cannot therefore be seen with the DIR command, nor deleted.

Fortunately it is possible to turn these lost chains, as they are called, back into real files which can then be seen and deleted in the normal way. Simply type this command:

CHKDSK /F

If you have any lost chains, Chkdsk will tell you so and ask you if you want to convert them into files. Answer ‘Y’.

FILE0000.CHK, FILE0001.CHK, FILE0002.CHK…

How to Responsibly Publish a Misissued SSL Certificate

I woke up this morning wanting to write a blog post, then I found that someone else had already written it. Thank you, Andrew.

If you succeed in getting a certificate misissued to you, then that has the opportunity to be a great learning experience for the site, the CA, the CAB Forum, or all three. Testing security is, to my mind, generally a good thing. But publishing the private key turns it from a great learning experience into a browser emergency update situation (at least at the moment, in Firefox, although we are working to make this easier with OneCRL).

Friends don’t publish private keys for certs for friends’ domain names. Don’t be that guy. :-)

Top 50 DOS Problems Solved: Why doesn’t COPY copy?

Q: I want to copy all the files from a 5.25-inch floppy disk on to a 3.5-inch floppy disk, including the ones in some sub-directories. The COPY command won’t copy the contents of sub-directories, but when I try to use DISKCOPY I get the error message “incompatible format for drive’. What’s going wrong?

A: There are three commands to copy files from one disk to another: COPY, XCOPY and DISKCOPY. They work in different ways, and for any copy operation you need to choose the tool that’s most appropriate for what you want to do.

The problem with COPY is that it only works on the directory you specify and it cannot create new directories on the new disk. XCOPY works in a similar way to COPY but is more intelligent. You can tell it to look inside sub-directories, and it will automatically create those sub-directories on the new disk.

The command you need to type in, assuming you are copying from drive A to drive B, is:

XCOPY A:*.* B: /S

Is is the /S switch that tells XCOPY to work on subdirectories too.

Who remembers using a copy command which didn’t work with subdirectories?

Top 50 DOS Problems Solved: Doubling Disk Capacity

Q: I have been told that it is possible to convert 720K 3.5-inch floppy disks into 1.44Mb versions by drilling a hole in the casing. Is this true? How is it done? Is it safe?

A: It is true for the majority of disks. A few fail immediately, but the only way to tell is to try it. The size and placement of the hole is, near enough, a duplicate of the write-protect hole.

If the write-protect hole is in the bottom left of the disk, the extra hole goes in a similar position in the bottom right. Whatever you do, make sure that all traces of plastic swarf are cleared away. As to whether this technique is safe, it is a point of disagreement. In theory, you could find converted disks less reliable. My own experience over several years has been 100 per cent problem free other than those disks which have refused to format to 1.44Mb in the first place.

You can perform a similar trick with 360K and 1.2Mb 5.25-inch disks.

Hands up who remembers doing this. I certainly do…

An Encounter with Ransomware

An organization which I am associated with (not Mozilla) recently had its network infected with the CryptoWall 3.0 ransomware, and I thought people might be interested in my experience with it.

The vector of infection is unknown but once the software ran, it encrypted most data files (chosen by extension) on the local hard drive and all accessible shares, left little notes everywhere explaining how to get the private key, and deleted itself. The notes were placed in each directory where files were encrypted, as HTML, TXT, PNG and as a URL file which takes you directly to their website.

Their website is accessible as either a TOR hidden service or over plain HTTP – both options are given. Presumably plain HTTP is for ease for less technical victims; Tor is for if their DNS registrations get attacked. However, as of today, that hasn’t happened – the site is still accessible either way (although it was down for a while earlier in the week). Access is protected by a CAPTCHA, presumably to prevent people writing automated tools that work against it. It’s even localised into 5 languages.

CryptoWall website CAPTCHA

The price for the private key was US$500. (I wonder if they set that based on GeoIP?) However, as soon as I accessed the custom URL, it started a 7-day clock, after which the price doubled to US$1000. Just like parking tickets, they incentivise you to pay up quickly, because argument and delay will just make it cost more. If you haven’t paid after a month, they delete your secret key and personal page.

While what these thieves do is illegal, immoral and sinful, they do run a very professional operation. The website had the following features:

  • A “decrypt one file” button, which allows them to prove they have the private key and re-establish trust. It is, of course, also protected by a CAPTCHA. (I didn’t investigate to see whether it was also protected by numerical limits.)
  • A “support” button, which allows you to send a message to the thieves in case you are having technical difficulties with payment or decryption.

The organization’s last backup was a point-in-time snapshot from July 2014. “Better backups” had been on the ToDo list for a while, but never made it to the top. After discussion with the organization, we decided that recreating the data would have taken much more time than the value of the ransom, and so were were going to pay. I tried out the “Decrypt One File” function and it worked, so I had some confidence that they were able to provide what they said they were.

I created a wallet at blockchain.info, and used an exchange to buy exactly the right amount of Bitcoin. (The first exchange I tried had a ‘no ransomware’ policy, so I had to go elsewhere.) However, when I then went to pay, I discovered that there was a 0.0001BTC transaction fee, so I didn’t have enough to pay them the full amount! I was concerned that they had automated validation and might not release the key if the amount was even a tiny bit short. So, I had to go on IRC and talk to friends to blag a tiny fraction of Bitcoin in order to afford the transfer fee.

I made the payment, and pasted the transaction ID into the form on the ransomware site. It registered the ID and set status to “pending”. Ten or twenty minutes later, once the blockchain had moved on, it accepted the transaction and gave me a download link.

While others had suggested that there was no guarantee that we’d actually get the private key, it made sense to me. After all, word gets around – if they don’t provide the keys, people will stop paying. They have a strong incentive to provide good ‘customer’ service.

The download was a ZIP file containing a simple Windows GUI app which was a recursive decryptor, plus text files containing the public key and the private key. The app worked exactly as advertised and, after some time, we were able to decrypt all of the encrypted files. We are now putting in place a better backup solution, and better network security.

A friend who is a Bitcoin expert did do a little “following the money”, although we think it went into a mixer fairly quickly. However, before it did so, it was aggregated into an account with $80,000+ in it, so it seems that this little enterprise is fairly lucrative.

So, 10/10 for customer service, 0/10 for morality.

The last thing I did was send them a little message via the “Support” function of their website, in both English and Russian:

Such are the ways of everyone who is greedy for unjust gain; it takes away the life of its possessors.

Таковы пути всех, кто жаждет преступной добычи; она отнимает жизнь у завладевших ею.

‘The time has come,’ Jesus said. ‘The kingdom of God has come near. Repent and believe the good news!’

– Пришло время, – говорил Он, – Божье Царство уже близко! Покайтесь и верьте в Радостную Весть!

R.I.P. api-dev.bugzilla.mozilla.org

Complaining about bugzilla.mozilla.org (BMO) is a Mozilla project activity as old as the hills. Back in 2009, it was realised by the Foundation that to make everyone happy was (and still is) an impossible task, and I was given a mandate to “help people solve their own problems”. So around September 2009, I released the first version of my Bugzilla API proxy software, BzAPI. This software presented a clean, well-documented RESTful interface on the front end, and did all sorts of things on the back end (XML, CSV, RPC, HTML scraping) that developers no longer had to worry about. We made a dev server VM for it so people could try it out – api-dev.bugzilla.mozilla.org.

It was popular. Extremely popular. People started building things, and then more things, all of which depended on this server for Bugzilla data. For various reasons, IT never got around to building a production instance, and so over the last five years, I’ve been maintaining this core piece of Mozilla project infrastructure, which was depended on by TBPL and many, many other tools which interfaced with Bugzilla. At its peak, it serviced 400,000 requests per day.

Over the intervening years, BMO itself acquired a REST API which slowly became more capable, and then a BzAPI-compatible API shim was implemented on top of it by the excellent dkl, so people could change their code to access BMO directly just by updating the endpoint URL. After a few false starts, requests to api-dev.bugzilla.mozilla.org are now served directly by BMO, via that shim code. Earlier today, the api-dev VM was finally powered down.

Here’s to you, api-dev. Good job.

Alice and Bob Are Weird

Suppose Alice and Bob live in a country with 50 states. Alice is currently in state a and Bob is currently in state b. They can communicate with one another and Alice wants to test if she is currently in the same state as Bob. If they are in the same state, Alice should learn that fact and otherwise she should learn nothing else about Bob’s location. Bob should learn nothing about Alice’s location.

They agree on the following scheme:

  • They fix a group G of prime order p and generator g of G

Cryptographic problems. Gotta love ‘em.

Signed Committer’s Agreements No Longer Required

For a long time, Mozilla has required people gaining commit access to our core repos to sign a Committer’s Agreement. This is not a copyright assignment or a transfer of rights; it’s basically a commitment to good behaviour, and to making sure code which gets into the tree is allowed to be there and is correctly licensed.

However, the logistics of printing it out, signing it, scanning/photographing it back in etc. were always a barrier to participation. In consultation with our legal team, we have decided that people simply assenting to the document is just as good so, as of now, people are no longer required to go through the process of signing it.

However, all people with commit access to any Mozilla repository are still expected to abide by it :-) We may be adding CONTRIBUTING files referencing the document to our Github repos to make this point more clear.

Samuel David Markham

I am overjoyed to announce the birth of our third son, Samuel David Markham, at 9.01am on the morning of 28th January 2015, weighing 8lb 0oz. Mother, father, baby and older brothers are all well :-)

He is called Samuel after:

  • The prophet and leader Samuel, who was called into God’s service at an early age, as recorded in the book of 1 Samuel;
  • Samuel Rutherford (1600 – 1661), a Scottish minister and representative at the Westminster Assembly, whose book Lex, Rex contains arguments foundational to a Christian understanding of good government;
  • Samuel Davies (1723 – 1761), American non-conformist preacher, evangelist and hymn writer, who showed we are all equal in God’s sight by welcoming black and white, slave and free to the same Communion table;
  • Samuel Crowther (1809 – 1891), the first black Anglican bishop in Africa, who persevered against unjust opposition and translated the Bible into Yoruba.

He is called David primarily after the King David in the Bible, who was “a man after God’s own heart” (a fact recorded in the book of 1 Samuel, 13:14).