Results 1 to 15 of 15

Thread: Finding password in executable

  1. #1
    Senior Member

    Join Date
    Jan 2008
    Location
    A rock in the ocean
    Posts
    752
    Thanks
    99
    Thanked 135 Times in 79 Posts
    Rep Power
    290
    Reputation
    3356

    Default Finding password in executable

    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 ->
  • #2
    LSemmens
    lsemmens's Avatar
    Join Date
    Dec 2011
    Location
    Rural South OZ
    Posts
    10,573
    Thanks
    11,853
    Thanked 7,053 Times in 3,334 Posts
    Rep Power
    3149
    Reputation
    132432

    Default

    Cou7ld you actually ask the creator of the software?
    I'm out of my mind, but feel free to leave a message...

  • #3
    Senior Member

    Join Date
    Jan 2008
    Location
    A rock in the ocean
    Posts
    752
    Thanks
    99
    Thanked 135 Times in 79 Posts
    Rep Power
    290
    Reputation
    3356

    Default

    Quote Originally Posted by lsemmens View Post
    Cou7ld you actually ask the creator of the software?
    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.

  • #4
    Senior Member urban_s0ulja's Avatar
    Join Date
    Jan 2008
    Location
    South East Asia
    Posts
    4,068
    Thanks
    380
    Thanked 510 Times in 330 Posts
    Rep Power
    378
    Reputation
    2276

    Default

    Is this for the new version of greywolf floating around?

  • The Following User Says Thank You to urban_s0ulja For This Useful Post:

    xapi (30-09-17)

  • #5
    Senior Member
    bob_m_54's Avatar
    Join Date
    Jan 2011
    Posts
    2,093
    Thanks
    1,052
    Thanked 1,151 Times in 689 Posts
    Rep Power
    633
    Reputation
    20178

    Default

    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...

  • The Following 2 Users Say Thank You to bob_m_54 For This Useful Post:

    tristen (30-09-17),xapi (30-09-17)

  • #6
    Senior Member

    Join Date
    Jan 2008
    Location
    A rock in the ocean
    Posts
    752
    Thanks
    99
    Thanked 135 Times in 79 Posts
    Rep Power
    290
    Reputation
    3356

    Default

    Quote Originally Posted by urban_s0ulja View Post
    Is this for the new version of greywolf floating around?
    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.

  • The Following User Says Thank You to mitaux8030 For This Useful Post:

    bob_m_54 (06-10-17)

  • #7
    Premium Member

    Join Date
    Jan 2008
    Posts
    4,311
    Thanks
    5,979
    Thanked 4,171 Times in 1,771 Posts
    Rep Power
    1348
    Reputation
    50392

    Default

    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.

  • #8
    Senior Member

    Join Date
    Jan 2008
    Location
    A rock in the ocean
    Posts
    752
    Thanks
    99
    Thanked 135 Times in 79 Posts
    Rep Power
    290
    Reputation
    3356

    Default

    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?

  • #9
    Junior Member
    Join Date
    Jan 2008
    Location
    Melbourne
    Age
    44
    Posts
    61
    Thanks
    15
    Thanked 11 Times in 8 Posts
    Rep Power
    202
    Reputation
    190

    Default

    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.

  • The Following User Says Thank You to Sektor For This Useful Post:

    mitaux8030 (07-10-17)

  • #10
    Senior Member

    Join Date
    Jan 2008
    Location
    A rock in the ocean
    Posts
    752
    Thanks
    99
    Thanked 135 Times in 79 Posts
    Rep Power
    290
    Reputation
    3356

    Default

    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.

  • #11
    Premium Member
    Skepticist's Avatar
    Join Date
    Apr 2009
    Posts
    1,139
    Thanks
    714
    Thanked 670 Times in 525 Posts
    Rep Power
    474
    Reputation
    12780

    Default

    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.

  • #12
    Member
    Join Date
    Jan 2008
    Posts
    463
    Thanks
    235
    Thanked 183 Times in 114 Posts
    Rep Power
    261
    Reputation
    2421

    Default


  • The Following User Says Thank You to vnboost For This Useful Post:

    Sektor (08-10-17)

  • #13
    Senior Member

    Join Date
    Jan 2008
    Location
    A rock in the ocean
    Posts
    752
    Thanks
    99
    Thanked 135 Times in 79 Posts
    Rep Power
    290
    Reputation
    3356

    Default

    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...

  • #14
    Premium Member
    Skepticist's Avatar
    Join Date
    Apr 2009
    Posts
    1,139
    Thanks
    714
    Thanked 670 Times in 525 Posts
    Rep Power
    474
    Reputation
    12780

    Default

    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.

  • #15
    Senior Member

    Join Date
    Jan 2008
    Location
    A rock in the ocean
    Posts
    752
    Thanks
    99
    Thanked 135 Times in 79 Posts
    Rep Power
    290
    Reputation
    3356

    Default

    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

  • The Following 4 Users Say Thank You to mitaux8030 For This Useful Post:

    bob_m_54 (14-10-17),Sektor (14-10-17),technoweenie (14-10-17),tristen (14-10-17)

  • Bookmarks

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •