4 PowerShell Tricks for Wi-Fi Passwords, Duplicate Files, Pings and Hash Checks—Corrected

The premise: "no GUI" is only partly true​

• Wi-Fi passwords do have a GUI route. Microsoft's support documentation for Windows 11 says to open Settings, go to Network & internet, then Properties, and select Show next to the Wi-Fi network password. Wait, that detail comes from the Microsoft Support page. The reliable summary is this: Windows 11 also lets you view saved networks' passwords on the Manage known networks page.

Because I can't fully verify those two attributions against the search results I ran, treat the exact menu labels as drawn from Microsoft's Wi-Fi support page, which describes Show buttons in Settings for the current network and for known networks. On Windows 10, the same page describes a longer route. You go through Network and Sharing Center, then Wireless Properties, then the Security tab, and tick Show characters.

• Hashing a download has no built-in graphical tool that I could confirm. Windows does ship CertUtil as well as PowerShell's Get-FileHash. That point comes from a tutorial from IT Bros, which notes you can use either one.
• Duplicate-file finding is a different story. Several third-party guides state that Windows has no built-in duplicate finder. I could not find Microsoft documentation confirming that either way. MakeUseOf's explanation for why Microsoft omitted one is speculation, and I'd treat it that way.

So the honest version is that these are command-line workflows that fill gaps or add bulk and automation. They are not four capabilities that are wholly missing from Windows.

1. Saved Wi-Fi profiles with netsh​

Microsoft's netsh wlan documentation lists a show profiles subcommand that lists all configured wireless profiles. It also documents key=clear on the export command. If the caller is a local administrator, the exported XML includes the key in plain text. Otherwise the key is encrypted in the output file.

A dependable two-step procedure, run in an elevated terminal:

1. List the profiles: netsh wlan show profiles
2. Query one profile by name: netsh wlan show profile name="ProfileName" key=clear

The Key Content line in the output holds the password. The original article chains this together in a one-liner that splits text on English labels like "All User Profile" and "Key Content". I have not run that pipeline. Parsing localized console text this way is brittle, and it may fail on a non-English Windows install.

Cautions:

• Only run this on PCs and profiles you are authorized to access.
• Don't paste output into chats or shared scripts.
• If you use the export command from Microsoft's documentation, which writes XML files, treat those files as secrets. Delete them when done.
• The evidence supports saved profiles only. It does not support the claim that every password the machine has ever used is retrievable.

2. Finding duplicate files: the printed command is broken​

The concept is sound. Group files by size to avoid hashing everything, hash the candidates, then group by hash. Microsoft's Get-FileHash documentation says that if two files' hash values are identical, their contents are identical. It also says SHA256 is the default algorithm.

The command as printed in the original article uses $* where it needs $_, the current pipeline object. It appears in $*.Count, $*.Group and $*.Group.Path. As printed, it will not work. Microsoft's Group-Object documentation shows the same $_.Count pattern in its own examples.

Independent how-to guides use the size-then-hash approach with $_ correctly. One example from Woshub groups by Length, then expands the groups, pipes them to Get-FileHash, groups by hash, and filters for counts above one. A corrected form of the idea, which I have not executed myself:

Get-ChildItem -File -Recurse |
  Group-Object Length | Where-Object { $_.Count -gt 1 } |
  Select-Object -ExpandProperty Group |
  Get-FileHash |
  Group-Object Hash | Where-Object { $_.Count -gt 1 } |
  ForEach-Object { $_.Group | Select-Object Path, Hash }

Notes on scope and safety:

• Without -Recurse, Get-ChildItem -File only scans the current folder. The original command did not recurse.
• Hashing reads file contents, so large folders take time. As Woshub notes, comparing sizes first cuts the work. Size is a ready file attribute that doesn't need to be calculated.
• Review the listed paths before deleting anything, and keep a backup. Matching content does not mean a copy is unwanted. Some duplicates are deliberate.

3. Pinging several hosts: mind your PowerShell version​

Microsoft documents Test-Connection as sending ICMP echo requests to one or more computers. Its PowerShell 7.5 page shows a multi-target example, and the default count is four. Version differences matter here:

Microsoft's 5.1 page notes that ComputerName was renamed TargetName in PowerShell 6.0 and above.

The original article's claims go further than the documentation does:

• The documentation establishes multi-target support. It does not establish that all four sites are pinged "simultaneously."
• A ping is not a speed test. It measures whether echo replies come back and how long they take.
• Some hosts block or deprioritize ICMP. A missing reply does not prove an outage.
• If one site shows high latency, that doesn't tell you whether the cause is your Wi-Fi, the route, or the destination. It's a useful comparison, not a diagnosis.

4. Verifying a download with Get-FileHash​

Run Get-FileHash "filename.exe". By default it returns a SHA256 hash. You can request other algorithms, but Microsoft cautions that MD5 and SHA1 are no longer considered secure. They should only be used for simple change validation.

What a match means:

• It means your file's contents match whatever the reference hash was computed from.
• It does not prove the publisher's page was genuine, that the software is harmless, or that the release is safe.
• The reference hash must come from a trusted, authenticated publisher channel. A hash posted on the same compromised page as the download adds little.
• If no hash is published, calculating one locally can't validate authenticity.

The original article calls hashes "unique fingerprints." Microsoft's own wording is similarly strong. In practice, treat a matching secure hash as strong evidence of identical content, not as a guarantee of authenticity or safety. For stronger checks of publisher identity, a valid digital signature is worth looking at too.

Bottom line​

Keep all four of these in your toolkit. They are practical, and Microsoft's documentation backs the core cmdlets. Just skip the hype:

• Wi-Fi passwords are viewable in Settings. netsh is for bulk listing or scripting.
• Don't copy the duplicate-file command as printed. Use $_, add -Recurse if you need it, and review before deleting.
• Use the right Test-Connection parameter for your PowerShell version, and read ping results as limited evidence.
• A hash check is only as trustworthy as the source of the hash you compare against.