Please read the thread before you reply.

This was about firmware images provided on the web site of the manufacturer. Not about reading/modifying the firmware of a drive - which indeed we know is possible by design (otherwise this whole discussion would be pointless to begin with).

As many already pointed out: you can not trust the firmware image provided by the drive itself, for the simple reason that you have to talk to the very firmware you try to verify, and which may be compromised.

Think of the kid calling "are there any monsters under the bed?", and the monster under the bed answering "no!".

If you don't have proper reading comprehension skills, you are unqualified to reply.

No-where did I try to say it's not a big deal.

Copying some data is quite different from replacing data, and far easier to do unnoticed. The NSA copied existing SIM encryption keys; they did not attempt to replace them with their own keys or so.

It is pretty hard to detect an intrusion, access to data, and copying of that data. Especially if the attacker gets access through an authorised account by getting their hands on someone's login credentials.

It is much easier to detect the replacement of data: this can be done with e.g. automated cryptographic checksum tests against remotely stored known good checksums, or against a freshly compiled copy.

A lot of data will have to be replaced unnoticed (source code is being read by humans, who may detect changes if it happens to be the part they work with) to stand any chance of getting a compromised binary on someone else's site unnoticed.

I doubt you need much, really.

All the malware part has to do is to read the rest of the software from disk upon boot, then hide that part of the drive from the OS. This way you could hide a pretty big piece of software on the disk, and with today 500 GB kind of capacities being the norm, the user won't notice unless they look really really carefully at the numbers.

You can't, but you can be quite sure that the manufacturer will take serious measures to make sure this doesn't happen. This protection against tampering to compromise computers just piggybacks on more general protections to keep firmware sound, such as tests to make sure there are no bugs in the firmware that cause data loss, and that software published on the web site is the software the company intends to publish.

This for the simple reason that one mistake here may result in bankruptcy, as people may lose trust in the whole company. Without trust in its products by its customers, a company can't survive - especially when it's about storing valuable data.

Most likely there are no such tools as no-one thought it could be a vector of infection. Just like the BIOS; which used to be a non-reprogrammable ROM chip. I for one didn't know current hard drives even had firmware that can be replaced by the user, let alone that it may be a potential attack vector for malware.

Depending on how hard it is to read the installed firmware from a hard drive (is this even possible in the first place?) it shouldn't be too hard to write a tool that can read the firmware, and calculate a checksum for verification. The hard part is going to be, how do you know that your software gets the actually installed firmware - or just a known good but inactive piece of code provided by a compromised firmware, pretending that this is the software that's installed? The moment a firmware is installed, you probably need to call onto that very firmware to get a copy of it from the drive. Unless this read-firmware routine is provided by a special, hard coded circuit.

Exactly. What people also forget is that it's not just about the whiteboard, it's at least as much about the beers afterwards. Getting to know your colleagues in person helps a lot in getting cooperation going (it helps you interpret the writing in their e-mails properly, for example).

There is no real substitute for in-person meetings. And considering the problem at hand has already the budget of flying people around to get it solved, you'd better make use of it.

Start with a partner or friends. If it's about UI issues or related things, they don't need to be programmers or versed deep into the problem at hand. People that know nothing about it actually can at times give you the best ideas, exactly because they know nothing about it and haven't yet restricted their minds by thinking about it. The programmatic implementation itself of course you have to do yourself, but that's generally the straightforward part (after you properly defined the problem, and the solution you want to work towards).

Part of the problem this is not that big news may be that it's about the US, where power outages and the like are the order of the day. Just ask around on /.: how many of you Americans routinely install a UPS in your home? How many have a generator on hand? Now compare this to the non-Americans that live in what we commonly call the "developed world".

Even emergency services were affected. Something that many Americans find so important that it's always used as a major argument against banning/jamming mobile phones in movie theatres and so, or as key reason primary school kids must carry a phone on them at all times. Even this major service was disrupted. So no matter what, something was terribly wrong here, and some company did not get their redundancies and automatic rerouting right.

Good chance the thieves found out the pipe didn't contain any copper the moment they cut it through. This is supported by the observation that, according to TFS, the pipe was just cut at one place, and nothing had been removed.

So all those important communication lines went trough a single pipe, with no backup, and that pipe was fully exposed to boot? That's just asking for trouble.

Lots and lots of minor fixes and changes add up to serious architectural rework. Ground-breaking new features are added when ready - one by one - every few months it seems I read about another major change to the kernel - so after a while you have several such major features added, it's unreasonable to add a major number every time.

So while I agree with your general ideas, it's certainly not that easy in the "release early, release fast" world of open source software, as with the fairly rapid addition of many bigger and smaller features to the kernel, and the fairly frequent release of new versions. Alternatively you may just have stick to major versions, like recently Firefox (currently my Firefox is at version 35) and Chrome (no idea what number they're at now) are doing, and as a result indeed the numbers are big enough that you can't really distinguish them. Which is bound to happen sooner or later to any piece of software that's under active development for a prolonged time.

Not sure about this, but the SCMP (local HK news paper) reported about people sending cheques to this company. That's real money, not BTC, that they gave that company. Details are thin, but it seems that this company asked for payment for to-be-mined BTC. At least they were running a BTC mining operation as well.

Maybe they bought a flat in 2003 (end of the SARS period), and sold it recently. They'd have easily tripled their money in that period of time (the housing market has gone up by that much, and it still going up fast - Hong Kong property prices are currently between ridiculous and simply out of this world). If they bought a $2M flat in 2008, they could sell it for like $6M now. That'd be $4M cash profit in hand, plus whatever they have left after paying off the original mortgage. Or take out a new mortgage based on the current value, mortgage interests are around 3% with banks all too happy to sell you mortgages.