Cou7ld you actually ask the creator of the software?
Bit out of my depth here. There's a PE32 executable here that permits three levels of user functionality, according to a password entered during execution: None, Medium & Admin. Already have the lower two level passwords, but would like to get admin level functionality. A simple text search of the executable doesn't find the known password, or any obvious hiding of a password.
Within the executable, there are a few text labels that appear to be related to password entry. I've loaded the file into PEbrowser and attempting to pick apart the code, but going nowhere fast - last assembler I ever played with was back in 8 bit days!
Would like to get some hints or ideas.
Look Here -> |
Cou7ld you actually ask the creator of the software?
I'm out of my mind, but feel free to leave a message...
That request was denied, even though I'm part of the beta test. Hence the query.
It appears as if ALL text displayed on-screen in the software is either encrypted or otherwise obfuscated. A spelling mistake with one of the on-screen input fields is not found anywhere within the executable or it's support dll with a simple text search. Guessing the same method is used to hide the user level passwords as well. For such a simple little program, it's been quite cunningly crafted. Wasn't expecting that given the speed at which it was created & published and how many bugs still remain in it.
Is this for the new version of greywolf floating around?
xapi (30-09-17)
Back in the olden days (early 90's) much of the text info stored in binaries on the old Amiga 500, was just bit shifted, to scramble it. This was usually for stored info that you entered, like user name, or games scores etc, but also quite often passwords. All you did was load the file into a hex editor that had "bit shifting" capabilities, and start clicking on the shift right or shift left button, till the garbled text in the hex pane revealed the stored text. It was also a great way to edit the score storage section on certain games, so that your kids wondered how you scored such an impossibly high score in their favourite game :-)
Of course there are many other ways to scramble the info, but you never know... Also, depending on the size of the file, it can be rather tedious, sifting through file part by part, depending on how much is displayed in the window. We used to look for patterns of areas with lots of ascii characters, then start shifting. If anything started to line up, you move further up and down the file, to see if there was more...
No, it's for a two way radio configuration application (not Big M, either). But there's a name not heard for a while!
And thanks for the trip down memory lane, Bob. I had one of those Amigas as well. Following your lead re: bit shifting unfortunately didn't find anything even remotely likely.
bob_m_54 (06-10-17)
This sort of thing interests me too, although I haven't done anything like password discovery/analysis for many years.
You might find the article at to be useful.
The article appears to be repeated at , but it might differ a little upon further reading.
Guess it would help that in this instance I know what at least one password plaintext and it's .ini file encrypted form is...? None of the online hash table based password decrypters are coming up with a match so far. Wondering if the same encryption is used to hide the passwords within the exe as well?
Probably slightly easier to bypass the check than figure out the password. Might even be able to bypass it using cheat engine. I'm really curious now and would love to give it a try but you probably want to figure solve it yourself.
Last edited by Sektor; 05-10-17 at 06:47 PM.
mitaux8030 (07-10-17)
Thanks for that idea Sektor, downloaded and been having a ball with Cheat Engine. The author has a wicked sense of humour too.
But so far, nothing has popped out with Cheat Engine's tools. What is apparent is that the software is very cunning indeed! Encrypted text, random addresses for storage of credentials etc. I can see I'll have to learn modern 32/64 bit assembly - a far cry from the 8 bit Z80, 6510 & 68000 stuff I messed around with as a kid.
There used to be some powerful debugging tools available for windows versions up to XP, not sure if any of those are usable in later win releases. They allowed setting of breakpoints at specific memory locations and calls to selected dll library functions so you could pause the running program at the point where the decision was made as to whether the password you entered was correct or not and memory / register contents at the breakpoint could viewed & searched to see what the correct code actually is along a disassembly listing. You could even simply change the jmp instruction after the compare so that every password except the correct one was accepted in some simple protection schemes EG cmp x,y jmp z xxxx could be altered to jmp nz xxxx. Not sure if schemes as simple as that are about these days though.
Numega 'Softice' was a very popular debugger but that was ages ago.
Last edited by Skepticist; 08-10-17 at 05:40 PM.
Sektor (08-10-17)
Starting small here with x86 assembler. Another executable which is considerably more simple, written by the same company, also uses a password to unlock extra functionality. This time, the password wasn't hidden / encrypted within the executable. Using CheatEngine, I inserted a breakpoint when the executable accessed the memory address where the password text was stored. This is the code that CE highlighted around that.
75 3C - jne MSVCR90.strcmp+4C
8B 02 - mov eax,[edx] (memory location at edx was where the user input text for the password was stored to)
3A 01 - cmp al,[ecx] << (comparison of entered password & expected password done here, memory location ecx was where the expected password was stored)
75 2E - jne MSVCR90.strcmp+44
0A C0 - or al,al
Pretty simple question here: can someone help explain how the above routine does what it does?
Hoping that once I understand the mechanics of what's going on here, I can look for a similar routine in the other executable, and see what it's comparing to what, which may reveal the password(s) I'm looking for...
What I see there is a compare of only the least significant byte of the password (cmp al,[ecx]) and an exit if it fails (jne MSVCR90.strcmp+44) so that appears to be just the start of the verification process and it's happening within the strcmp (string comparison) function of the visual C library. Examine memory at [ecx] and you could be lucky enough to see the correct password but that would be a terribly insecure type of protection IMO but you never know. You'd have to trace through single stepping and forcing all the character compares to succeed to be sure but I'd expect a bit more 'magic' to be going on
You need to trace through to where it returns to the program from the MSVCR90 library after a valid comparison for all characters to see what the program does after that (hopefully accepts the input) but there could be further validation after that like a registry entry compare, something uniquely specific to your PC or it could even 'phone home' for further validation (if you're online at the time).
Last edited by Skepticist; 13-10-17 at 11:42 PM.
Well look at that. Unicode encoded password, separated by a pair of null bytes between each character. Password found! Knowing this now, a few new searches have revealed no other secret passwords - just those three levels of access.
But... the passwords didn't unlock the extra functionality that was hoped for. There's one particular function I'd like access to, and remnants of the code are still there (looking at the text tags used in the executable and information buried in the help file seem to suggest so anyway) and there are configuration bits in the saved config file that can't be changed by hex-editing that config file. The software forces those bits back to default before sending them via the USB to the programmed device - I monitored the USB port to confirm that. So there's something special about those bits that the software definitely doesn't want to give up access to. I might have to dive in to the code a bit deeper to bypass that
bob_m_54 (14-10-17),Sektor (14-10-17),technoweenie (14-10-17),tristen (14-10-17)
Bookmarks