-1

I'm a network Penetration Tester and I'm trying to learn how to crack binaries. As an exercise, I've spent two days trying to crack a Linux binary that was supposedly designed to be cracked. Searching on the web and trying what I know on Linux has thus far been fruitless. I've only been able to find the word 'PAsswOrd' using the Linux utility 'strings'. When I submit it, the binary outputs 'you have to try harder'. Running the executable outputs 'I'm not your property'.

I realize I need to know what tools exist beyond basic Linux utilities to unravel the executable. I'm not asking for any part of the solution or a set of instructions. Just some sort of starting point would be useful, since I do not see any SO questions or online training that provides this.

Douglas Daseeco
  • 614
  • 3
  • 17
user7451333
  • 32
  • 3
  • 2
    Is this the same question that was at http://security.stackexchange.com/questions/151714/binary-file-password-is-correct-but-try-harder-file-added ? It's still off topic... – Matthew Feb 21 '17 at 13:53
  • 4
    You've not shown any steps that you've taken, meaning that this essentially comes down to "how do I solve this challenge". That's far too broad for an SE answer, as well as being totally useless to anyone else. There are entire books on reverse engineering, and people who have spent years developing the skills. Think of it being like going onto a group comprised of musicians and saying "I'm struggling writing a song - could you do it for me?" – Matthew Feb 21 '17 at 14:12
  • A first step would be to disassemble the binary to understand what it does. – Hacktiker Feb 21 '17 at 14:26
  • mote : i'm a penetration tester **ONLY**, and i have no experience in reversing . – user7451333 Feb 21 '17 at 14:31
  • To add on to @DouglasDaseeco's answer, I would say you need to start here: Purchase the book "[Practical Malware Analysis](http://www.nostarch.com/malware)" from No Starch Press, and start learning how to take apart malware. Google absolutely won't ever give you the answers for discovering what real-world malware does. That's a skill you must learn for yourself. – John Deters Feb 21 '17 at 18:58

1 Answers1

0

What you are doing is called reverse engineering an executable. It is not unusual for a person who is hard coding a password into source code (a horrible security strategy) to make an amateur attempt to keep it from appearing in the static data intact. However, the password PAssw0rd may not be at all related to the actual one. The various program responses are obviously intentional, so PAssw0rd may be a deliberate red herring.

Several tools are common in reverse engineering efforts.

  1. The command "file" which takes the file path as the first parameter so you can determine (in most cases) what type of executable you have.
  2. Disassemblers which show EXACTLY what the executable does but is difficult to read for those that don't write assembly code on that specific architecture or have experience with disassembly.
  3. Decompilers like Boomerang, Hex-rays, and Snowman can provide some greater readability but they do not recover the actual variable names or syntax of the original program and they are not 100% reliable, especially in cases where the engineers that created the executable tested with these packages and tried to obfuscate the security further.
  4. Data flow diagrams or tables. I know of no free tool to do this automatically, but a Python or Bash script over the top of a text parser of the assembly output (which can be written in sed or Perl) can be helpful.
  5. Pencil and paper, believe it or not, for jotting flows and ideas

A common approach is to hunt for two things in the decompiled or disassembled code.

  1. Cryptographic functions, such as a hash or cipher algorithm
  2. The user prompt for the password and the subsequent read of the user entry

These are the two endpoints in the data flow. You will want to back-trace from the place where the password enters the cryptography algorithms and forward-trace the user entry of the password, hoping to find where the two ends meet.

Once you trace the path between user entry and authentication components, you will be able to see the mechanism in between. If the security was done correctly, it will be a properly created hash value and your attempt will end poorly, but I suspect, this being an exercise, favorable results will be possible.

Douglas Daseeco
  • 614
  • 3
  • 17
  • 6
    it's nice of you to offer to try to help this guy, but the purpose of a challenge program is to teach; and he has shown no effort in actually learning. Instead he says "I have searched everywhere for a solution", explicit stating his intent to cheat the challenge instead of learning. That's the real problem with this question. – John Deters Feb 21 '17 at 18:51