Quick question

[nemo]

I'm a bit lazy. When cracking passwords, I don't much care to drag a ton of dictionary files around with me, so I wrote a program to generate every possible combination of characters for a password of arbitrary length. I've added logic to only allow passwords that meet Windows complexity requirements to be thrown to the output file to trim the results a bit, but am still having one nagging issue - when the file grows to 2G, my program automatically terminates. I've run into this once before, when my Nessus log file hit 2G, the program would terminate. The solution to that was to rename / compress the log file and move on, but that doesn't exactly help here.

Does anyone know the flag I've got to set if my program is going to create a file > 2G?

 

Thanks

 

ps - my environment is FC4, and disk space is not an issue

[Buffy]

In gcc I think you're looking for -D_LARGEFILE_SOURCE, although that should be a no-op on windows which doesn't care about file sizes like *nix does.

 

Why don'tcha just test as you generate? Are you doing multiple passes for some reason?

 

Cheers,

Buffy

[nemo]

I'd like to use the list with any number of applications on multiple platforms, so I wanted the output to be as raw as possible while still being relevant (not testing 8 zeroes as a password). That, and I've only put a few hours of thought into this little project - eventually, I'll probably make a respectable program of it and pre-hash passwords, add salting options and some cautionary "you're about to generate a petabyte of data, moron" messages - but for now, it's kinda fun to watch my processor scream.

[Buffy]

Right, but generating strings on the fly inside the cpu (even if you're doing some fancy algorithms with generating them) is a lot faster than hitting the disk, so if I were building it, I'd just generate and test...very portable and you don't have to worry about disk space, installation issues, file formats, wide chars, etc. etc. etc. You could even put in a flag for ebcdic!

 

Cheers,

Buffy

[Dark Mind]

Why'd you modify it Buffy? :rant:

 

I know all...

 

 

Right, but generating strings on the fly inside the cpu (even if you're doing some fancy algorithms with generating them) is a lot faster than hitting the disk, so if I were building it, I'd just generate and test...very portable and you don't have to worry about disk space, installation issues, file formats, wide chars, etc. etc. etc. You could even put in a flag for ebcdic!

 

Cheers,

Buffy

 

 

If I were you I would've fixed the speeling airs instead of adding the parenthesized :eek: ...

[nemo]

Maybe I'm not understanding... I am generating the strings and testing the complexity requirements in memory before hitting the disk. I don't want to build another cracker, just feed something relevant into one. If I don't hit the disk at all, as far as I know, I'd have to make it a part of an actual cracking app. By 'testing' do you mean the complexity requirements, or actually comparing hashes on the system I'm beating on?

[Buffy]

If I were you I would've fixed the speeling airs instead of adding the parenthesized :eek: ...

What spelling errors? You mean "ebcdic"? You're too young to know what that is!!! :rant: It was a parenthetical add to clarify for a confused nemo...

 

Cheers,

Buffy

[Buffy]

Maybe I'm not understanding... I am generating the strings and testing the complexity requirements in memory before hitting the disk. I don't want to build another cracker, just feed something relevant into one. If I don't hit the disk at all, as far as I know, I'd have to make it a part of an actual cracking app. By 'testing' do you mean the complexity requirements, or actually comparing hashes on the system I'm beating on?

Ah, so you are prepping a standard file format for later reading by a program you don't control. That makes sense then. Of course if the target program used stdin, you could pipe it!

 

I was thinking you had all the logic in place to generate it. It sounds like you're doing some writing, testing and editing of the files though, right? Otherwise as I say, if you were going to actually do the cracking, and assuming you're doing the generation in one pass with parameters to affect your generation algorithm then not putting them in files is the hot ticket...

 

Cheers,

Buffy

[Dark Mind]

:rant:

 

...I NEED to take a programming class, read up on the subject, or SOMETHING. This is complete jargon.

 

For not understanding much of what is said, I visit this forum far too often :eek:.

[nemo]

...if you were going to actually do the cracking, and assuming you're doing the generation in one pass with parameters to affect your generation algorithm then not putting them in files is the hot ticket...

agreed...

 

I've got some hardware in a lab to play with, if I get some time :rant: I'd like to write a cracker that can actually put four or more processors to good use. For the moment, though, I'm just working on a way to carry around 3K that will turn into ~2G instead of dragging all that data around.

 

Thanks for the compiler option.

[alexander]

well i can think of multipple approaches to this one:

1 create multiple files (for example start a _1 after the _0 reached 1.99 gigs)

2 buffer the output through tar

3 use other brute programs written by cryptographers

 

what passwords are you trying to crack anyways? most of the things i can imagine either are protected against brute forcing or are OS password containing files (shadow files and ntlm hashes (sam files))

If you want a script made for brute forcing passwords, take a look at brutus, it was among the most popular scripts to brute your way into websites...