Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 17 Mar 2012 02:41:04 +0400
From: Solar Designer <>
Subject: Re: Compile john in Windows 64 bits

On Tue, Mar 13, 2012 at 07:44:31AM -0700, Alain Espinosa wrote:
> Compilation finishes fine and when execute:
> $ ../run/john.exe --test
> Benchmarking: Traditional DES [128/128 BS SSE2-16]...
> john crashed. A look at disassembly(image attached) show access in SSE
> code to a memory unaligned at 16 byte. Other formats works (testing in
> a Celeron 430 1.8GHz CPU, Win7 SP1 64 bits):

I did not realize this needed a comment from me until magnum mentioned
that apparently it did.

Unaligned accesses were a common problem on Windows - with Cygwin as
well - although it's been a while since I last heard of them (maybe
something was fixed in Cygwin lately).

We have ALIGN_FIX in some .S files for that, which may have to be
defined on some Windows builds.  Apparently, a similar thing occurs with
Mingw-x64.  x86-64.S lacks the ALIGN_FIX thing, so this needs to be
added and enabled (set to 8) when needed (that is, when a given build
crashes on self-test).

The screenshot appears to correspond to LM hash code, even though the
above says Traditional DES.  On the screenshot, we see that k is in rdx,
*k is in rcx - and the latter turns out to be misaligned.  This suggests
that the entire DES_bs_all is misaligned.

When not using the x86-64.S code yet building without OpenMP, DES_bs_all
is declared in DES_bs.c like this:

DES_bs_combined CC_CACHE_ALIGN DES_bs_all;

Whether this actually guarantees sufficient alignment (not only inside
the section, but also for the section itself) or not is once again

With OpenMP-enabled builds, DES_bs_all is aligned by DES_bs_init():

		DES_bs_all_p = mem_alloc_tiny(
		    ++n * DES_bs_all_size, MEM_ALIGN_PAGE);

so the problem should not occur no matter what platform.

...Oh, it just occurred to me that the screenshot also shows that
DES_bs_all.B is correctly aligned.  Now this is puzzling - why would
.B be aligned and .K not aligned?  Or does *k somehow not point to a K[]
element?  Things to check: addresses of DES_bs_all_K and DES_bs_all_B in
x86-64.o, whether rcx is within DES_bs_all_K or not, if not then why
not: initialization code in DES_bs_init(), sizeof(DES_bs_vector).

My current best guess: maybe the struct fields in x86-64.S do not match
those in DES_bs.h due to different/incorrect types used in C.  I'd start
by checking sizeof(DES_bs_vector).


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.