Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 9 Mar 2011 18:25:29 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: mscash broken for ages?

Here is the 'prepare' function I have for mscash.  But without all the other john infrastructure changes, this function is 'meaningless'

static char *prepare(char *split_fields[10], struct fmt_main *pFmt)
{
//	if ((db->format == &fmt_mscash) || (db->format == &fmt_mscash2)) {
//		piece = (char *) mem_alloc(strlen(login) + strlen(ciphertext) + 4);
//		sprintf(piece, "M$%s#%s", login, ciphertext);
	char *cp;
	if (!strncmp(split_fields[1], "M$", 2))
		return split_fields[1];
	cp = mem_alloc(strlen(split_fields[0]) + strlen(split_fields[1]) + 4);
	sprintf (cp, "M$%s#%s", split_fields[0], split_fields[1]);
	if (valid(cp, pFmt))
	{
		char *cipher = str_alloc_copy(cp);
		MEM_FREE(cp);
		return cipher;
	}
	MEM_FREE(cp);
	return split_fields[1];
}

Hopefully the above code will get 'through' without problems.  In this 'prepare', I simply return the field[1] if it starts with "M$" which is pretty much the same as the fix you posted was doing.  

I just need to get with Solar, to coordinate getting a couple of larger 'structure' changes out. I personally think they should be put either into john proper, or put into the jumbo.  Changes like this (a new method) into the fmt_methods structure (and I have 2 changes like this), impact pretty much every single format.  Putting a patch out as a stand alone against a jumbo, ends up causing all patches to be very 'order dependant'.  

Jim.

>-----Original Message-----
>From: Bucsay Bal√°zs [mailto:earthquake@...on.hu]
>Hi!
>
>The problem is with the jumbo patch. 

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ