[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP952B2982A1353FFFEE4A28FD110@phx.gbl>
Date: Thu, 10 May 2012 00:43:48 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: wrapper around john to track attacks and sync files
On 05/09/2012 12:11 PM, Frank Dittrich wrote:
> On 05/09/2012 10:49 AM, Aleksey Cherepanov wrote:
>> At the moment I have wrapper that only wraps john but do not do
>> anything. I implemented it using Perl because it is a nice language
>> for such tasks, also it seems that much of the developers here know
>> it. Is it ok to use Perl? Or should I use C for that? And what
>> language should be used for final version (if it is different from
>> language for draft implementation)?
>
> For the draft implementation, perl is absolutely OK.
>
> For the final version, I am not so sure.
> Perl is still better than many other alternatives, but might not be
> available on all clients.
> Especially for Windows clients this might be a problem.
> Several scripts in the jumbo version already require perl.
> (There are even scripts in other languages, but I think Alexander tries
> to get rid of additional dependencies and prefers perl.)
> But these scripts are not really required to use john.
>
> So, IMO, a final version implemented in C would be preferable.
I'd like to add a few thoughts here.
I'm not saying we shouldn't consider perl for the final implementation.
In fact, if you think you need twice the time to implement the same
functionality in C, compared to a perl implementation, we'd need very
good reasons not to use perl.
Of course, it would be better to support more platforms.
But in a pen test scenario, you'd normally try to use clients
that are very similar to each other, because properly securing a zoo of
different systems isn't fun.
For the CrackMeIfYouCan contest:
If using perl means, Windows support will be more difficult (or it means
we need cygwin and are limited to 32bit), we an either live with the
fact that we might have less clients available, compared to a C
implementation, because the additional functionality we get due to
preferring perl over C easily compensates the possibly smaller number of
clients, then this might be OK.
Another way to work around the problem:
When we provide an installation media (this might be a remastered Ubuntu
live CD iso image or even an image of a recent Linux distribution
installed on an USB stick.
Then, windows users can boot from he USB stick, and run a Linux client.
Working with an installation on a USB stick usually is easier as booting
a Live CD, because it is faster, and you can have one partition which is
mounted writable, so we wouldn't need to write to the hard drive.
We'd need to provide an easy way to pick the keyboard layout during the
boot process, and we should pick a distribution with good hardware support.
An image which can be copied to a USB stick can also be a good idea in a
pen test scenario.
You could even use LUKS encrypted partitions (except the boot
partition). For the contest, you would have to disclose the LUKS
encryption key, and provide a link to a documentation how to add a new
encryption key and get rid of the old one...
I am, however, not sure if we would be able to distribute all the
software which might be needed during the contest.
(I didn't study the AMD/nvidia license terms for their OpenCL/CUDA
frameworks. May be we need to provide download instructions instead...)
The wrapper probably doesn't consume much CPU time, so picking C for
performance reasons is not necessary.
I don't know how you approach your draft implementation.
Usually you can divide the features to be implemented into must-have
features and nice-to-have features.
And you can divide them into features which are easy to implement and
features which are hard to implement. (By hard I don't just mean
time-consuming, bu rather involving difficult to solve problems where
you are not sure how to approach the implementation or whether your
ideas will work, and so on.)
For a draft implementation, I would pick hard to implement must-have
features first.
If you manage to implement them, everything is fine, because you
implemented something that will be useful. Making it even more useful
will be easy, because there are the easy to implement must-have features.
If you still have time after implementing these, you can spend your time
on the easy to implement nice-to-have features.
(But may be that by using your software you learn which other features
are needed that nobody considered during the initial draft...)
On the other hand, you find out that you didn't manage to solve the hard
problems for the must-have features in a reasonable time, you did at
least manage to avoid wasting time on easy to implement features which
will be useless unless the hard to implement must-have features are
implemented.
May be you need to think about different approaches.
May be you need to think about ways how to avoid the hard-to-solve
problems. (There might be easy workarounds for the features which were
supposed to be "must-have".)
Or may be you need to revise your schedule, and reduce the number of
features you implement. If this is the case, at least you did everything
you could to find this out as early as possible, when it is still time
to adjust the schedule, and not close to the end of the project, when
all your work turns out to be useless because some urgently needed
feature isn't implemented.
As soon as you do have some code which you think might be reviewed or
tested by others, please let me know.
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.
