Printable View
I know this may be a "no brainer" for most of you, but all I want is some instructions to open up my mind a bit on hacking. Yes I'm new to this :)
Code:include <string>
#include <iostream>
using namespace std;
int main ()
{
string password;
while ( 1 )
{
cout << "Please enter your password: ";
cin >> password;
if ( password == "1234" )
{
break;
}
}
cout << "Welcome, you got the password right";
}
Before becoming a hacker try to write main this way
Code:int main(void)
{
....
return 0;//successfully terminated program
}
sorry about that.Code:#include <string>
#include <iostream>
using namespace std;
int main ()
{
string password;
while ( 1 )
{
cout << "Please enter your password: ";
cin >> password;
if ( password == "1234" )
{
break;
}
}
cout << "Welcome, you got the password right";
return 0;
}
Strictly not needed.
int main() and int main(void) are the same in C++. In C however they have different meansings.
return 0 not needed by the standard. An implicit return 0 is added at the end of main if you exit main without return statement.
Now to the original question. We are not fond of aiding in cracking so you will most likely not find information here on this subject.
If all you had was the executable, it's easy to "hack" with GDB:
Then to find the password:Code:(gdb) disassemble main
Dump of assembler code for function main:
/* ... */
0x0000000100000b6e <main+57>: lea 0x208(%rip),%rsi # 0x100000d7d
0x0000000100000b75 <main+64>: callq 0x100000cba <dyld_stub__ZSteqIcSt11char_traitsIcESaIcEEbRKSbIT_T0_T1_EPKS3_>
0x0000000100000b7a <main+69>: test %al,%al
0x0000000100000b7c <main+71>: jne 0x100000b80 <main+75>
/* ... */
End of assembler dump.
(gdb)
Although, we're not here to help you do malicious activity, and I'm only providing this solution because its use in practical programs would be next to impossible.Code:(gdb) x/s 0x100000d7d
0x100000d7d: "1234"
Well by default the compiler will do so,but many things are done by default,but i think is good practice to clearly state what we want to do,and not letting someone else who read our code to 'trying' to remember what's done by default.For exampleQuote:
Originally Posted by Shakti
This will output 0,because by default x gets the value.However in a large program it would be very helpful if we wrote int x=0 (in my opinion) :)Code:#include <iostream>
using namespace std;
int main(void){
int x;
cout<<x<<endl;
return 0;
}
-off topic post ends :p
Not true. x is uninitialised. It is not initialised by default to a value of zero.Quote:
Originally Posted by std10093
"int main()" and "int main(void)" are equivalent in C++. They are also equivalent in C within a function definition (i.e. implementation). So your advocacy of adding the void keyword, in this case, is pointless.
Just run it and got a 0 at the output.Quote:
Originally Posted by grumpy
undefined behavior. the standard does not define what uninitialized variables get set to, except in the case of static objects.Quote:
Originally Posted by std10093
Yes, occasionally variables will be zero. The value of the variable just depends on what was in memory before they were created, as declaring a variable doesn't change any memory.Quote:
Originally Posted by std10093
And this is really irrelevant to the topic.
memcpy, I hope it's not a bother, but can you break down the code that you wrote? you don't have to go into to much detail.
He did not write any code.assembly is what your code is translated into before some other stages in order to be runned.There he executed the proram.These are addresses 0x0000000100000b6e.The 0x states that they are in hex. The jne for example is a command(like you use an if-else statement,a for loop etc.).
so all he did was disassemble the main function in GBD. thought it was written, feel like an idiot lol.
For those who can't read the disgusting, weird and unreadable AT&T syntax, here is the clean Intel version:
And what lies at esp+0Ch, pray tell? Why, it's the string "1234", according to a memory viewer.Code:cout << "Please enter your password: ";
00BE1220 mov eax,dword ptr [__imp_std::cout (0BE3088h)]
00BE1225 push offset string "Please enter your password: " (0BE31ACh)
00BE122A push eax
00BE122B call std::operator<<<std::char_traits<char> > (0BE18C0h)
cin >> password;
00BE1230 mov ecx,dword ptr [__imp_std::cin (0BE308Ch)]
00BE1236 push ecx
00BE1237 lea eax,[esp+18h]
00BE123B call std::operator>><char,std::char_traits<char>,std::allocator<char> > (0BE1B00h)
00BE1240 add esp,0Ch
if ( password == "1234" )
00BE1243 lea esi,[esp+0Ch]
00BE1247 call std::operator==<char,std::char_traits<char>,std::allocator<char> > (0BE1B20h)
00BE124C test al,al
00BE124E je main+50h (0BE1220h)
Want to make it secure? Then encrypt the password "1234", then encrypt whatever the user inputs and then compare them.
This foils this approach.
Shouldn't this, ideally, be 'hash' instead of 'encrypt' ?Quote:
Originally Posted by Elysia
I was thinking of a one-way encryption, but apparently that is called hashing (hashing also produces fixed-length output making it even harder to reverse), so I believe you are correct.Quote:
Originally Posted by manasij7479
Of course, even if you hashed the password (which is what most real programs do, by the way), that's not the end of the story. If someone had access to the actual executable, they could just modify the code. Figure out where the check is being performed, and replace that assembly with (e.g.) a whole bunch of 0x90's (which is the machine code for a NO-OP). They could just eliminate the branch entirely. Or make it an unconditional branch. Or whatever.
So then you might have to perform a checksum on the executable to ensure that the code hasn't been modified. But then you have to check that checksum somewhere else, which is itself vulnerable. And so on. You can see why digital protection mechanisms are difficult to do well.
By the way, I have actually legitimately used the insert-noops technique before. I had a binary-only program that was supposed to run as a non-root user, but it was a virtual machine and root was the only user. It exited and refused to run. So I ran it in gdb until it exited, found the branch, and squelched it with noops. And I didn't have to create new user accounts just to run the silly program. (It was a version control system, one of the ones that used to be popular before sensible systems like git came into being.) Yes, creating a new user might have been easier, but I would have had to do it every time I rebooted....
Finally: there's a program called "strings" (at least on UNIXes with GCC) which will go through the data section of your executable and look for anything that looks like a string. Here's the output on a hello world program:
As you can see, it doesn't take much effort to just dump all the strings and get an idea of what's going on. Notice the "Hello, World!"? So even if you manage to hide how the code is accessing the data, you might still have to hide the data itself. The nice thing about this technique is that you don't need any gdb skills at all, just type "strings". :)Code:$ strings hello
/lib64/ld-linux-x86-64.so.2
__gmon_start__
libc.so.6
puts
__libc_start_main
GLIBC_2.2.5
fff.
fffff.
l$ L
t$(L
|$0H
Hello, World!
Just to clarify: it has been mentioned already that this board doesn't support cracking, and we won't post about that. But I think it's important to understand how security *can* be defeated, I mean the types of actions that are technically feasible. Especially if you want to write software that does things like prompting for passwords. If you don't understand how security can be broken there's no way to write secure programs.
Also it's kind of fun to poke around and see how executables and assembly and debuggers work. It leads to a better understanding of how computers really tick, and that's all to the good. If you want to see true magic, look up nm and ldd and objdump. :) Cheers.
I'll mention that while the world is complex, and cracking programs is easy, there are ways to get around this.
To ensure no one modifies your executable, we use a digital signature. It's a proven technology used in many places on the web today, for example in encrypted SSL connections. Not going to explain how it works (google is your friend!).
As for how to prevent in-memory executable modification, typically the alternatives in the real world are either:
- No allowing writing to memory of another executable where its code resides (can be overridden, but typically requires admin privileges to do so).
- DEP prevents programs from writing some code into memory and executing that (DEP can be turned off, but doing so typically requires admin privileges).
- Sandboxing - essentially running all programs in a little virtual machine so whatever they do cannot affect other programs.