Results 1 to 8 of 8

Thread: 64bit processors and Backtrack 4 programs

  1. #1
    Just burned his ISO
    Join Date
    Sep 2010
    Location
    Netherworlds
    Posts
    2

    Default 64bit processors and Backtrack 4 programs

    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.

  2. #2
    Very good friend of the forum Virchanza's Avatar
    Join Date
    Jan 2010
    Posts
    863

    Default Re: 64bit processors and Backtrack 4 programs

    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:

    Code:
    unsigned const cores = Get_Number_Of_Cores();
    
    for (unsigned i = 0; i != cores; ++i)
    {
        Spawn_New_Thread_To_Crack_Password();
    }

  3. #3
    Member
    Join Date
    Jan 2010
    Posts
    70

    Default Re: 64bit processors and Backtrack 4 programs

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

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

  4. #4
    Very good friend of the forum Virchanza's Avatar
    Join Date
    Jan 2010
    Posts
    863

    Default Re: 64bit processors and Backtrack 4 programs

    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)
    Last edited by Virchanza; 09-07-2010 at 11:07 AM.

  5. #5
    Member
    Join Date
    Jan 2010
    Posts
    70

    Default Re: 64bit processors and Backtrack 4 programs

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

    Code:
    $ 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.

  6. #6
    Very good friend of the forum Virchanza's Avatar
    Join Date
    Jan 2010
    Posts
    863

    Default Re: 64bit processors and Backtrack 4 programs

    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:

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

    Code:
    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).

  7. #7
    Member
    Join Date
    Jan 2010
    Posts
    70

    Default Re: 64bit processors and Backtrack 4 programs

    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):
    Code:
    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:
    Code:
    $ 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).
    Last edited by orgcandman; 09-07-2010 at 05:23 AM.

  8. #8
    Very good friend of the forum Virchanza's Avatar
    Join Date
    Jan 2010
    Posts
    863

    Default Re: 64bit processors and Backtrack 4 programs

    Quote Originally Posted by orgcandman View Post
    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
    Last edited by Virchanza; 09-07-2010 at 06:34 AM.

Similar Threads

  1. Replies: 1
    Last Post: 01-22-2010, 12:45 PM
  2. Backtrack 4 startup programs.
    By imported_silvester in forum OLD BackTrack 4 (pre) Final
    Replies: 3
    Last Post: 11-17-2009, 02:10 PM
  3. 64bit
    By RageLtMan in forum OLD BackTrack 4 (pre) Final
    Replies: 6
    Last Post: 10-01-2009, 07:52 PM
  4. BT4 on ARM processors
    By ossumguywil in forum OLD BT4 Feature Requests
    Replies: 4
    Last Post: 06-16-2009, 11:10 AM
  5. I installed Backtrack 3 on eeepc. How I remove programs?
    By ChevronX in forum OLD Newbie Area
    Replies: 3
    Last Post: 04-07-2008, 05:23 AM

Posting Permissions

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