Compiling Crack on OSF/1

Compiling Crack on OSF/1

Post by Derek Douvil » Fri, 19 Apr 1996 04:00:00



        I've been running Crack 4.1 on our Sparc 20 for the past two days.
Ugh!  (I guess I should have put it into Network mode).  Anyhow,  it
was suggested that we run it from our 64 bit OSF/1 box,  which is a
DEC ALPHA chip processor.  This system is also not as heavily used
as the Sparc 20,  so I should get better performance.

        The problem I've run into is this statement:

  Ll ^= (S0L)[ *dp STEP];
---------------------^

        This error occurs when compiling crack-fcrypt.c. STEP is supposed
to be #defined to either ++ or --,  depending on whether BIG_ENDIAN
is defined,  or SMALL_ENDIAN is defined.  Are these system definitions?
The code within the conditional define will probably make a performance
difference depending on which one I use,  if I'm to use either.

        Anyone have a solution?  Once our Sparc 20 has cached the bad passwords,
I'd prefer to run it off the faster processor for the next run.

P.S.  Don't ask me to send you a copy of my password file so you can
test it   ;-)

--
Derek Douville (Technical Analyst)               COGNOS INCORPORATED

Phone:    (613) 738-1338 x3033                  Ottawa, Ont. K1G 3Z4
Fax:      (613) 738-3518                  #include <stddisclaimer.h>
UNIX TECHNICAL SUPPORT (Internal)              SYSTEM ADMINISTRATION

 
 
 

Compiling Crack on OSF/1

Post by Paul Engli » Sat, 20 Apr 1996 04:00:00


:       I've been running Crack 4.1 on our Sparc 20 for the past two days.
: Ugh!  (I guess I should have put it into Network mode).  Anyhow,  it
: was suggested that we run it from our 64 bit OSF/1 box,  which is a
: DEC ALPHA chip processor.  This system is also not as heavily used
: as the Sparc 20,  so I should get better performance.

:       The problem I've run into is this statement:

:   Ll ^= (S0L)[ *dp STEP];
: ---------------------^

:       This error occurs when compiling crack-fcrypt.c. STEP is supposed
: to be #defined to either ++ or --,  depending on whether BIG_ENDIAN
: is defined,  or SMALL_ENDIAN is defined.  Are these system definitions?
: The code within the conditional define will probably make a performance
: difference depending on which one I use,  if I'm to use either.

:       Anyone have a solution?  Once our Sparc 20 has cached the bad passwords,
: I'd prefer to run it off the faster processor for the next run.

If you'll accept a somewhat vague recall from Assembly class last year, this
might actually get you somewhere. The Endian refers to the memory model you
are using for the program. In that case, I think it's pretty safe to say
that on an Alpha, you would be using BIG_ENDIAN, because SMALL_ENDIAN is one
of those really ancient PC-type things with only a couple of megs of memory.
So you could probably #define BIG_ENDIAN, or remove the little ENDIAN option.
At any rate, with only 2 cases.. go for the old trial and error method..

 
 
 

Compiling Crack on OSF/1

Post by T.E.Dick » Sun, 21 Apr 1996 04:00:00


:       I've been running Crack 4.1 on our Sparc 20 for the past two days.
: Ugh!  (I guess I should have put it into Network mode).  Anyhow,  it
: was suggested that we run it from our 64 bit OSF/1 box,  which is a
: DEC ALPHA chip processor.  This system is also not as heavily used
there's a short program 'bytesex.c' that you're supposed to have run during
the build -- it may have run & failed since crack was only loosely tested
for long-long (60-bits for one case) machines.

(I did run 'bytesex' on an alpha last year, and it gave the correct result)

--
Thomas E.*ey

 
 
 

Compiling Crack on OSF/1

Post by Alec Muffe » Tue, 23 Apr 1996 04:00:00


 >
 >   I've been running Crack 4.1 on our Sparc 20 for the past two days.
 >Ugh!  (I guess I should have put it into Network mode).  Anyhow,  it
 >was suggested that we run it from our 64 bit OSF/1 box,  which is a
 >DEC ALPHA chip processor.  This system is also not as heavily used
 >as the Sparc 20,  so I should get better performance.
 >
 >   The problem I've run into is this statement:
 >
 >  Ll ^= (S0L)[ *dp STEP];
 >---------------------^

Dump fcrypt() and go get a copy of UFC.

Host: ftp.uu.net
Last Updated Fri Apr  5  3:52:32 GB 1996

    Location: usenet/comp.sources.misc/volume28
      DIRECTORY rwxr-xr-x    512       Jul 29 1992    ufc-crypt

- or from prettymuch anywhere else.

Also, change all instances of:

        ctime(blah)

into:

        (char *) ctime(blah)

- alec
--
#!/usr/local/bin/perl -- -pwcracker-in-2-lines-of-perl-plus-disclaimer

{printf "u=%s p=%s\n",$u{$c},$_ if(crypt($_,$c) eq $c);}} # Use: pwc dict ...

 
 
 

Compiling Crack on OSF/1

Post by Steffen Klu » Tue, 23 Apr 1996 04:00:00




> I've been running Crack 4.1 on our Sparc 20 for the past two days.
>Ugh!  (I guess I should have put it into Network mode).  Anyhow,  it
>was suggested that we run it from our 64 bit OSF/1 box,  which is a
>DEC ALPHA chip processor.  This system is also not as heavily used
>as the Sparc 20,  so I should get better performance.

> The problem I've run into is this statement:

>  Ll ^= (S0L)[ *dp STEP];
>---------------------^

> This error occurs when compiling crack-fcrypt.c. STEP is supposed
>to be #defined to either ++ or --,  depending on whether BIG_ENDIAN
>is defined,  or SMALL_ENDIAN is defined.  Are these system definitions?
>The code within the conditional define will probably make a performance
>difference depending on which one I use,  if I'm to use either.

> Anyone have a solution?  Once our Sparc 20 has cached the bad passwords,
>I'd prefer to run it off the faster processor for the next run.

There is a patch to crack 4.1 available for DEC Alpha machines. It
solves the 64bit and endian problems. I can send it via email
if you like.

Cheers
Steffen.

--
Steffen Kluge
ave GmbH Aachen

--

 
 
 

Compiling Crack on OSF/1

Post by Derek Douvil » Thu, 25 Apr 1996 04:00:00



diff to use with `patch`,  which I successfully merged.  The code
compiled right away (once I removed the ^M characters from the patch
file),  and Crack is now running happily on two 64-bit Alpha boxes
in -network mode.

Thanks,  Jason.

--Derek Douville


:  >
:  > I've been running Crack 4.1 on our Sparc 20 for the past two days.
:  >Ugh!  (I guess I should have put it into Network mode).  Anyhow,  it
:  >was suggested that we run it from our 64 bit OSF/1 box,  which is a
:  >DEC ALPHA chip processor.  This system is also not as heavily used
:  >as the Sparc 20,  so I should get better performance.
:  >
:  > The problem I've run into is this statement:
:  >
:  >  Ll ^= (S0L)[ *dp STEP];
:  >---------------------^

: Dump fcrypt() and go get a copy of UFC.

: Host: ftp.uu.net
: Last Updated Fri Apr  5  3:52:32 GB 1996
:  
:     Location: usenet/comp.sources.misc/volume28
:       DIRECTORY rwxr-xr-x    512       Jul 29 1992    ufc-crypt
:  
: - or from prettymuch anywhere else.

: Also, change all instances of:

:       ctime(blah)

: into:

:       (char *) ctime(blah)

: - alec
: --
: #!/usr/local/bin/perl -- -pwcracker-in-2-lines-of-perl-plus-disclaimer

: {printf "u=%s p=%s\n",$u{$c},$_ if(crypt($_,$c) eq $c);}} # Use: pwc dict ...

--
Derek Douville (Technical Analyst)               COGNOS INCORPORATED

Phone:    (613) 738-1338 x3033                  Ottawa, Ont. K1G 3Z4
Fax:      (613) 738-3518                  #include <stddisclaimer.h>
UNIX TECHNICAL SUPPORT (Internal)              SYSTEM ADMINISTRATION