Date: Tue, 9 Dec 2008 22:51:29 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Patch: Handle huge (>=4GB) wordlist Robert and all, On Tue, Dec 09, 2008 at 03:16:50PM +0100, Robert Annessi wrote: > Attached is a minor patch to make john handle huge wordlists. I approved this posting with the attached patch because the issue keeps coming up once in a while (quite often in private e-mails to me), however I find this specific patch wrong, and I suggest that it not be used. One problem with it is that "--restore" won't work right for large wordlists (which would be unsupported without the patch). Another problem is that the patch is highly non-portable. A proper patch would be to make JtR use the data type off_t for file offsets, and to compile JtR with proper settings for the given system's C library to enable Large File Support (LFS). Such compiler flags, to be added into CFLAGS, may be obtained with "getconf LFS_CFLAGS" - this command may be run right out of the Makefile. For glibc, the proper addition to CFLAGS would be -D_FILE_OFFSET_BITS=64 ("getconf LFS_CFLAGS" also adds -D_LARGEFILE_SOURCE, but this should not matter for JtR). Unfortunately, these changes would make JtR somewhat less portable and/or more complicated. The off_t data type might not exist on some ancient systems, where it is still possible to compile JtR. (OK, maybe it's time to disregard those. The few people who would compile JtR there can add a "typedef" on their own.) Adding the output of "getconf LFS_CFLAGS" into CFLAGS in the convenient and clear way would introduce a dependency on GNU make. Adding -D_FILE_OFFSET_BITS=64 explicitly might not enable the new functionality on systems other than those based on glibc. Starting to use GNU autoconf and automake is a solution (and there are other reasons to go for it as well), but it's one I don't like very much and have been trying to avoid so far. Yet it is within consideration for future versions of JtR. Finally, LFS is potentially needed for 32-bit builds of JtR only. 64-bit builds (running on 64-bit platforms, of course) support huge files just fine, with no changes needed. That said, I might integrate LFS on 32-bit into JtR at some point. Maybe I'll start with JtR Pro (the portability concerns don't apply for it) and the jumbo patch (optional and known to make JtR less portable for other reasons anyway). Thanks, Alexander Peslyak <solar at openwall.com> GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15 http://www.openwall.com - bringing security into open computing environments -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ