[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP31592036053E20866D13269FD1C0@phx.gbl>
Date: Sun, 20 May 2012 23:02:44 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: file synchronization backend for MJohn
On 05/20/2012 10:41 PM, Simon Marechal wrote:
> On 05/20/2012 10:14 PM, Aleksey Cherepanov wrote:
>> Looking deeply in git I found that the conflict could be easily fixed:
>> git inserts lines '<<<<<<< HEAD', '=======' and '>>>>>>> <commit_id>'
>> into file, these lines could be easily replaced by one sed call, also
>> git inserts new lines from file that are ok as is. Though I think it
>> is rather a hack but it could work and it may be hard to do it better.
>> So I will try to use it first.
>
> Automatically resolving conflicts is exactly something you should not
> do. Why not do it how it should be done ? When you can't push because
> somebody else did just before you did, you can :
> - force push, destroying everything that was pushed by others and just
> be obnoxious, or
> - pull, hope for an automatic resolution and push the merge, or
> - fetch, rebase your patch and push.
>
> I like the git approach because you can explain the reason of every
> change in the commit log and link every change to someone. It helps a
> lot for after action report.
Supporting "after action" reports is a definite plus.
OTOH, in most circumstances, the clients wouldn't need to know the
complete commit history.
They wouldn't even need to know the current list of cracked hashes or
list of password hashes remaining uncracked, except those hashes of the
hash format which will be attacked next by a particular client.
For most files, we could even reduce the risk of difficult to resolve
conflicts.
We could use separate pot files per hash format.
Since the sequence of lines in a pot file is irrelevant, we could always
sort the pot file alphabetically before committing.
May be the server should always verify newly added lines (thus making
sure the passwords do really crack the corresponding hashes).
No commit should remove or change any line in a pot file, only added
lines should occur.
For the list of remaining hashes, the opposite is true:
Every commit which changes such a file should just delete lines.
An exception could be that new sources of password hashes are found in
the middle of a cracking session.
In a pen test, you might be requested to test an additional system while
you are still trying to crack hashes from other systems.
For a contest, think of the CrackMeIfYouCan 2011 challenges.
We might need a new option replacing --show=LEFT, to avoid removing
lines containing duplicate hashes with different user names...
May be we could create a branch per client, and only the server is
allowed to push changes to the master branch containing the global pot
file (and may be different pot files per hash format and/or per input file.
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.
