Home > Programming > Simple Password Cracking

Simple Password Cracking

A very basic password cracking

Here is a very simple algorithm which matches the character of the password entered to the user to that stored by a variable in the program(which frequently happens). It is very easily implemented.

Its core is actually only one line of code that, in the C language, could be written as follows: if (strcmp (password entered, reference password)) {/* Password is incorrect */} else {/* Password is OK*/}.

Here is an example code which implements it and we’ll examine it.

Listing 1: The Simplest System of Authentication


// Matching the password character by character

#include <stdio.h>
#include <string.h>

#define PASSWORD_SIZE 100
#define PASSWORD  "myGOODpassword\n"

int main () {

	char buff [PASSWORD_SIZE];

	for (;;) {

		printf ("Enter password:");
		fgets (&buff [0], PASSWORD_SIZE,stdin);

		if (strcmp (&buff [0], PASSWORD))
			printf ("Wrong password\n");
		else
			break;

		if (++count>3) return -1; // terminating the program if 3 attempts have been used
	}

// Once we're here, the user has entered the right password.
	printf ("Password OK\n");
}
}

The password isn’t encrypted in any way, it can be found by simply looking at the binary code. Looking at all the text strings, especially those that look like a password, we’ll quickly find the required key and easily “open” the program!

The area in which we need to look can be narrowed down using the fact that, in the overwhelming majority of cases, compilers put initialized variables in the data segment (in PE files, in the .data section).

So, let’s assume it’s in the data section. Now, we just need a handy instrument to view the binary file. You can press in your favorite shell (FAR, DOS Navigator) and, by pressing the key admire the digits scrolling down until it bores you. You can also use a hex-editor (QVIEW, HIEW, etc.) but for presentation purposes, I’ll use the DUMPBIN utility supplied with Microsoft Visual Studio.

Let’s print out the data section (the key is /SECTION:.data) as raw data (the key is /RAWDATA:BYTES), having specified the “>” character for redirecting the output to a file. (The response occupies a lot of space, and only its “tail” would find room on the screen.)

> dumpbin /RAWDATA:BYTES /SECTION:.data simple.exe >filenameRAW DATA #3
00406000: 00 00 00 00 00 00 00 00 00 00 00 00 3B 11 40 00 ............;.@.
00406010: 64 40 40 00 00 00 00 00 00 00 00 00 70 11 40 00 d@@.........p.@.
00406020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00406030: 45 6E 74 65 72 20 70 61 73 73 77 6F 72 64 3A 00 Enter password:.
00406040: 6D 79 47 4F 4F 44 70 61 73 73 77 6F 72 64 0A 00 myGOODpassword..
00406050: 57 72 6F 6E 67 20 70 61 73 73 77 6F 72 64 0A 00 Wrong password..
00406060: 50 61 73 73 77 6F 72 64 20 4F 4B 0A 00 00 00 00 Password OK.....
00406070: 40 6E 40 00 00 00 00 00 40 6E 40 00 01 01 00 00 @n@.....@n@.....

Look! In the middle of the other stuff, there’s a string that is similar to a reference password (it’s printed in bold). Shall we try it? It seems likely we need not even bother: Judging from the source code, it really is the password. The compiler has selected too prominent of a place in which to store it—it wouldn’t be such a bad idea to hide the reference password better.

One of the ways to do this is to manually place the reference password value in a section that we choose ourselves. The ability to define the location isn’t standard, and, consequently, each compiler (strictly speaking, not actually the compiler, but the linker—but that isn’t really important) is free to implement it in any way (or not implement it at all). In Microsoft Visual C++, a special pragma — data_seg — is used for this, and indicates in which section the initialized variables following it should be placed. By default, unassigned variables are placed in the .bbs section, and are controlled by the bss_seg pragma.

Let’s add the following lines to Listing 1, and see how they run.


int count=0;
// From now on, all the initialized variables will be
// located in the .kpnc section.
#pragma data_seg (."kpnc")
// Note that the period before the name
// isn't mandatory, just customary.
char passwd[ ]=PASSWORD;
#pragma data_seg ()

// Now all the initialized variables will again
// be located in the section by default (i.e., ."data").
char buff [PASSWORD_SIZE]=" ";
...
if (strcmp(&buff[0] , &passwd[0]))

> dumpbin /RAWDATA:BYTES /SECTION: .data simple2.exe >filenameRAW DATA #3
00406000: 00 00 00 00 00 00 00 00 00 00 00 00 45 11 40 00 ............E.@.
00406010: 04 41 40 00 00 00 00 00 00 00 00 00 40 12 40 00 .A@.........@.@.
00406020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00406030: 45 6E 74 65 72 20 70 61 73 73 77 6F 72 64 3A 00 Enter password:.
00406040: 57 72 6F 6E 67 20 70 61 73 73 77 6F 72 64 0A 00 Wrong password..
00406050: 50 61 73 73 77 6F 72 64 20 4F 4B 0A 00 00 00 00 Password OK.....
00406060: 20 6E 40 00 00 00 00 00 20 6E 40 00 01 01 00 00 n@..... n@......
00406070: 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 ................

Aha! Now, there’s no password in the data section and hackers’ attack has been retarded. But don’t jump to conclusions. Simply display the list of sections in the file:

> dumpbin simple2.exeSummary
2000 .data
1000 .kpnc
1000 .rdata
4000 .texts

The nonstandard section .kpnc attracts our attention right away. Well, shall we check to see what’s in it?

dumpbin /SECTION:.kpnc /RAWDATA simple2.exeRAW DATA #4
00408000: 6D 79 47 4F 4F 44 70 61 73 73 77 6F 72 64 0A 00 myGOODpassword..

There’s the password! And we thought we hid it. It’s certainly possible to put confidential data into a section of noninitialized data (.bss), the service RTL section (.rdata), or even into the code section (.text) — not everyone will look there for the password, and such allocation won’t disturb the functioning of the program. But you shouldn’t forget about the possibility of an automated search for text strings in a binary file. Wherever the reference password may be, such a filter will easily find it. (The only problem is determining which text string holds the required key; most likely, a dozen or so possible “candidates” will need to be tried.)

If the password is written in Unicode, the search is somewhat more complicated, since not all such utilities support this encoding. But it’d be rather native to hope that this obstacle will stop a hacker for long.

Obtained from Hacker Disassembling Uncovered.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: