64bit processors and Backtrack 4 programs

[ZeusCracker]

I was wondering if there were any programs on Backtrack 4 that take advantage of 64bit processors. I'm specifically looking for significantly faster password generating tables, since theoretically I could use 3 of my quad core processors to spit out 64 bits (8 characters) of random passwords a millisecond.

I may create my own 64-bit C++ program to do this using 'long long' integers or pointers.

[Virchanza]

When you use a compiler such as "gcc" to compile C code and specifically tell it to compile for a 64-Bit-capable CPU, then the compiler will produce an executable file that will contain machine code that might have a few CPU instructions that only make sense to a 64-Bit CPU.
If you take this executable file and try to run it on a normal 32-Bit CPU, then the 32-Bit CPU will be like "What the hell is that instruction, I've never seen it before?!".

All the stuff on the Backtrack 4 Final CD is compiled to be compatible with a 32-Bit CPU, so it doesn't take advantage of the extra CPU registers and extra instructions that are available on a 64-Bit machine.

If you really want to take advantage of your CPU's 64-Bit capability, then you'll have to recompile some programs and specify to the compiler that the target is 64-Bit. For most programs, the performance increase will be negligible, but for a select few programs there might be a considerable difference.

Regarding writing your own programs in C or C++, well if you want to get the best performance, then here's some pointers I have to offer:
1) Use the types such as uint_fast64_t which are available in stdint.h
2) Use a Big Number library such as GMP which is written to take advantage of different CPU architectures (The GNU MP Bignum Library)
3) Make sure your users set their compiler options right so that they get the best performance (or you can simply just compile the program for them and supply them with an executable file)

Regarding taking advantage of your 4 cores, well this should be taken care of by the programmer. The programmer, when writing his program, should spawn as many threads as there are CPU cores in order to get the best performance possible. You shouldn't need to set compiler options or re-compile programs. Something like:

unsigned const cores = Get_Number_Of_Cores();

for (unsigned i = 0; i != cores; ++i)
{
    Spawn_New_Thread_To_Crack_Password();
}

[orgcandman]

Be advised - you'll be chasing down all sorts of awful bugs where people assumed 32-bits. As an example:

   long ip_addr = 0;

On a 64-bit architecture, will be 8 bytes. If you dump this into an IP packet, you'll get all sorts of garbled packets.

This is one of the primary reasons that I'm guessing BT4 is built exclusively for 32-bit computers.

[Virchanza]

As far as I'm aware, (and I'm open to correction here), the width of the integer types does not change when you tell GCC to compile for a 64-Bit CPU.

EDIT: It turns out I was wrong. With GCC, the "long" type is 64-Bit if you compile for a 64-Bit machine.

The types stay like this:

char - 8
short - 16
int - 32
long - 32 (This becomes 64 when you compile for a 64-Bit machine)
long long - 64

When you use long long in a program compiled for 64-Bit, it genuinely uses 64-Bit CPU registers to play around with the number.

However when you use long long in a program compiled for 32-Bit, it uses two 32-Bit registers side by side, and multiple instructions are required every time you wanna play around with the number (and hence there's a performance hit).

If you're writing a C/C++ program and you want to use exact-width types, then make use of the types defined in stdint.h:

uint16_t
uint32_t
uint64_t

I like to make use of the types:

uint_fast32_t
uint_fast64_t

There's a full explanation of these types on this page: http://www.dinkumware.com/manuals/de...ge=stdint.html
If you want to set your compiler to compile for specific CPU's (e.g. compile for 64-Bit), you can play around with these options: i386 and x86-64 Options - Using the GNU Compiler Collection (GCC)

[orgcandman]

Your understanding on the size of data types doesn't match what gcc defaults to using.

$ cat test-long.c
#include <stdio.h>

int main()
{
    printf("sizeof(long) == %u\n", sizeof(long));

    return 0;
}
$ gcc -o test-long test-long.c -m32
$ ./test-long
sizeof(long) == 4
$ gcc -o test-long test-long.c -m64
test-long.c: In function âmainâ:
test-long.c:5: warning: format â%uâ expects type âunsigned intâ, but argument 2 has type âlong unsigned intâ
$ ./test-long
sizeof(long) == 8
$

This is c99 "standard" (ie: compiling using -std=c99 will not produce anything different). However, I've tested with -ansi, and -std=c89. All produce the same result.

[Virchanza]

My own machine is only 32-Bit-capable so I can't test out the code using "-m64".

Could you please do me a quick favour? Can you change this line of code:

printf("sizeof(long) == %u\n", sizeof(long));

to:

printf(  "sizeof(long) == %u\n", (unsigned)sizeof(long)  );

After you do that, can you please compile it and run it for both m32 and m64 as you did in your previous post?

(The reason I ask is that the behaviour of your original piece of code is undefined because you specify %u to printf but then you give it an argument of type size_t).

[orgcandman]

no need to. size_t is unsigned (according to c99). ssize_t is signed. (BTW, if it weren't this way, a malloc of < 0 would be crazy!)

But if you'd like to verify both:

first, confirmation that size_t is unsigned (without grep'ing the standard):

root@bt:~# cat sizet.c
#include <stdio.h>
#include <string.h>

int main()
{
  size_t     usize;
  signed int ssize;

  memset(&usize, 0xff, sizeof(usize));
  memset(&ssize, 0xff, sizeof(ssize));

  if(usize < 0)
    printf ("size_t < 0\n");

  if(ssize < 0)
    printf ("int < 0\n");

  return 0;
}
root@bt:~# gcc -o sizet sizet.c
root@bt:~# ./sizet
int < 0
root@bt:~#

Second, the re-run:

$ gcc -o test-long test-long.c -m64 -ansi
test-long.c: In function âmainâ:
test-long.c:5: warning: format â%dâ expects type âintâ, but argument 2 has type âlong unsigned intâ
$ ./test-long
sizeof(long) == 8

If you'll notice, the warning message has changed slightly. I expect that the first example on my Ubuntu x64 machine would produce errors regarding comparisons between unsigned and < 0 (always being false). No matter, the real issue that the warning reveals is that we should use %u for 32-bit machine, and %lu for 64 bit machine. (the return width of sizeof varies on architecture type)

EDIT: we're veering way off-topic, here. We should probably take the rest of this to PM (or, mods willing, start a different thread).

[Virchanza]

no need to. size_t is unsigned (according to c99)

You're correct that size_t is an unsigned integer type, but it isn't necessarily a typedef for "unsigned int" (it could be something bigger like unsigned long int). If printf receives an integer argument of the wrong size then the behaviour is undefined.

You're right about long long being 64-Bit on your machine though, I wasn't expecting that.

Of course it would be wonderful if everyone would just use the types defined in stdint.h instead of depending upon implementation-defined stuff that can differ from machine to machine (and even from OS to OS).

P.S. The proper way to use printf to print a size_t value is to use %zu (it's fully-portable and you don't have to worry about 32-Bit versus 64-Bit).

I don't see any need to start a new thread, we're still talking about 32-Bit versus 64-Bit issues.

Let the games begin ;-D