Luigi Auriemma

Hello, id like to translate the programm steampwd to Delphi, but i can't C, so i have a big Problem, because i don't understand who this programm works.

Can anybody help me to translate this to Delphi?




(Sorry, for my bad english.)

the short way is without any doubt crypto++, hoping about the existence of a Delphi wrapper naturally.
the long way instead is the solution I adopted which means the manual usage of SHA1, MAC and AES.
The third solution, which is also simple, is the usage of a dll which contains the needed code.
In any case depends by your programming skills and the license you want to adopt.

i would choose the longer way wich is more difficult.

(my delphi skills are mediocre)

Ok, the first things you need to collect for decoding the Steam password are 3 registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProductId
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid
HKEY_CURRENT_USER\Software\Valve\Half-Life\Settings\io

then concatenate the collected strings in that order (so "ABC"), the result is your decryption key.

Now the long part and I hope you will find the correct algorithms somewhere (this is the real long part).
The first thing you must do is converting the encrypted password from hex to byte, so "0123AB" becomes a bytes string of 0x01 0x23 0xab, in short its length will be half.

The resulted data, which we will call input, is divided in the following way:

PASSWORD|IVSEED|HMACSHA

PASSWORD is your encrypted password which usually has a fixed length anyway remember to get these 3 fields from the "right" since only IVSEED and HMACSHA have an officially fixed length
IVSEED is a field of 8 bytes which contains additional data used for a better encryption
HMACSHA is a filed of 20 bytes used as a signature, something like a checksum

Take your decryption key and retrieve its SHA256 hash, the result will be called key

the HMACSHA field is better if for the moment is not considered since it's not useful for the decryption, it's only for verifying if the input password is correct

Now you must call a function called AESPHM_GenerateIvFromSeed which in short does the following:
- SHA256 of IVSEED
- the resulted 32 bytes data must be xored in the following way, first byte with byte at offset 16, second one with byte at 17 and so on until byte 16 with byte 32
- the result is a 16 bytes data called iv

We have almost finished, set key as AES encryption key (note, encryption not decryption, anyway the type could change in some implementations of the AES algorithm).

now "encrypt" (same matter of before) all the PASSWORD field seen before using AES CFB128 with iv offset set to 0 (naturally, in case your implementation supports this field) and the iv field (that one of 16 bytes) calculated in the previous step.
Note that I'm talking about standard algorithms (OpenSSL compatible) so their usage and their fields are the same everywhere, nothing complex or strange.

The resulted data is divided in:
PADDING_LEN|PADDING|DECRYPTED_PASSWORD

This first byte (PADDING_LEN) is used for telling how much padding bytes exist in the encrypted password, in short it's the amount of byptes we need to skip.
To calculate the size of PADDING do:
paddingLen = (byte & 15) + 3

DECRYPTED_PASSWORD contains your decrypted password so just skip 1 + paddingLen to reach this field.
Done.

Now a note about the AES_CFB128 encryption, for some unknown reasons Crypto++ applies "encryption" with the IV XORing (the CFB part) of "decryption" so if you use the standard algorithms you will see only the first 16 bytes of PASSWORD, since the rest are invalid due to the differente XORing of the data.
When you will reach this point we can discuss about how to modify AES for adapting it to Crypto++.

Well, this is the long way which is absolutely not long or complex but naturally the inverted AES (and HMAC in case you want to implement also the check) could be a problem in some cases with some programming languages.

Product ID:
MachineGuid:
io:

is this theDecryption Key of my PC?:

if the registry keys are exactly those you have pasted, your decryption key is:

5527r-014-2059203-22k82355f4584-ba15-4380-a994-34f485cc410a12019s1713

Anyway the full decryption key is also showed by steampwd when you try to decrypt your blob file.

i was also interested in this matter was just wondering if this delphi project of yours was open source?

i got
55274-648-8637434-239876c230c34-07c8-4a4c-82ef-dce7a58e8eba1069231698
and i dont understand how to Decrypt this
PLEAS ! PLEASEEEE Help me!!!
I must to decrtypt this to get my steam back..
i try to use: http://www.chilkatsoft.com/js-aes-decrypt.asp
and i dont know howto use... HELP!!!

if you want to recover your password use steampwd:

http://aluigi.org/pwdrec/steampwd.zip

launch it, select your clientregistry.blob file and if it contains your saved password it will visualize it.
otherwise means you cannot retrieve it

Is the [key] parameter in steampwd for providing a decryption key?

I extracted the .blob and the registry key values from an HDD image of my previous install. I was hoping I could pass that .blob file and those concatenated registry values to retrieve my password (and avoid having to restore the backup just to run steampwd).

Here is how I format it(borrowing hihoo's key for the example):

I'm getting the "wrong key (another computer?) or encrypted password" error when I try.

Is there a way to do this on a different install if I have the information of the previous?

Thank you for your help.

the [key] parameter is used for specifying the key exactly as you did in your example.
And naturally if you specify the correct key you can use steampwd on any computer.
So the only hypothesis is that you are using a wrong key, have you verified it?

I will recheck now. The only odd thing out that comes to mind is that my current OS install is Vista 64, and my previous one that I'm browsing a backup image of is Vista 32. So the productID is located in a slightly different spot:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId

Would that make any difference?

I will recheck my values and edit my post.

Went through the process again, and can't find my mistake.

I browse the old image and extract:

C:\Program Files\Steam\ClientRegistry.blob

C:\Windows\System32\SOFTWARE

C:\Users\"MyoldUserAccountName"\ntuser.dat

Then I open regedit and select load hive.

I load SOFTWARE and ntuser.dat and locate these three registry values within those loaded hives:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid
HKEY_CURRENT_USER\Software\Valve\Half-Life\Settings\io

Concatenate them:
89578-015-5401684-713308aec7f9e-e43d-44d8-951f-477389fc8f451176496950

Then run steam password, passing in the .blob I had extracted and the key, and it returns an error. :\



See anything off-hand that I might be doing wrong?

Thanks again.

uhmm if steampwd returns that error there is not much to do, it means just that the signature of the encrypted password doesn't match the one obtained using that specific key.
Have you recompiled steampwd or you are using the original steampwd.exe included in the zip?

Because some users reported some fails with steampwd recompiled by them while the one compiled by me has ever worked (so this is only a side note to remove this exception from the hypotesis of your problem)

I just used the Guid and io by themselves to make my key, and not my productID, and it worked perfectly! I'm guessing on Vista the encryption key does not use the productID?

As a test, I saved my recovered password in steam on my current machine. Then I ran steampwd again to see if it would work, but it errors. So, it appears steampwd does not work in Vista 64 just using the .blob file. A key made up of only the machineguid and io passed as an argument is the only way it will work.

Thank you again for you help. I wish the third party software we pay thousands of dollars a year in licensing fees for that we use at work had support as good and as transparent as yours. Thanks.

By the way, I used the original steampwd.exe included in the zip.

Argh I missed completely the post in which you talked about Vista... oh my distraction.

I have just released a new version of steampwd which solves this problem, in reality this "new" method is exactly the old one I used some versions ago eh eh eh
Please try it, so we can finally close the Vista problem definitely.
Thanx

I tried version 0.2.2 on Vista 64 and it worked perfectly! Thanks