[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 21 Feb 2014 09:13:36 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: SAP-B obscure bug or intended behavior?
On 02/20/2014 11:17 PM, magnum wrote:
> Thanks for reporting!
>
> I'm passing it on to john-dev to start with. Anyone got a clue? I know
> we tested this format with a whole lot of real SAP hashes. I'll dig out
> older versions of our format and check if it behaves differently.
>
> magnum
>
> On 2014-02-20 22:42, atom wrote:
>> Hey Magnum,
>>
>> I was recently adding SAP-B to oclHashcat and used jtr as a reference for
>> implementing. I found a problem in the implementation that I think goes
>> back to the reversal of the algorithm. Since I don't know who it reversed
>> maybe you can forward it to the right person?
I think I might have been the first one who reversed SAP's password hash
algorithm back in 2004 (on a 32 bit Linux system), but I never published
my JtR patch.
Since atom speaks German, here is a link to an old article I Published
after reversing the algorithms for SAP CODVN B and CODVN D:
http://www.it-audit.de/assets/artikel/eigen/SAP_Passwort_Update.pdf
The code that got included into JtR was posted years later by someone else.
>> The question is, how does SAP react in that case.
>>
>> Heres's the hash that can be used for reproduce:
>>
>> 12850413$1470EF2F683C956D:46813230
SAP computes exactly the same CODVN B hash for this user name and password.
Frank
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.
