It is obfuscated in a way that will still avoid detection during static code analysis and casual code review.
This looks like debug or logging string builder which no one would give it a second look while glancing over it.
Hashes and binary blobs will look out of place, same thing goes for intentionally obfuscated secure string builder.
When you put in a back door the best one will always be the shortest possible complicating it will only increase the likelihood of it being detected.
The sign of a true high level adversary isn't overly complicated and obfuscated software but one which is remarkably simple and elegant whilst still achieving the desired functionality.
Obfuscation and complexity screams cyber criminals which care more about covering their own trail than ensuring functionality.
From a very practical standpoint - obfuscation and complexity also makes it more likely that the code will be broken in the future. Not broken like "discovered and disclosed" but broken like: "it doesn't work any more".
I mean - it's not like the unit tests are going to contain check_backdoor_works() (etc).
So the simpler and more straight forward you can get your backdoor snuck in - the longer you can know it will remain, and keep working.
No, your run of the mill malware and back doors which are implemented by people without much real trade craft experience that like to show off being smarter than anyone else - cyber criminals.
Spies rarely are egotistical and never are flashy, James Bond is pretty much the most anti-spy as one can get :)
I agree that functionality and simplicity is very important, but having the password in plaintext is just sloppy. LukaAI suggested using a hashed password. Surely that would have been much better at containing the fallout.
A hashed password means that you have to implement the entire hashing mechanism to evaluate it that will take a huge amount of code compared to a single string compare.
The hash string value will also be detected by most common static analysis rules which look for hashes and strings that look like passwords in the code.
The beauty of this hack is that even if you are looking for hard coded credentials you are likely not to find them as that PW string will not trigger any reasonable regex which will look for a clear text passwords (or a hashed one for that matter).
You wouldn't have to implement sha1(), I bet it's already there. It'd be the same as calling strcmp; the difficulty is hiding the hash (although it probably wouldn't be the only "magic number" in their code), but given enough time and creativity you could come up with a clever solution. For example, you could check one byte of the hash at a time in different parts of the auth function.
You would have to implement it somewhere which means you'll either "import" it which will add it to the assembly or have to call functions / services which handle SHA1.
One of the common techniques in static code analysis is to cross reference function calls against a desired state and to flag any undocumented links which again increases the likelihood of your backdoor being detected.
This looks like debug or logging string builder which no one would give it a second look while glancing over it.
Hashes and binary blobs will look out of place, same thing goes for intentionally obfuscated secure string builder.
When you put in a back door the best one will always be the shortest possible complicating it will only increase the likelihood of it being detected.
The sign of a true high level adversary isn't overly complicated and obfuscated software but one which is remarkably simple and elegant whilst still achieving the desired functionality.
Obfuscation and complexity screams cyber criminals which care more about covering their own trail than ensuring functionality.