Date: Thu, 14 Feb 2013 09:10:44 +0100 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: mschapv2-bitsliced conversion This did not help the OSX assembler: x86-64.S:99:0: warning: "P" redefined [enabled by default] x86-64.S:45:0: note: this is the location of the previous definition x86-64.S:67:Unknown pseudo-op: .extern x86-64.S:67:Rest of line ignored. 1st junk character valued 95 (_). x86-64.S:1368:32-bit absolute addressing is not supported for x86-64 x86-64.S:1368:cannot do signed 4 byte relocation x86-64.S:1370:32-bit absolute addressing is not supported for x86-64 x86-64.S:1370:cannot do signed 4 byte relocation This uses the same arch.h as Linux, but -DUNDERSCORES, -DBSD and -DALIGN_LOG. magnum On 14 Feb, 2013, at 8:50 , deepika dutta <deepikadutta_19@...oo.com> wrote: > I am attaching a new patch handling the problem of multiple definition of P. I hope it works on all platforms. > > Cheers, > Deepika > From: deepika dutta <deepikadutta_19@...oo.com> > To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com> > Sent: Wednesday, February 13, 2013 1:11 PM > Subject: Re: [john-dev] mschapv2-bitsliced conversion > > I think I can correct the warning of multiple definition of P. Though this warning didn't occur in linux, I feel that P has been defined in multiple locations and need to be externed in the assembly file. I will look into this and give a new patch for your testing. I don't know why the other issues are coming, maybe someone can resolve them. > > Cheers, > Deepika > From: magnum <john.magnum@...hmail.com> > To: john-dev@...ts.openwall.com > Sent: Wednesday, February 13, 2013 5:37 AM > Subject: Re: [john-dev] mschapv2-bitsliced conversion > > Deepika's work can be found in branch "mschapv2-bs" on GitHub, with patch history preserved. It is still based on 1.7.9-jumbo-5. It seems to work just fine on Linux (64-bit works fine on Bull, 32-bit cross compile builds fine too but we have no 32-bit OpenSSL to link against). > > On 64-bit OSX I get this though: > > x86-64.S:102:0: warning: "P" redefined [enabled by default] > x86-64.S:45:0: note: this is the location of the previous definition > x86-64.S:1371:32-bit absolute addressing is not supported for x86-64 > x86-64.S:1371:cannot do signed 4 byte relocation > x86-64.S:1373:32-bit absolute addressing is not supported for x86-64 > x86-64.S:1373:cannot do signed 4 byte relocation > x86-64.S:1375:32-bit absolute addressing is not supported for x86-64 > x86-64.S:1375:cannot do signed 4 byte relocation > x86-64.S:1377:32-bit absolute addressing is not supported for x86-64 > x86-64.S:1377:cannot do signed 4 byte relocation > x86-64.S:1379:32-bit absolute addressing is not supported for x86-64 > x86-64.S:1379:cannot do signed 4 byte relocation > ... > make: *** [x86-64.o] Error 1 > make: *** Waiting for unfinished jobs.... > make: *** [macosx-x86-64] Error 2 > > And on 32-bit: > > x86-sse.S:118:1: warning: "P" redefined > x86-sse.S:61:1: warning: this is the location of the previous definition > Undefined symbols for architecture i386: > "P", referenced from: > _DES_bs_crypt_plain in x86-sse.o > ld: symbol(s) not found for architecture i386 > collect2: ld returned 1 exit status > make: *** [../run/john] Error 1 > make: *** [macosx-x86-sse2] Error 2 > > > These are hopefully trivial problems. If we get them solved, I'll see if I can add this as a separate format for a starter, eg. "mschapv2-bs" and merge it to current bleeding tree. > > magnum > > > On 7 Feb, 2013, at 20:50 , magnum <john.magnum@...hmail.com> wrote: > > > Thanks, I'll have a look at your patch within a week. > > > > magnum > > > > > > On 7 Feb, 2013, at 20:21 , deepika dutta <deepikadutta_19@...oo.com> wrote: > > > >> Hi, I am attaching a new patch which is tested to work on both 32 and 64 bit SSE2 linux OS. I have modified both x86-sse.S and x86-64.S. > >> I cannot say for sure that this will not break the build on other targets. I think someone should test this since I do not have those target machines. I will try to rectify any problems which arise due to this. > >> > >> Regarding working on converting other formats, though I don't think it will be too difficult but I will inform you whenever I get ample time to devote on it :) > >> > >> Cheers, > >> Deepika > >> From: magnum <john.magnum@...hmail.com> > >> To: john-dev@...ts.openwall.com > >> Sent: Thursday, February 7, 2013 2:43 PM > >> Subject: Re: [john-dev] mschapv2-bitsliced conversion- openmp support > >> > >> On 7 Feb, 2013, at 8:35 , Frank Dittrich <frank_dittrich@...mail.com> wrote: > >>> On 02/07/2013 04:47 AM, Solar Designer wrote: > >>>> On Wed, Feb 06, 2013 at 07:12:34AM -0800, deepika dutta wrote: > >>>>> Actually, I worked on coverting the DES_bs_crypt_plain(), which I had added to do single DES encryption, into SSE implementation. I have added this function into the x86-sse.S file. Since the code in this file was in assembly language, I tried some copy-pasting from previous code and added some assembly code myself to get the single DES encryption working. I compiled this program using linux-x86-64 option, everything is working fine and the latest banchmarks for bitsliced implementation are given below. You can test for yourself. The patch is attached. > >> > >> I'm confused - isn't x86-sse.S only used for 32 bit SSE builds? For 64-bit it should be x86-64.S. Or did you do both? That would be awesome. > >> > >>>> This is cool, but (un)fortunately we've just revised the MSCHAPv2 format > >>>> such that it does not depend on speed of DES encryption anymore - see > >>>> the "NetNTLMv1 and MSCHAPv2" thread in here. So I'm afraid there's no > >>>> point in introducing your changes to that format now (nor would they > >>>> apply to the revised code). > >>> > >>> But the changes should apply to the new mschapv2-naive format which > >>> basically is the renamed old mschapv2 format, intended for shorter > >>> cracking runs, because it loads hashes faster than the new mschapv2. > >> > >> True, although it wouldn't be much benefit other than as a nice example of code - you'll only use the old naïve version for very short runs where the speed doesn't matter anyway. > >> > >> Anyway, the thing that has stopped me from pulling the MSCHAPv2 BS patches into Jumbo is the fact they (so far) b0rked builds other than generic (and now linux-x86-64?). I haven't looked at this latest patch yet but I assume it still breaks some builds. There is no need to implement BS for every single target, but the changes need to be #ifdef'ed so that all builds pick code that works for it. Given that, I'll include it right away (even for mschapv2-naive). > >> > >> Also, new patches should ideally be rebased upon the bleeding-jumbo branch on GitHub: https://github.com/magnumripper/JohnTheRipper/tree/bleeding-jumbo > >> > >> magnum > >> > >> > >> <john-1.7.9-jumbo-5-MSCHAPV2-BS-4.diff> > > > > > > > > > > > > > <john-1.7.9-jumbo-5-MSCHAPV2-BS-5.diff> Content of type "text/html" skipped
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.