Trying to decrypt a string with md5 and shasum


New Member
Aug 13, 2019
Reaction score
Hello, I no longer work in IT but in the past I tried to learn Linux a few times but failed because it was just too complicated. Today I have only access to a linux command line of a web server and one on my OpenWRT router. I am trying to go both ways, first to encode the word "admin" and then decode it. I have tried this syntax on both the Linux systems I have access to and neither work.

Here is a paragraph I copied from the SuperUser website on what I need to do to make this work:

You'll need to generate a new password hash using the formula SHA256(MD5(new password)). Test to make sure you can generate the same hash as the root account in the file by testing with 'admin'.

On a Mac

echo -n admin | md5 | tr -d '\n' | shasum -a 256



THanks in advance! Again I would like to figure out how to apply this syntax to get a successful code/decode.
Last edited:

G'day @DonJuane and welcome to :D

I am moving this Thread to Command Line, where questions such as yours are better answered.

Good luck

Chris Turner
putting it succinctly my understanding is this: There are 2 approaches to passwords "encryption" and "hashing". With encryption its possible to go back to original password. With hashing on the other hand its a one way process. So you might ask if you can't get back to original password , how on for instance web gui login do you know when someone enters their password it a correct one? Well if your the web master & you have someone's hashed password in a database and of course you know how it was done, you have to take a pasword some enters hash it the same way & compare that hashed password with the hashed one in the db. Does that make sense ? SHA256 i believe was one of the first hash. Thus you can't go back
  • Like
Reactions: Rob
Thanks for reply. So you say that there is no "reverse" to convert the long string of numbers starting with 465.... back into the password which is "admin" in this case. If I have the long number string above, even though it is "hashed" and not encrypted (not sure if they are the same thing) then having the long number string, there is no magic command string that can turn this long string back into the word "admin"? Correct?

**** Incidentally this value is located in an XML file that is a configuration file for a Huawei router.
What I am trying to do is bridge a fiberoptic router to an OpenWrt router and I need my SIP password so I can use another ATA to access my VOIP service without using the telco's router because the internal ATA on the telco's router stops working when I bridge off that OTA to a conventional router.
This stuff is over my head... but Google is pretty smart. Check out this link to learn differences between encryption, hashing, and salting.

My best guess at the moment is... yes, your gibberish string of characters CAN be converted to its actual value, but it is very unlikely that you will be able to do that yourself. What good would all this security be if it were all so simple to hack?

I think its done is from many levels, knowing that keeping this stuff out of the user's hands (allowing them to know their SIP phone ID and password that they pay monthly for keeps them from screwing up their router and generating a phone call to the support center when they mess it up. It's not actually a true security issue since I don't think a key is even involved. It's like zipping something for a world that's never heard of zip. Just enought to keep the day to day riff-raff out LOL.
Well, if it were a REALLY simple system, it might use base64 encode and decode. Filezilla used to use a plain text config file where FTP passwords were stored with this simple method. Oops! I don't know about your router.... but I sure hope that mine is harder to crack. :eek:o_O:D

You may find the solution you are looking for, but that kind of stuff is pretty far above my pay grade.

Hashing is NOT encryption - you cannot de-hash/un-hash something to determine its original value.

Storing passwords as hashes, or as "salted hashes" or "salt and peppered" hashes is a relatively secure method of storing password information.

It's many orders of magnitude more secure than storing passwords as plain text, because you don't have any copies of the users passwords - only hashes of them. Whenever the user tries to log-in - you hash the string they entered on the login page and then compare it against the hashed value that is stored for that user. If the hashes match - you know that the user entered the correct password - without ever having to know what the users actual password was.

And this is a pretty secure way to do things.

However - if somebody breaks into your website and steals your database (or if a website has a malicious administrator) - they could easily write a script, or program which uses a pre-hashed dictionary of commonly used passwords (aka a Rainbow Table) and then compare the hashes in their dictionary/table against the hashes stored in the database - in order to try to deduce the users passwords.

"Salted" hashes are even more secure than plain hashes.
If you use salted hashes - you'd typically assign each new user a randomly generated "salt" value when they sign up - the salt value will be used to alter the result of the hash slightly. The salt value is stored alongside the users login information and their password hash.

When a user logs in, you look up that users salt value, then you salt and hash the password they entered in the login page and compare that against the hash in the database - if the hashes match - the user entered the correct password, so you let them in!

A determined attacker could still write a script to generate a salted, hashed dictionary. But it would take a lot longer for them to crack every password in the database, because they'd have to salt and hash their entire dictionary each time, using each users "salt" value.

And if you add a randomized "pepper" value for each user - things become even trickier for attackers.

So hashing is a pretty secure method of authenticating users passwords - as long as you use a reasonably complex method of hashing the passwords. And as long as your users don't stupidly use anything too simple, or too common for their password!

One other very minor problem with using hashes is the possibility of hash-collisions. With hashing, there is always the risk that two or more distinctly different input values could result in the same hash value being generated.

So it is possible that someone could enter a completely different password that yields the same hash-value.

By the very nature of hashing - hash collisions can never be completely ruled out. But with SHA-256 and the newer SHA-3 method - there is less chance of collisions occurring - compared to older methods like MD5 and SHA-1.

But if you want to encrypt something and then de-crypt it, you will need to use true cryptography, NOT a hashing algorithm!

Members online