Well, since you indicate that you have actual recent statistics of Windows malware penetration (hopefully by OS version), I will kindly ask you to provide a link to them.

Also, you are wrongly assuming that having an older car (which by the way, was never explicitly implied by the analogy, though we can reasonably assume that most of the people using XP are likely to have it installed on a computer that is not so recent) somehow makes you more immune to theft, failing to take into account that, for the most part, opportunistic thieves will be more interested in the content of the car (and how easily accessible it might be) than the car itself.

By the way, I'll just leave this here (sadly no XP or 10 data...). Of course this data comes from Microsoft, who have vested interest in saying that their newer OSes are safer, but then again, feel free to call them on that with evidence to back it up.

Thanks to the link you posted we can study the evolution between 2012 and 2014

Oh, can we now?

I thought we would only be able to do that if we had the infection rate for XP in 2014, which (unless I missed something) we don't have.

It's nice of you to discuss trends... when they affect everything but the system that is of interest to us.

Or maybe we should draw the logical (but unprovable) conclusion we try to can draw from these statistics, which would be that, for the most part, the older the system, the greater the increase in malware penetration between 2012 and 2014. But then again, without factual data, this is just conjecture.

Also, to come back to my original post, which was about how deliberate SHA-1 collisions (if they become, as is expected by most security researchers, achievable with non-prohibitive investment in the near future, if they aren't already being exploited today) are bad news for XP and Vista users, the thing is: even XP/Vista users who are conscious about security and making sure they only run signed software have now been put at a relatively tangible increased risk of being infected. The reason being that, if someone can successfully produce arbitrary SHA-1 collisions, they could, for instance, create a malicious version of Rufus 2.6, and reuse the existing digital signature and timestamp (which are both only based on the SHA-1 of the original executable payload) to make it look like the real thing. As far as XP and Vista users would be concerned, the malicious download would not have any indication that it was modified to do something nefarious, due to its digital signature being 100% legit. So, now, unless you are doing the extra step of also manually checking SHA-256 (or some other more secure hash) against one you can trust (which I don't, and am not planning to, provide on the site), an executable having a valid SHA-1 digital signature is expected to soon become meaningless...

So, as much as you may like to pretend that XP users are probably as safe as ever, if they are security conscious, I am afraid I have some factual elements that indicate that this is a very dangerous assertion to make...

From the data available we can however infer that notwithstanding a numberless amount of security updates issued by MS the actual infection rate has at leastdoubled for 7 (the data for Vista is probably too scarce to be meaningful and the comparison between the very early adopters of 8 and the relatively more copious amount of current 8 and 8.1 users is probably also not a fair one).

If fully supported OSes in this period have increased the number of infected machines by a factor of at least 2 (but possibly higher, Vista is x3 and 8 x6) we cannot but assume that the trend for a less secure and unsupported (and not anymore updated) OS like XP should be much, much higher, something in the x10 to x100 range.

Since XP was already in 2012 rated to have more than 11/1000 machines infected, by now a consistent number of machines running XP should be infected, anything between 10% and 100% which is something that seems like not being what happens.

The data is anyway useful, as another consideration may be that in late 2012, OS usage was:

544,000 ran 7 and thus there were between 6/1000 and 9/1000 of them infected, let's say 7.5/1000=4,080

132,100 ran XP and thus there were AT THE VERY LEAST 11/1000 of them infected=1,453

31,500 ran Vista and thus there were 11/1000 of them infected=347

130,000 ran 8.1 and thus there were 1.5/1000 of them infected=195

46,700 ran 8 and thus there were 6/1000 of them infected=280

this makes 6,355 total and 4,902 excluding the unsafe XP

This explains why all the good guys in antivirus/security and computer shops are still at work, actually the number of infected machines per million has increased and without counting the XP machines (for which we have not MS data) has almost doubled from 2,577 to 4,902.

notwithstanding a numberless amount of security updates issued by MS the actual infection rate has at leastdoubled

Which, unless we have statistics that detail by which factor the number of people developing Windows targeting malware has increased during that period (in most likelihood, especially as we see a sharp global increase, what if, with the availability of ready-made rootkits and exploits being sold on a more black-market that became more publicized, there was an 4-fold increase in Windows malware during that period?) does not allow us to draw much of any conclusion.

Or do we want to pretend that cars were much safer in the early 20th century, because there were a lesser number of fatalities overall, due to a lesser number of vehicles?

If fully supported OSes in this period have increased the number of infected machines by a factor of at least 2 (but possibly higher, Vista is x3 and 8 x6) we cannot but assume that the trend for a less secure and unsupported (and not anymore updated) OS like XP should be much, much higher, something in the x10 to x100 range.

Really? How about, again, taking quantization about the amount of malware being developed, and for which system (a malware developer is still a developer, and like myself, will have more interest developing software for platforms that have a greater share, than obsolete or semi-obsolete ones... which doesn't mean anything with regards to older systems' security) into account? Alas, we have no data for that, and without this, I maintain that the conclusions you are trying to draw are missing one very important detail (actual evidence) to back them up.

Also, you are trying to lead people to think that because data may not have increased 10 or 100 fold, it must means that it can't have seen the greatest increase of all, which is a fallacious assumption to make. All we can say is that we don't have data. But not having data does not mean that a system, for which, on the other hand, we have factual evidence of increased insecurity, should still be considered safe-enough.

actually the number of infected machines per million has increased

Indeed. If, by inferring that either there is more malware out there than ever, or that its level of sophistication to bypass security measures has increased, that doesn't invite anyone who is using a system that is unmaintained by its manufacturer, to move to a system that is, I don't know what will, especially when it comes down to the first line of defence (rejecting potentially malicious executables through the use of digital signature).

I am not trying to lead people into thinking anything, we don't have enough or good enough data, but the little data we have however leads to say that XP has more "risk" than before and more than any other supported MS OS (which is your thesis ), on the other hand the same data leads to say that the actual number of infected machines (practice) has increased noticeably, while the "risk" (theory) for currently supported OS's should have diminished.

Whether this depends by the ineffectiveness of MS patches/updates (which related to "risk") or by the increased efforts of the bad guys (which relate more to "number of affected machines") or (say ) by a sudden outburst of demented users parking their cars in bad neighbourhoods , is well up to discussion/debate , but you will have to concede that there is no real correlation between "risk" (and "risk mitigation" as performed by the good MS guys) and actual number of infected machines (which is "real world" insecurity), at least for Windows 7, which represents the vast majority.

It is very possible that the good MS guys managed to make Windows 10 "invulnerable" but there is not yet any data about it.

Except I do. The SHA-1 signature business, of which I explained the why and how it effectively puts XP (and Vista) users at an increased risk.
Granted this depends on the ability of creating deliberate SHA-1 collisions, but research, which I also indirectly linked to, suggest that it's a matter of when (with the when possibly being in the past), not if.

You can huff and puff all you want, this is good enough data that demonstrates that XP users are at an increased security risk compared to other platforms.

XP has more "risk" than before and more than any other supported MS OS (which is your thesis )

Backed by the evidence I gave earlier.
It's also a system for which OS vulnerabilities are no longer patched by its manufacturer, which is other evidence of decreased security.

If you want to pretend the above doesn't matter, and that somehow, the increased in complexity which was likely introduced in later OSes offsets all of the above, be my guest. But don't be surprised if I cease to take you seriously.

while the "risk" (theory) for currently supported OS's should have diminished.

I already explained why there is nothing in the data you linked to that allows us to draw that conclusion, unless we also know the trend in malware creation for these systems, for the same period. Furthermore, the SHA-1 collision business is something very recent (late 2015), so we won't get much data about it for a while... which doesn't mean that it's any less of a real security risk.

is well up to discussion/debate

No it's not. It's something for which we lack data, and therefore that makes any assertion unreceivable, unlike the evidence I presented, which can be backed up and does not depend on ancillary data to provide the meaningful conclusion that yes, a system for which OS vulnerabilities are left unpatched and standard digital signatures can not be relied on is by definition more insecure that systems where the same does not apply.

but you will have to concede that there is no real correlation between "risk" (and "risk mitigation" as performed by the good MS guys) and actual number of infected machines (which is "real world" insecurity), at least for Windows 7, which represents the vast majority.

I have no problem conceding anything you want about Windows 7 in the absolute (or that Windows systems are indeed "vulnerable", as you are once again trying to orient the "discussion" in a direction I never took - heck, I am presently convinced that, if your system is connected to the internet, and the NSA wants to access it, they will have no trouble doing so, regardless of whether it's super hardened Linux, BSD, Windows or whatever), since that's not my point.

My point is that, as backed up by evidence, Windows XP is becoming less and less secure, especially when it comes to fending off malware, and that, if you have any inkling about preserving the integrity of your system and/or data, you should move to a system that doesn't have the very adverse shortcomings that Windows XP has which means:

- getting regularly uncovered system vulnerabilities patched (so that these specific vulnerabilities can not be exploited)

- a native digital signature framework that you can trust (which is the whole point of digital signatures).

Fact of the matter is that Windows 7 and later are such systems, and therefore should be considered more trustworthy and less vulnerable than XP. Does that mean that malware authors will specifically target more vulnerable systems as they also have less of a market share? Not in the least. But that doesn't detract from the fact that, should they decide to, they will have a much easier time doing so than for later platforms, and this is something that should be taken into account by anyone still using these platforms, if they actually care about security.

Windows XP is less secure than Windows 7, and windows 7 (and later) are more trustworthy and less vulnerable than XP.

No doubts about this.

My point is only about how muchsafer these new OS's are than XP.

From the way you made the "chastise" incipit, it seemed like the (BTW useful and recommended) SHA-256 check was something that will make Windows 7 (and later) failproof OSes while the lack of it in XP and Vista will instantly make them pwned.

From the way you made the "chastise" incipit, it seemed like the (BTW useful and recommended) SHA-256 check was something that will make Windows 7 (and later) failproof OSes while the lack of it in XP and Vista will instantly make them pwned.

Well, I guess I'll have to be more careful next time I write something like "the security risk for anybody running XP has been increased significantly", as it seems some people may interpret it as "instant p0wnage"

For what is worth, the "chastise", which, to put it in context, was part of "since I'm never gonna miss a good reason to chastise people still using XP in this day and age" is a callback to previous discussions (some of which you participated in IIRC) where I highlighted, among other things, how much of a hassle it is for developers (including Microsoft) to try to support older OSes, and how the people who are the first to complain about having to pay for a new license, or the amount of tracking newer Microsoft OSes might perform behind their back, or even the malware security risks that you'll get with all versions of Windows anyway, as reasons why they don't want to move away from XP, will incredulously dismiss Linux as a viable (and free) alternative...

If anything, as a Free Software developer I'd personally be a lot happier if XP and Vista people moved away from Windows altogether (even if that means they'd no longer be able to use Rufus), than upgrade to Windows 7 or later. But even if they don't do that, pointing new security deficiencies in those systems is one way I see to hopefully help those users conclude that they'd probably be better off not using those OSes...

And I do understand how supporting different OS's is a PITA for a developer, particularly for a serious, attentive developer like you are , and I do understand how you are meaning well when you point out all the issues that may come out from a prolonged use of an unsupported OS, but as said in the past, just like a number of other developers already did you are perfectly free to release a new version without XP (or Vista or both) support, and all you need is to remove those from the list of supported OS, surely you will have some negative feedback from a few "old windows" aficionados, but they will manage to live with it alright.

But you don't really *need* to retell the already told and retold, almost two years after the end of MS support people still running XP either ignore all the warnings already received (because of either ignorance or recklessness) or have some valid reason to still use XP.

The turning point (news) is IMHO the shift of the line to comprise Vista (which is anyway NT 6.x) among the unsupported and "old" OS's.

Certainly the numbers are not that big, but - hard as it might be to say this - Vista SP2 is not as bad an OS as the original release was (and is) perceived, the good MS guys are doing everything they can to promote their new OS (which is understandable) but doing this while Vista is still under "extended" support (under "extended" support security updates are included) seems to me another little thing that is further reducing the trust you can have into the MS guys.

<Congratulations, you have unlocked the “I’m gonna have to lecture you with a super-long post” achievement!>

You still are missing the point, and, after that irrelevant “But Windows 7 is not bulletproof” blurb, you are now trying to use a second straw man to make it look like my beef with XP has to do with having to personally support it as a developer. So I guess I’ll have to address this first.

Just to be clear, if I was that annoyed at how XP makes my life harder as a developer, I’d have dropped support for it in Rufus in a heartbeat. But instead, as indicated in the small paragraph that prompted all this discussion, I chose to trouble myself with continuing to sign Rufus using 2 sets of digital signatures (instead of just the SHA-256 one) to continue to help security-conscious XP users. Granted, there’s not much I can do about SHA-1 collisions, but provided that they are still some time away, continuing to provide an SHA-1 signature, for systems that only understand SHA-1 signatures, is still much better, security-wise, than not providing one at all. As a matter of fact, doing what is “right” in term of security, instead of doing what ones feels like, is pretty much the point I am going to make, and my whole issue with you; there’s no such thing as freedom of action when it comes to ensuring that users have the best security they possibly can. You should not compromise, as you are doing, when trying to ensure the safety of all OS users and as a valued member of this community, you are doing a great disservice to it by trying to imply that it is still okay to use XP (which, I can guarantee, is the takeway people will get from your posts).

You are also (in effect with a 3rd straw man) trying to pretend that my message is just about reiterating that XP support has ended (“XP is dead”, i.e. your “memento mori”), where it is everything but. My main statement was only ever about safety, and I shouldn’t have to point to you that the corollary elements I get to mention, such as the fact that, as a “dead” OS, XP has ceased to receive system vulnerability fixes, or that because of the need for developers to add extra paths in their code in order to support XP (and, in case you it needs to be explained, my real concern here is for browser developers, such as Chrome or Firefox ones, rather than myself, as browsers are usually the first line of defence against malware) we logically get more software that can be exploited, only serve to further demonstrate why XP can only logically be construed as a major security liability right now, that people should attempt to move away from.

With this being said then let me get straight to the core of the matter, which is something I believe I had already tried to make clear in other threads where we discussed XP:

By using XP in a connected fashion in this day and age, when there exist much safer (including free ones) and viable (Last time I checked, WINE on Linux was doing a good job at running XP apps) alternatives, you not only are putting yourself, but, more importantly others, at risk.

And now we get to the part where I’m going to use yet another car analogy. And while I have to skew my analogy in the process (which is what all analogies do anyway – there’s hardly ever one where the transposition factor is 100%), I’m going to go for the “If I can't make people remember anything from what I'm saying this whole spiel, let’s at least make them remember this”.

Henceforth, let me introduce you to a car that is relatively well known in UK and Ireland, but probably not that much outside of these countries, called the Reliant Robin, to state that: using Windows XP in 2016 is pretty much like using a Reliant Robin. And the reason is probably best illustrated with this little video:

Well, first of all, what we have here is an obvious design flaw (or conscious design decision if you want to put it that way – doesn’t matter) in the system that cannot easily be patched, and that certainly will not be addressed by the manufacturer at this stage. But, more importantly, this flaw is something that not only puts the user of the vehicle at a very real risk, as shown in the video, and, more importantly, also puts other users of the public road network at risk. Even if you are fully conscious of the tendency of the car to roll over (i.e. are security conscious when using XP), and taking counter measures, it only takes a turn which you didn’t anticipate, or a moment of inattention in a curve, to roll over the car, possibly onto incoming traffic.

So not only are you putting yourself at risk, from using a vehicle that (at least in the case of XP – remember I mentioned that the transposition factor would not be 100%), its manufacturer has repeatedly indicated should no longer be used, but you are endangering others.

And this is one of the regular battle security people have to fight when it comes to collective resources that can be compromised: the “I should be able to do whatever I choose” argument that fails to account for other people using the resource.

Have you ever considered that it’s very much possible to theorize that, what you tried to bring people’s attention to (increase in the rate of malware penetration for newer than XP platforms between 2012 and 2014), could actually have a lot to do with people, no doubt encouraged by straw men arguments like the one you also linked to (“why should I upgrade to newer Windows when Microsoft continues to issue more and more security patches for these OSes and they’re everything but bulletproof”), continuing to use XP in a connected fashion. As you are plainly aware, the spread of malware requires vectors, and the more vectors you initially have, the most likely you are to be able to penetrate even more systems.

So, if we consider that, starting from the data we have for Q4 2012, and the logic that tells us a system where critical vulnerabilities are left unpatched is not going to evolve in the best direction security-wise — regardless of a dwindling market share, XP platforms are likely to be a lot easier to compromise today than they were in 2012. From this, we can envision that, as far as malware people are concerned, XP platforms are easy to penetrate targets, either by “drive by” or malicious download. And thus, because people have been encouraged to keep using XP way longer than they should have, if, say, you have market share that went from 20% to 10%, but in the same time suddenly gained a drive by infection rate that is much higher than this reduction rate, you will now be sitting on a larger park of infected machines in your botnet (reminder – most malware these days will attempt to communicate with a server), which you can use as vector of infection... including for Windows 7 and 8 machines. Of course, these may not be as easy to penetrate as XP ones, but with a larger park, you may still see an increase. And once you get a greater foothold with those, the infection trend is likely to go up rather than down, regardless of how active the OS manufacturer is with system vulnerabilities.

Oh, and since I’m going to try to be pre-emptively feature complete in my argumentative here, so that I don’t have to deal with replies that attempt to distract from the central point (more on this below), let me address a few things as an aside, especially as they very much apply, even if you disagree with the argument that XP is directly tied to the increase of infection rate for later Windows machine, which I’ll be the first to say is mere unprovable conjecture at this stage:

1. It doesn’t matter if you use the latest Chrome, Firefox or latest AV on XP when every single one of these applications relies on Windows system DLLs where vulnerabilities such as buffer overflows or missing sanitization are left unpatched. As long as your application doesn’t come with a complete OS replacement layer, and as opposed to OS that are still receiving updates, you will be left vulnerable because of these unmaintained OS libraries.

2. You may try to put forth the argument that, because of the end of support, most XP machines will be run by individual and run isolated on a home network and are therefore, even if infected, unlikely to do much harm, as would be the case for a corporate network (which of course should have tried to weed out unsupported OSes some time ago). What you’d fail to take into account however is that one way infected botnets are being used is to try to infect web servers, when 0-days vulnerabilities get exposed (there are many server vulnerabilities that get disclosed over the course of a year) before the server admin gets a chance to patch them. Of course, since there are a lot of web servers on the internet, and a lot of them will have some mitigation techniques to cut off requests from individual clients that are poking around too inquisitively, the more machines you have on your botnet, the higher the chance to compromise a web server. And if you happen to compromise a machine that serves Windows executables (or serves any web page really, as drive-by exploits are not uncommon), congratulations, by being able to exploit a few more “easy” targets, you have suddenly increased the rate of infection for all Internet users. Oh, and with the SHA-1 signature thing, if you broke into a server that distributes signed .exe’s, you may just have found an even greater opportunity to infect security-conscious Vista and XP users, as even a valid signature there might not be enough to provide confidence that what was just downloaded isn’t malicious.

Now, I know it’s a long blurb already, but I can’t pass out a renewed attempt at inserting yet another straw man with your final “reducing the trust you can have into the MS guys” statement. I thought I had been clear already that it’s not because a system, which isn’t the one being discussed, evolves in a poor direction security wise, that it has any positive incidence on a system for which we have conclusive evidence hinting at its security being worse by a much greater factor.

So, to get back to the old car analogy, unless you are actively alerting users of such systems to move to something more secure, what you are effectively doing is letting a friend, which you know has a car with a braking system that is no longer maintained and has been getting worn out past safe levels, or even letting a drunk friend, drive in state where they shouldn’t.

And, sure, they may not have paid much heed to advice about these issues for the past couple of year, and, maybe they don’t seem to have gotten into any trouble so far (except I doubt XP people who got infected will post in this forum to report), but if you value both your friends and the other drivers on the road, at the very least, you have a duty not to keep silent. The probability of something happening is simply too great to just stand there and state: “Nah, you can drive, you’ll be grand...”

Thus, no matter how you are trying to (mis)lead the discussion here, let me say this: I don’t think it is okay for a respected member of this forum to tell people who use a much unsafe OS (compared to alternatives they can move to, especially as we have to assume that people visiting a forum dedicated to booting are likely to be competent enough to transition to Linux, should they wish to) that they should feel entitled to do so. Instead, in the absence of indication that people are using XP in a disconnected fashion, I would expect you to be one of the first person to remind them that they should really consider moving to another OS, as well as remind Vista users that, with EOL coming soon, they should have a migration strategy ready.

Or, since I really can't tell you what to do, at the very least, as a person who I surmise has enough expertise to understand security matters, I would expect you not to try to shut down the message of someone who is only trying to perform what I just stated above (regardless of how annoyed you may be of hearing the message). Considering how much effort you tried put in diminishing my message, I can therefore only assume that your goal is to promote the opposite, with the much detrimental effect that this will effectively reduce everyone’s safety.

Oh, and since this is a very long post, which of course brings a lot more stuff you can try to cherry pick on, to distract from the central point, then let me make my central point abundantly clear. If you want to refute something in this post, then at the very least, I expect you to address the points highlighted below, as everything stated above is merely a reformulation or expansion of these:

Windows XP is currently a very real security liability, and this state will only get worse.

Because of this, XP users are putting their and, more importantly, other people’s safety at risk.

It is therefore not okay to tell XP users that they should feel entitled to continue to use XP, if they are going to do so in a connected fashion (which, in the absence of information indicating otherwise, is what we should assume in a security-focused context). On the contrary, it is the duty of security minded people to remind XP users that they should move to a more secure OS, as well as remind Vista users that they should also prepare an exit strategy, as they will be in a similar situation soon.

Let me also add this just in case (which may also help clarify the connected/unconnected above): outside of custom in-house corporate applications (that can usually be transitioned to a private subnet that is separate from the internet and will actively be monitored by an IT dept), I have seen very little evidence of users being tied to an XP platform because of applications, especially in manner that requires internet connectivity.

So, are you just going to continue to imply that, when we have worrying usage statistics regarding Internet connected XP machines, almost 2 years after users should have migrated, trying to move people away from XP, on account of security concerns, is something you just can't stand for?

<Congratulations, you have unlocked the “I’m gonna have to lecture you with a super-long post” achievement!>

Thank you for the privilege.

I chose to trouble myself with continuing to sign Rufus using 2 sets of digital signatures (instead of just the SHA-256 one) to continue to help security-conscious XP users.

And this I personally appreciate and thank you for your kind consideration and for the extra-work you decided to do in order to support XP users.

So, are you just going to continue to imply that, when we have worrying usage statistics regarding Internet connected XP machines, almost 2 years after users should have migrated, trying to move people away from XP, on account of security concerns, is something you just can't stand for?

No, as a matter of fact I don't want to imply anything.

What I tried to state was that people that still run XP nowadays are either ignorant (they don't know or do not fully understand the security issues XP creates) or reckless/not security minded (i.e. they do know and understand the risks involved and don't care about them) or BOTH ignorant and reckless or ignorant, reckless and stubborn , and since in the last two years everyone has been busy telling XP users how wrong it is what they are doing, people that still insist on running XP nowadays are not anymore sensible to this message.

Those that are running newer systems on the other hand (possibly because alreadychastised by someone in the last two years) may get the (false) impression that anything more recent than XP is safer (which is true) but also that it is so much safer that they can do everything they can think of because the so much increased security (which is false).

And I am sorry , but I will not attempt to address the points you highlighted, let's see if we can put an end to this discussion, you have highlighted your opinions on the matter, they are very well worded and thought out, good.

Note that there is usually a 24 hours delay between the time I publish a new version of the side and the time it becomes available through the auto-update feature of Rufus (to provide a buffer in case a major issue was left unreported during beta).

Used Rufus 2.8 Portable to burn Ubuntu Desktop 14.04.4 LTS iso to USB Stick. Used the first option and not the dd option. Booted with garbled screen on first boot. Shutdown and reboot. The Install screen showed and installed normally. So install of
Ubuntu Desktop 14.04.4 LTS worked.

Add SHA-256 validation for downloaded files. You will now see an ✓ or ✗ in the log for relevant content

Add support for O2Micro PCI-E card readers

Improve automatic closure of the Windows default format prompt

Improve support for Ubuntu (silence a benign warning), Springdale (use the actual label) and Antergos (Syslinux version detection)

Work around a Windows bug that can render a GPT disk inaccessible after cleanup (e.g. ChromeOS image)

Fix hash computation for content that isn't a multiple of 64 bytes (NB: This did not affect ISOs)

Fix Syslinux installation on some media, with huge thanks to 424778940z for the tests

Fix a corner case where settings could be altered after Start had been pressed, if a hotplug event also occurred

Additional fixes and improvements

Since it might be of interest to some, some comments on the first item:

The goal of the SHA-256 validation is to help the paranoid user (which we should ALL be) determine if the downloadable content may have been altered in any way during download. Say, you live in one of these regimes that is hell bent on controlling the kind of information that their citizen can publish on the internet, and you happen to want to use tails. You've heard that Rufus was a great tool for installing tails onto an USB. Also, because Rufus is digitally signed (with SHA-256 which is difficult to compromise to say the least) and unless your government managed to coerce one of the Certification Authorities that Windows natively supports into issuing a fake certificate with the name "Akeo Consulting" (which is what you should check to confirm that the Rufus you downloaded is genuine), as well as coercing Microsoft into not revoking that Certification Authority as soon as they are made aware that it issues fake certs, then you can have a reasonable amount of confidence that your copy of Rufus has not been tampered with.

But that still left the matter of the files which Rufus may need to download to make the USB bootable. In the case of tails, Rufus requires the download of ldlinux.sys and ldlinux.bss. Regardless of whether that happens or HTTP or HTTPS, a nefarious entity could use a man in the middle attack and replace the files requested from the server with their own malicious copy. So how can we alleviate the issue?

Simple: Rufus now includes a DB of the SHA-256 hashes for all the downloadable files that resided on the server at the time of the release. So, in the case of tails 2.4, which happens to use the release version of Syslinux 6.03, which is of course currently available on the server, you'll see something like this in the log:

If you see a ✓, it means that Rufus validated the SHA-256 of the downloaded content and found that it matched one of the entries it has in its DB.
If you see a ✗, it can mean one of a few things:

The downloaded file is more recent than something we had on the server had the time of the release. For instance, if Syslinux 6.04 is officially released tomorrow, and you happen to have a distro that uses 6.04, you would see an ✗ even if the file you downloaded is identical to the one I placed on the server, since the DB goes only as far as files that were present at the time of the release

Your download is corrupted (can happen if you have one of these firewalls that alters content)

Someone is doing something very nasty with the files your are downloading.

At any rate, if you are a security conscious user, you'll probably want to check if there are any ✗'s in your log...

I also suspect that some of the people here might be interested with that claim of Windows having a bug that can render a GPT disk inaccessible after cleanup. This is all detailed in issue #759, but if you are the inquisitive type (and have a real Linux machine available to repartition or clean your drive, as you will NOT be able to recover your drive from Windows alone!), you can download the following ChromeOS image, write it in DD mode (preferably NOT using Rufus, so that you don't try to place the blame it) and then issue a clean in diskpart... Now try to format/partition it. Interesting behaviour, heh?

I was repeatedly able to produce the issue with Windows 10 (10586) x64, and my understanding is that Windows IOCTL_DISK_CREATE_DISK is not a thorough as it should and leaves artefacts behind that throw Windows off. Oh, and please don't blame me for a new set of nasty pranks, that'll make people believe their USB drives are dead...

There exist some Windows disk drivers out there, such as the O2 PCI-E SD Card one, that require read buffers to be aligned to at least 8-bytes when issuing a ReadFile(). Failure to use aligned buffers results in an ERROR_INVALID_PARAMETER code being returned. So Syslinux' libfat/cache.c might require the use of _aligned_malloc() as well as aligned structures to properly work on Windows.

I'll see if I can send a patch about this to the SL mailing list, but it might be a while before I do so...

And thanks for finding those queer behaviours of Windows diskpart and of thos disk/filesystem drivers.

Maybe the "you will NOT be able to recover your drive from Windows alone!" is a tad bit too scary, if I get it right all is needed is to wipe/00 out a few sectors to remove diskpart clean left overs. using a disk/hex editor or any dd or similar.

if I get it right all is needed is to wipe/00 out a few sectors to remove diskpart clean left overs.

That'll only work as long as you haven't issue a clean/IOCTL_DISK_CREATE_DISK (which is what Rufus does now, to work around the issue, as we used to start repartitioning with an IOCTL_DISK_CREATE_DISK only). But if you did, then Windows seems to completely lose its marbles with regards to that drive, and is no longer able to wipe sectors to restore it. At least, that's what I found during my testing.

Granted, I haven't spent that much time exploring all possibilities to fix such a drive from Windows (maybe there's still a way - for instance, I haven't tested plugging the drive on a different Windows machine). But as far as I am concerned, the only thing that worked was resetting the drive from Linux, coz Windows was a complete NO_GO.

Oh, and since this also recently came to my attention, if anyone wants more fun with USB drives that make Windows go crazy, you can also try and download OpenVMS for Itanium here (I64VMSV84withUpdate1000.iso - 4GB) and burn it in dd mode with your favourite dd app. Guaranteed to BSOD any Windows, from XP to 7, as soon as you plug the drive...

So one possible workaround would be to write the MBR or GPT partition tables with zeroes, in sector mode, as Win32DiskImager does, before we attempt any further cleanup operations.

Which left me with the idea that direct disk access is still possible (even after running that command) .

In any case (in theory) disconnecting the device and re-connecting it should be enough to "clear" the leftovers of the command, unless *something* is written to the actual device (or to a "permanent" setting, like - say - the Registry) that makes it *somehow* "read only" or "inaccessible".

Seen from the other side (if the behaviour is confirmed and reproducible) it could be a way to -somehow- force a "read only" flag on a device and/or make it accessible only on non-Windows (10) OS, etc., which might be useful for *something else* (though right now I have no ideas what that use could be).

It is also possible that the situation is "initiated" by the combination of that (those) particular GPT images and the "diskpart clean" by that the bug is actully *somewhere else*, like in a HAL driver, in a IFS detector, mount manager, etc., in any case very interesting find and something to keep an eye on.