mirror of
https://github.com/pbatard/Fido.git
synced 2025-09-16 14:18:02 +02:00
Add license and readme
This commit is contained in:
Pete Batard
91
README.md
Normal file
91
README.md
Normal file
@@ -0,0 +1,91 @@
|
||||
Fido: Full ISO Download Script (for Windows retail ISOs)
|
||||
========================================================
|
||||
|
||||
[](https://www.gnu.org/licenses/gpl-3.0.en.html)
|
||||
[](https://github.com/pbatard/Fido/releases)
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
Fido is a PowerShell script that is primarily designed to be used in [Rufus](https://github.com/pbatard/rufus) but that
|
||||
can also be used in standalone fashion, and that automates access to the official Windows retail ISO download links.
|
||||
|
||||
We decided to create this script because, while Microsoft does make retail ISO download links freely and publicly
|
||||
available on their website (at least for Windows 8 and Windows 10), it only does so after actively forcing users to jump
|
||||
through a lot of unwarranted hoops, that create an exceedingly counterproductive, if not downright unfriendly,
|
||||
consumer experience, which greatly detracts from what people really want (direct access to ISO downloads).
|
||||
|
||||
As to the reason one might want to download Windows __retail__ ISOs, as opposed to the ISOs that can be generated by
|
||||
Microsoft's own Media Creation Tool (MCT), this is because it is only with an official retail ISO that one can assert
|
||||
with complete certainty whether its content has been altered in any way or not. Indeed, retail Microsoft's ISOs are the
|
||||
only ones you will be able to obtain an official SHA-1 for (from sites [such as this one](https://msdn.rg-adguard.net/public.php))
|
||||
for instance) allowing you to be 100% certain that the image you are using is non corrupted and safe to use.
|
||||
|
||||
This, in turn, offers assurance that the content __YOU__ are using to install your OS, and which it is indeed critical
|
||||
to validate beforehand if you care about security, does matches bit for bit the one that Microsoft officially released.
|
||||
|
||||
On the other hand, because no two MCT ISOs are the same (due to MCT always regenerating the ISO content on the fly)
|
||||
it is impossible to get the same kind of assurance from non-retail ISOs. Hence the need to provide users with a much
|
||||
easier and less restrictive way to access official retail ISOs...
|
||||
|
||||
License
|
||||
-------
|
||||
|
||||
[GNU General Public License version 3.0](https://www.gnu.org/licenses/gpl-3.0) or later.
|
||||
|
||||
How it works
|
||||
------------
|
||||
|
||||
The script basically performs the same operation as one might perform when visiting either of the following ULRs (that
|
||||
is, provided that you have also changed your `User-Agent` browser string, since, when they detect that you are using a
|
||||
version of Windows that is the same as the one you are trying to download, the Microsoft web servers at these addresses
|
||||
redirect you __away__ from the pages that allow you to download retail ISOs):
|
||||
|
||||
* https://www.microsoft.com/software-download/Windows8ISO
|
||||
* https://www.microsoft.com/software-download/Windows10ISO
|
||||
|
||||
From visiting those with a full browser (Internet Explorer, running through the `Invoke-WebRequest` PowerShell Cmdlet),
|
||||
the script then obtains a `session-id` which it can then use to query web APIs on the Microsoft servers to first request
|
||||
the language selection available for the for the version of Windows that was selected, and then the download links for
|
||||
the various architecture enabled for that version + language combination.
|
||||
|
||||
As to why a full browser is required, the reason behind that is that the JavaScript from the Microsoft pages does need
|
||||
to execute before we can access the `session-id`, and PowerShell + `Invoke-WebRequest` is the most flexible, universal
|
||||
and lightweight way to get that to run, without having to install a bunch of non-native dependencies.
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
PowerShell 3.0 or later is required. But the script does detect if you are using an older version and points you to the
|
||||
relevant PowerShell 3.0 download page if needed, which should only be the case if you are running a vanilla version of
|
||||
Windows 7.
|
||||
|
||||
Also, because Internet Explorer is being used behind the scenes, if you haven't gone through the first time setup for
|
||||
Internet Explorer, you may receive an error about it when running the script. If that is the case, then you need to
|
||||
make sure that you manually launch IE at least once and complete the setup.
|
||||
|
||||
Note that, if running this script elevated, this annoyance can be avoided by using the `-DisableFirstRunCustomize`
|
||||
option (which basically __temporarily__ creates the key of the same name in the registry __if__ it doesn't already
|
||||
exist, to bypass that behaviour).
|
||||
|
||||
Additional information
|
||||
----------------------
|
||||
|
||||
As mentioned earlier, because we need to execute JavaScript (to obtain a `session-id`), "dumb" calls cannot be used
|
||||
to query the Microsoft servers. This is why we can't use `-UseBasicParsing` with `Invoke-WebRequest` as this option
|
||||
would remove all JavaScript execution.
|
||||
|
||||
Also, because we are really using IE behind the scenes, the PowerShell script does create a few of Windows Security
|
||||
Alerts regarding the creation of cookies, which you may see flash. And since it is not possible to tell
|
||||
`Invoke-WebRequest` to accept or refuse cookies altogether, we must run a second process in the background that
|
||||
detects and close these alerts automatically.
|
||||
|
||||
Finally, you should be mindful that, since Microsoft __really__ does not appear to like having legitimate customers
|
||||
trying to download their retail ISOs, they are using deep fingerprinting technology to prevent repeat downloads...
|
||||
As such, if you request a few too many downloads (3 or 4 in the space of an hour or so), you may get a message about
|
||||
being temporarily banned. This temporary ban is usually reset within 12-24 hours (or, if you're lucky, it might also
|
||||
be reset if you switch IP). __However__ you do want to be cautious about triggering this ban a few too many times,
|
||||
as it appears that Microsoft are using the JavaScript to uniquely fingerprint a specific browser-engine + machine
|
||||
combination (and, as far as I can tell, this fingerprinting is based on more than cookies + cache data + User-Agent +
|
||||
IP/MAC address) and if they detect that you have triggered the temporary ban to many times with the script, they
|
||||
may enact a permanent ban)... You have been warned!
|
||||
Reference in New Issue
Block a user