Found out myself digging through the source code:
The WinWlanCredentials constructor is defined, which initializes the hWlanApi handle by loading the wlanapi.dll library using LoadLibraryExA function.
The constructor proceeds to open a handle to the WLAN API using WlanOpenHandle function. It checks if the handle was opened successfully and returns if there was an error.
The WLAN interfaces are enumerated using WlanEnumInterfaces function, and for each interface, the code checks if it is in the connected state. If not, it continues to the next interface.
The current connection information for the interface is obtained using WlanQueryInterface function with the wlan_intf_opcode_current_connection opcode. The SSID of the connected network is extracted from the obtained connection attributes.
If the SSID is empty, the code continues to the next interface.
The code then retrieves the list of WLAN profiles using WlanGetProfileList function.
It iterates through the list of profiles and checks if the profile name matches the SSID of the connected network.
If a matching profile is found, the code retrieves the XML content of the profile using WlanGetProfile function. It extracts the PSK from the XML using a regular expression and stores it in the _psk member variable.
So, the interesting part:
In the Windows-specific implementation provided, the code retrieves the Wi-Fi password (PSK) from the WLAN profile stored on the system. The password is obtained in plaintext form directly from the profile, without encryption.
When a user connects to a Wi-Fi network and enters the password, Windows stores the network's profile, including the SSID and the password, on the system. By default, the password is stored in an encrypted form in the WLAN profile XML file. However, Windows provides an API function called
WlanGetProfile with the
WLAN_PROFILE_GET_PLAINTEXT_KEY flag, which allows retrieving the password in plaintext form.
The ability to retrieve the password in plaintext form requires administrative privileges (regular users do not have access to the plaintext password through the WLAN API). I.e., if the code is running with administrative privileges, it can retrieve the password using the WlanGetProfile function with the appropriate flag.
However, I feel like it's a bad design in Windows--that permisions for a process launched by an admin are blanket and not granular: you may want to install an app, but it doesn't mean you necessarily want it to be able to siphon in your credentials.