Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 3 Jun 2011 07:32:53 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: John 1.7.7-jumbo-5

On Thu, Jun 02, 2011 at 10:18:36PM -0500, JimF wrote:
> The salted_sha format came along for the ride with simon's intrisic patch. 
> It was old code he had (explained in a prior email), that he had created. 
> It is actaully nsldaps, but works for sse2/sse2i builds.  But yes, these 
> should be reduced to 1 (or 2) formats.

Yes, that's what I thought.

> >code in JtR required such alignment of binary()'s output buffer.  Was I
> >wrong, or has something changed, introducing this requirement?
> 
> The assumption comes from how the get_bin are implemented. Many typecast to 
> unsigned, then and off the lower bits.  If the return from binary is not 
> aligned on these systems, they core.  It turned up on sparc64 (and some on 
> sparc 32).

You might be confusing binary() and binary_hash[]().  The latter are
performance-critical, and they definitely assume alignment.  The former
is not performance-critical (it is only used at loading and by
self-tests), and its callers were not supposed to assume alignment.

> >...Oh, it just occurred to me that fmt_self_test() directly passes
> >binary()'s
> 
> Now, it 'may' be only in testing code. I had not investigated further, as 
> the code would not get past this.   So, in the cracking code, you do not 
> pass binary's return value?  If for normal cracking, you realloc 
> (alingned), and then present that to the get_bin() calls, then all we may 
> need to fix is formats.c, and revert back the code.

The cracking code uses pointers already in the "database", which were
filled by the loader using:

		current_pw->binary = mem_alloc_copy(
			format->params.binary_size, MEM_ALIGN_WORD, binary);

> All I can say, is there were many formats where I had problems in the 
> sparc64 system.  At first, we could not even 'start' john, it would die in 
> the format loading of md5_gen_fmt.

Sure.

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ