Free Rainbow Tables | Forum

Home of the Distributed Generator and Cracker
It is currently 23 Apr 2014, 18:55

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 32 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: rcrcacki_mt GUI
PostPosted: 02 Jan 2011, 19:18 
Offline
Shoulder Surfer

Joined: 02 Jan 2011, 18:49
Posts: 16
quel wrote:
others:
2) GUI for rcracki_mt (qt, gtk, wxwindows, etc.) - it has to be cross platform.

I'm currently working on a GUI (GTK+) for rcracki_mt which runs both on Linux and on Windows. I attached the source code and a pre-compiled executeable for Linux (should run on all newer systems, tested under Fedora 13 & 14 x86_64, GTK+ 2.20.1), but the Windows version has still some bugs which will be fixed soon (I hope).
Constructive comments and criticism welcome.

Paragon


Attachments:
rcracki_mt-GUI_0.6.5.2.tar.bz2 [151.47 KiB]
Downloaded 701 times
Top
 Profile  
 
 Post subject:
Posted: 03 Jan 2011, 00:11 


Top
  
 
PostPosted: 03 Jan 2011, 00:11 
Offline
Total Hash Enlightenment

Joined: 15 Jul 2009, 22:38
Posts: 1486
Location: Dallas, TX, USA
Paragon wrote:
quel wrote:
others:
2) GUI for rcracki_mt (qt, gtk, wxwindows, etc.) - it has to be cross platform.

I'm currently working on a GUI (GTK+) for rcracki_mt which runs both on Linux and on Windows. I attached the source code and a pre-compiled executeable for Linux (should run on all newer systems, tested under Fedora 13 & 14 x86_64, GTK+ 2.20.1), but the Windows version has still some bugs which will be fixed soon (I hope).
Constructive comments and criticism welcome.

Paragon


Excellent! I had to add -lgthread-2.0 to get it to link with just a make <enter>. We'll have to switch to using autoconf/configure scripts to build the GUI if the dependencies are met and so forth. I'm not sure your version is directly based on 0.6.5.2. HashAlgorithm.h appears to be based on 0.6.4 for instance. Also, we do want to preserve a cli option. I updated the Makefile a bit to make it cleaner.

The binary doesn't seem to work for at least one other person and I. For a binary release you may want to look at the Makefile in gitorious for distrrtgen where we do static builds. It does bloat the binary but ensures it runs regardless of the libraries there or missing as well as if the versions differ. (-static -static-libgcc added to CFLAGS and LFLAGS)

Output and session files/names probably need a browse option as I generally don't want to type the full path or store everything in the directory with the binary and code.

For Load tables we need to have some sort of option for wildcard like md5_loweralpha-numeric-space#1-8_* or md5_loweralpha-numeric-space#1-8_?. I store my files just like they are on GARR so I can select md5_loweralpha-numeric-space#1-8_0 or the parent md5 directory.

I think it may have thread issues as running a single thread the progress bar and counter seem to work correctly. Also, on completion is has a scroll bar. There doesn't appear to be a way to copy and paste the output messages. However, when I run with 2 threads the progress bar and counter generally freeze at 0 or 1 and when the session completes it has the correct hash but the GUI is completely locked.

I didn't test session naming or resuming or keeping precalcs but the rest seems to work properly except for when threads > 1.

I like it keep working!


Attachments:
File comment: some cleanup
rcracki_mt-GUI_0.6.5.2_quel.patch [2.62 KiB]
Downloaded 448 times
Top
 Profile  
 
PostPosted: 03 Jan 2011, 01:32 
Offline
Dictionary

Joined: 31 Oct 2007, 01:57
Posts: 64
Okay I was doing some thinking of what could cause the threads to lock up on the GUI and I believe its most likely because your trying to have multiple threads get their progress be updated on the GUI. Now my solution is to have only thread 1 access the GUI to update it and also have it do this progress calculation in order to have what I think is a thread safe operation. Basicly the idea is to added all the tested passwords and then divide the keyspace by them this would give a very accurate result for the guy and should be thread safe.

percentage = keyspace / (thread1passes + thread2passes + ... )


Top
 Profile  
 
PostPosted: 03 Jan 2011, 15:20 
Offline
Shoulder Surfer

Joined: 02 Jan 2011, 18:49
Posts: 16
quel wrote:
I'm not sure your version is directly based on 0.6.5.2. HashAlgorithm.h appears to be based on 0.6.4 for instance.

I downloaded the latest sources from Sourceforge which is version 0.6.5.2, I think.

quel wrote:
I think it may have thread issues as running a single thread the progress bar and counter seem to work correctly. Also, on completion is has a scroll bar. There doesn't appear to be a way to copy and paste the output messages. However, when I run with 2 threads the progress bar and counter generally freeze at 0 or 1 and when the session completes it has the correct hash but the GUI is completely locked.

I know this bug from earlier GTK+ versions. Which version do you have installed? As I mentioned before, on Fedora 13 & 14 (GTK+ 2.20.1) it works fine (but you're right, it should be downwardly compatible). I'll try to fix it.

quel wrote:
There doesn't appear to be a way to copy and paste the output messages.

Mmh, that's strange. You can't mark any text? Is there some kind of left-click -> copy text? I have no idea what it is.

rubendodge wrote:
I believe its most likely because your trying to have multiple threads get their progress be updated on the GUI. Now my solution is to have only thread 1 access the GUI to update it and also have it do this progress calculation in order to have what I think is a thread safe operation.

At first glance, there is only one thread which updates the progress bar (in CCrackEngine::Run), but I believe that's what causes the error. It seems like GTK+ becomes confused when another thread tries to access the GUI outside the main loop. I'll try to solve this problem with a function which is called every ~500ms inside the gtk_main loop and which updates the progress bar so that there are no GTK calls in another thread.

I'll keep you updated, and thanks for the comments.

Paragon


Top
 Profile  
 
PostPosted: 03 Jan 2011, 19:42 
Offline
Total Hash Enlightenment

Joined: 15 Jul 2009, 22:38
Posts: 1486
Location: Dallas, TX, USA
Paragon wrote:
quel wrote:
I'm not sure your version is directly based on 0.6.5.2. HashAlgorithm.h appears to be based on 0.6.4 for instance.

I downloaded the latest sources from Sourceforge which is version 0.6.5.2, I think.


Those are the latest and that's what I started my diff with.

Paragon wrote:
quel wrote:
I think it may have thread issues as running a single thread the progress bar and counter seem to work correctly. Also, on completion is has a scroll bar. There doesn't appear to be a way to copy and paste the output messages. However, when I run with 2 threads the progress bar and counter generally freeze at 0 or 1 and when the session completes it has the correct hash but the GUI is completely locked.

I know this bug from earlier GTK+ versions. Which version do you have installed? As I mentioned before, on Fedora 13 & 14 (GTK+ 2.20.1) it works fine (but you're right, it should be downwardly compatible). I'll try to fix it.


2.12.12 (Debian stable)

Paragon wrote:
quel wrote:
There doesn't appear to be a way to copy and paste the output messages.

Mmh, that's strange. You can't mark any text? Is there some kind of left-click -> copy text? I have no idea what it is.


No I can't highlight text at all with the mouse.

Paragon wrote:
I'll keep you updated, and thanks for the comments.


Thanks for your work on this! Paragon brings rcracki_mt out of the stone age ;) (I generally loathe any front-end or GUI type work so I don't do it and you've saved me from having to do so.)


Top
 Profile  
 
 Post subject: Re: rcrcacki_mt GUI
PostPosted: 04 Jan 2011, 19:45 
Offline
Shoulder Surfer

Joined: 02 Jan 2011, 18:49
Posts: 16
Okay, I changed the code so that no other thread tries to access the GUI (a lot of global variable stuff, but this doesn't matter at the moment). When starting more than one thread, the GUI shouldn't freeze anymore (I tested it several times and it runs well, even on Windows). GThread was totally removed. Would be nice if you and others could test it.

Furthermore, I fixed a bug concerning the charset: when no charset.txt was found in the folder, it will use a hardcoded one. Maybe I will add a possibility to specify a custom charset file in the future, we will see.
At last, I added a 'Do you really want to quit?' dialog which pops up when the user quits while rcracki_mt is still running. If this is the case, it will keep the session files on disk.
In addition, there are several smaller things I changed/fixed: you can now browse where to save the cracked hashes and the session files, the progress bar has a percent indicator, verbose output etc.

Of course there are some minor bugs, and I don't have a clue why you can't mark any text, quel, but I think a 'Clear Messages' and a 'Copy result to clipboard' button would be useful. I also tried to compile the executeable with static libraries, but static libraries and GTK+ is a pain (lots of undefined references). However, here's the new version, just type 'make' and run rcracki_mt_gui.

Paragon


Attachments:
rcracki_mt-GUI_0.6.5.2.tar.bz2 [61.5 KiB]
Downloaded 534 times
Top
 Profile  
 
 Post subject: Re: rcrcacki_mt GUI
PostPosted: 05 Jan 2011, 07:58 
Offline
Total Hash Enlightenment

Joined: 15 Jul 2009, 22:38
Posts: 1486
Location: Dallas, TX, USA
Paragon wrote:
Okay, I changed the code so that no other thread tries to access the GUI (a lot of global variable stuff, but this doesn't matter at the moment). When starting more than one thread, the GUI shouldn't freeze anymore (I tested it several times and it runs well, even on Windows). GThread was totally removed. Would be nice if you and others could test it.

Furthermore, I fixed a bug concerning the charset: when no charset.txt was found in the folder, it will use a hardcoded one. Maybe I will add a possibility to specify a custom charset file in the future, we will see.
At last, I added a 'Do you really want to quit?' dialog which pops up when the user quits while rcracki_mt is still running. If this is the case, it will keep the session files on disk.
In addition, there are several smaller things I changed/fixed: you can now browse where to save the cracked hashes and the session files, the progress bar has a percent indicator, verbose output etc.

Of course there are some minor bugs, and I don't have a clue why you can't mark any text, quel, but I think a 'Clear Messages' and a 'Copy result to clipboard' button would be useful. I also tried to compile the executeable with static libraries, but static libraries and GTK+ is a pain (lots of undefined references). However, here's the new version, just type 'make' and run rcracki_mt_gui.

Paragon


First, again thank you! Second, at the rate you are going minimally you should sign up for gitorious and clone the project so you can keep commit history of changes and eventually issue a pull request (http://gitorious.org/freerainbowtables- ... nbowtables). It is currently synced with rcracki.sourceforge.net trunk (64-bit fixes for overflows mostly compared to 0.6.5.2.) If you prefer svn then I'll have to see if I can create a branch where you have commit access.

1) an option to just input one hash instead of loading a file would be nice
2) thanks for the more flexible result saving option (and session options)
3) pausing during pre-calculation seems to work sometimes but not always ie it finishes that pre-calculation but then keeps going instead of pausing like the cli does
4) if we're in a paused state shouldn't we be able to abort?
5) sometimes abort, even with 1 thread, doesn't seem to have impact and after 20 seconds a second abort does (especially true if I pause, resume, then keep clicking abort)
6) test a variety of keep precalc, abort, pause, resume, start options and they all seemed to work correctly minus #5
7) memory limit set to anything including 50 seems to still get me 541mb+ memory (ie the size of a table file plus some index)
8) the hardcoded charset is one of those double edged swords - until we have complex hybrids keeping it as a file gives a lot of flexibility. Also, with RTI2 the charset will be part of the file header so there won't be a need for this hardcode.
9) I can mark text in single and multi-threaded thread mode (and copy it)
10) copy result to clipboard is probably a good idea
11) clear is also a good idea in case people do multiple runs
12) still need some way to wildcard table inputs
13) I see your point about a static build being obnoxious
14) If you take a look at https://build.opensuse.org/project/pack ... %3Aquelrod you may be able to get some compilation/build testing for a decent variety of GNU/Linux systems. At least to know what libraries we might be missing.


Top
 Profile  
 
 Post subject: Re: rcrcacki_mt GUI
PostPosted: 05 Jan 2011, 19:41 
Offline
Shoulder Surfer

Joined: 02 Jan 2011, 18:49
Posts: 16
quel wrote:
First, again thank you! Second, at the rate you are going minimally you should sign up for gitorious and clone the project so you can keep commit history of changes and eventually issue a pull request (http://gitorious.org/freerainbowtables- ... nbowtables). It is currently synced with rcracki.sourceforge.net trunk (64-bit fixes for overflows mostly compared to 0.6.5.2.) If you prefer svn then I'll have to see if I can create a branch where you have commit access.

Okay, I signed up for gitorious and cloned the project. You can get a copy of rcracki_mt-GUI under the following link: http://gitorious.org/~paragon/freerainb ... cki_mt-gui

quel wrote:
3) pausing during pre-calculation seems to work sometimes but not always ie it finishes that pre-calculation but then keeps going instead of pausing like the cli does

Pausing and aborting is still a bit buggy, but it shouldn't be a great problem to fix this.

quel wrote:
7) memory limit set to anything including 50 seems to still get me 541mb+ memory (ie the size of a table file plus some index)

Does this problem disappear when you run rcracki_mt from the terminal with the -m flag? I tried it several times and found it a bit ... "unpredictable", because when I set this option to 50, the memory usage was about 80mb etc.

quel wrote:
8) the hardcoded charset is one of those double edged swords - until we have complex hybrids keeping it as a file gives a lot of flexibility. Also, with RTI2 the charset will be part of the file header so there won't be a need for this hardcode.

Okay, I just recognized that when you put the executeable in /usr/bin, it doesn't find a charset so I found it a good idea to use a hardcoded one. But when using RTI2, the problem doesn't play a role anymore.

Paragon


Top
 Profile  
 
 Post subject: Re: rcrcacki_mt GUI
PostPosted: 05 Jan 2011, 20:50 
Offline
Total Hash Enlightenment

Joined: 15 Jul 2009, 22:38
Posts: 1486
Location: Dallas, TX, USA
Paragon wrote:
Okay, I signed up for gitorious and cloned the project. You can get a copy of rcracki_mt-GUI under the following link: http://gitorious.org/~paragon/freerainb ... cki_mt-gui


Excellent

Paragon wrote:
Pausing and aborting is still a bit buggy, but it shouldn't be a great problem to fix this.


k

Paragon wrote:
quel wrote:
7) memory limit set to anything including 50 seems to still get me 541mb+ memory (ie the size of a table file plus some index)

Does this problem disappear when you run rcracki_mt from the terminal with the -m flag? I tried it several times and found it a bit ... "unpredictable", because when I set this option to 50, the memory usage was about 80mb etc.


Yes, the option was a quick hack and isn't complete as it mostly restricts the memory for table allocation and not for index memory allocation. So setting it to 50mb and seeing 80mb isn't uncommon. But only in the GUI does setting 50 mb get me 541mb which is what I get with it set to 0 and on the cli I get about 80mb used with -m 50 as you note. I need to clean up and all the allocation code because it was created as a *non-static* memory pool that isn't actually used as a memory pool should be used. When you say unpredictable do you mean you always see more overhead than you set by some value about 30mb or that some runs you get 541mb and others you get 80mb? Also, were your results consistent across the cli and the GUI?

Paragon wrote:
quel wrote:
8) the hardcoded charset is one of those double edged swords - until we have complex hybrids keeping it as a file gives a lot of flexibility. Also, with RTI2 the charset will be part of the file header so there won't be a need for this hardcode.

Okay, I just recognized that when you put the executeable in /usr/bin, it doesn't find a charset so I found it a good idea to use a hardcoded one. But when using RTI2, the problem doesn't play a role anymore.


Oh good point I never thought about my opensuse builds that don't include charset.txt. With distrrtgen it's easy enough to package the binary and charset.txt at the same time.

Do you have any experience with writing autoconf/configure style build setups? I ask only because I've avoided it so far with simple Makefiles but we'll need to do library detection and allow GUI or CLI or both to be built at compile time.

Also, are you doing the windows builds with mingw? I expect that to have the windows GUI build we'll need a full installer that optionally fetches and installs GTK similar to what pidgin does.


Top
 Profile  
 
 Post subject: Re: rcrcacki_mt GUI
PostPosted: 06 Jan 2011, 14:33 
Offline
Shoulder Surfer

Joined: 02 Jan 2011, 18:49
Posts: 16
quel wrote:
When you say unpredictable do you mean you always see more overhead than you set by some value about 30mb or that some runs you get 541mb and others you get 80mb? Also, were your results consistent across the cli and the GUI?

(Ahead, I'm not a rainbow table expert) When running a session with 512mb Rainbow Table files, I would expect that the memory usage is about 540mb (table + index, but in any case over 512mb), but it was 438mb. Or I ran a session (md5_loweralpha-numeric-space#1-8, GUI) and the memory usage was just about 240mb (without using a memory limit). I mean, it behaves quite unexpected. However, I did several test runs with specifying a memory limit and it worked for me, both command-line and GUI version. I guess it must must be a bug in rcracki_mt, not in the GUI, because I did not change any table reading / loading code so far.

quel wrote:
Do you have any experience with writing autoconf/configure style build setups? I ask only because I've avoided it so far with simple Makefiles but we'll need to do library detection and allow GUI or CLI or both to be built at compile time.

No, unfortunately I haven't. I tried it several times but found it always too complex for my projects. A simple Makefile was sufficient. However, you're right, we should use some kind of library detection. Maybe I give autoconf a second chance, we'll see.

quel wrote:
Also, are you doing the windows builds with mingw? I expect that to have the windows GUI build we'll need a full installer that optionally fetches and installs GTK similar to what pidgin does.

Under Windows, I build the GUI with Dev-C++, which has a Mingw compiler system with GCC 3.4.2. I also tried to use a cross-compiler under Linux and compile the executeable for Windows, but this wasn't what I was looking for (furthermore it didn't really work). Maybe we can use the gtk-win project, but I've never tried it out.

Paragon

Edit: autoconf and configure script works fine. I think it's a good idea to use something like './configure --enable-gui' or './configure --disable-gui' so the user can decide whether he wants the GUI or the command-line version to be built.


Top
 Profile  
 
 Post subject: Re: rcrcacki_mt GUI
PostPosted: 09 Jan 2011, 07:51 
Offline
Total Hash Enlightenment

Joined: 15 Jul 2009, 22:38
Posts: 1486
Location: Dallas, TX, USA
Paragon wrote:
(Ahead, I'm not a rainbow table expert) When running a session with 512mb Rainbow Table files, I would expect that the memory usage is about 540mb (table + index, but in any case over 512mb), but it was 438mb. Or I ran a session (md5_loweralpha-numeric-space#1-8, GUI) and the memory usage was just about 240mb (without using a memory limit). I mean, it behaves quite unexpected. However, I did several test runs with specifying a memory limit and it worked for me, both command-line and GUI version. I guess it must must be a bug in rcracki_mt, not in the GUI, because I did not change any table reading / loading code so far.


Ah, yes the memory behavior without any limits can be a bit erratic. The issues stem from Public.cpp's unsigned long GetAvailPhysMemorySize(). In particular on linux while the code is better than that it was before it is still not the full picture.

Code:
   struct sysinfo info;
   sysinfo(&info);
   return ( info.freeram + info.bufferram ) * (unsigned long) info.mem_unit;


The problem is that while adding the bufferram to freeram improved the issue a good year ago when I made the change, cachedram is technically free but not available via sysinfo. Actually, I finally did what I should have done a long time ago and noted that free ignores sysinfo altogether for memory information and gets it from the proc filesystem. At least I know where to get the data from now. I'll put this on my todo list.

Paragon wrote:
quel wrote:
Do you have any experience with writing autoconf/configure style build setups? I ask only because I've avoided it so far with simple Makefiles but we'll need to do library detection and allow GUI or CLI or both to be built at compile time.

No, unfortunately I haven't. I tried it several times but found it always too complex for my projects. A simple Makefile was sufficient. However, you're right, we should use some kind of library detection. Maybe I give autoconf a second chance, we'll see.


That sounds like my experience with it.

Paragon wrote:
quel wrote:
Also, are you doing the windows builds with mingw? I expect that to have the windows GUI build we'll need a full installer that optionally fetches and installs GTK similar to what pidgin does.

Under Windows, I build the GUI with Dev-C++, which has a Mingw compiler system with GCC 3.4.2. I also tried to use a cross-compiler under Linux and compile the executeable for Windows, but this wasn't what I was looking for (furthermore it didn't really work). Maybe we can use the gtk-win project, but I've never tried it out.


Ouch 3.4.x gives really horrific performance so we'll have to find a better option for windows GUI builds.

Paragon wrote:
Edit: autoconf and configure script works fine. I think it's a good idea to use something like './configure --enable-gui' or './configure --disable-gui' so the user can decide whether he wants the GUI or the command-line version to be built.


Excellent! I just gave it a shot and that is moving in the right direction. I notice that even if you don't --enable-gui it still checks for GTK, GLIB, PANGO, and CAIRO. The SSL check is long overdue. Would you clean up the code duplication across the cli and gui directories? Also, take a look at how ophcrack.sourceforge.net lets you add multiple tables as we need something like that. I think I'll be ready to merge this once the three issues I listed are taken care of except for the windows builds. I'm happy to let *nix users get the sneak peak while we sort out the windows side and get some feedback.


Top
 Profile  
 
 Post subject: Re: rcrcacki_mt GUI
PostPosted: 10 Jan 2011, 20:09 
Offline
Shoulder Surfer

Joined: 02 Jan 2011, 18:49
Posts: 16
quel wrote:
Ouch 3.4.x gives really horrific performance so we'll have to find a better option for windows GUI builds.

The latest version of Dev-C++ was released in 2005, so I don't wonder why they are using GCC 3.4.2. I'm going to take a look at other IDEs for Windows later, my current roadmap is to get the Linux version run properly.

quel wrote:
Would you clean up the code duplication across the cli and gui directories?

The problem is that I include <gtk/gtk.h> in global.h, thus all other files include GTK, too. Maybe I can solve this problem with a config.h header, but even if so, I still have the problem that I need the client's RainbowCrack.cpp. However, I'll take a look at this (may take a bit longer since I haven't much time at the moment).

quel wrote:
Also, take a look at how ophcrack.sourceforge.net lets you add multiple tables as we need something like that.

Mmh, when you say you store the rainbow tables like they are on GARR, there shouldn't be a problem to select multiple directories. I fixed this issue recently, so you can select more than only one folder (just hold the shift key when loading rainbow tables). Or do you mean we need a real 'rainbow table manager' like ophcrack has?

Paragon


Top
 Profile  
 
 Post subject: Re: rcrcacki_mt GUI
PostPosted: 11 Jan 2011, 02:08 
Offline
Total Hash Enlightenment

Joined: 15 Jul 2009, 22:38
Posts: 1486
Location: Dallas, TX, USA
Paragon wrote:
The latest version of Dev-C++ was released in 2005, so I don't wonder why they are using GCC 3.4.2. I'm going to take a look at other IDEs for Windows later, my current roadmap is to get the Linux version run properly.


Agreed, *nix first and we'll sort out windows later since it is likely to be a lot more trouble.

Paragon wrote:
quel wrote:
Would you clean up the code duplication across the cli and gui directories?

The problem is that I include <gtk/gtk.h> in global.h, thus all other files include GTK, too. Maybe I can solve this problem with a config.h header, but even if so, I still have the problem that I need the client's RainbowCrack.cpp. However, I'll take a look at this (may take a bit longer since I haven't much time at the moment).


If it's just a matter of a single include then can't you combine an #ifdef with the configure? I'm confused by what you mean the client's RainbowCrack.cpp unless you are just referring to the cli v gui code path?

Paragon wrote:
quel wrote:
Also, take a look at how ophcrack.sourceforge.net lets you add multiple tables as we need something like that.

Mmh, when you say you store the rainbow tables like they are on GARR, there shouldn't be a problem to select multiple directories. I fixed this issue recently, so you can select more than only one folder (just hold the shift key when loading rainbow tables). Or do you mean we need a real 'rainbow table manager' like ophcrack has?


Oh I did not try shift/ctrl when selecting the directories. I would select 1 directory and want to put a * or ? where you'd see 0, 1, 2, and 3 (use to cli.)

No I don't think we need a full table manager like Ophcrack, I only used it as an example. One day we'll probably want something a bit more intuitive like that but this is not a requirement to get your GUI merged into the source tree.


Top
 Profile  
 
 Post subject: Re: rcrcacki_mt GUI
PostPosted: 11 Jan 2011, 19:33 
Offline
Shoulder Surfer

Joined: 02 Jan 2011, 18:49
Posts: 16
quel wrote:
If it's just a matter of a single include then can't you combine an #ifdef with the configure? I'm confused by what you mean the client's RainbowCrack.cpp unless you are just referring to the cli v gui code path?

The problem is hard to explain (and unfortunately my English is too bad for an attempt). However, when you say code duplication, do you mean that, e.g. fast_md5.cpp are the same files as well in the gui as in the cli directory? If so, it's of course no problem to use only one fast_md5.cpp since I didn't change the code to use it in the GUI.
The bad thing is that I had to change files like RainbowCrack.cpp extremely. I cannot use one RainbowCrack.cpp for both CLI and GUI, that's the reason why I created two directories: one for the client, the other for the GUI (and I still find it a good idea to do so: it's the easiest way and you guys can keep on working on rcracki_mt without having to deal with some GUI code I added. Furthermore, nobody gets confused about which files belong to the GUI and which files belong to the client).

quel wrote:
Oh I did not try shift/ctrl when selecting the directories. I would select 1 directory and want to put a * or ? where you'd see 0, 1, 2, and 3 (use to cli.)

Yes, you can select multiple directories (it's like you do something like
Quote:
./rcracki_mt -l hashlist /home/user/RainbowTables/md5_loweralpha#1-8 /home/user/RainbowTables/md5_alpha#1-9

so it will use all rainbow tables in both directories)
Or, assume you have a directory called MD5 where all rainbow tables for MD5 hashes are placed, with subdirectories, too. So the only thing you have to do is to select this one MD5 directory. rcracki automatically scans for tables in this directory and all subdirectories. You can even specify your root directory, rcracki will scan all subdirectories for rainbow tables (but that takes a long time and makes no sense at all). Also, I found out that there is no need for any wildcards. Or do I misunderstand you completely?

quel wrote:
I notice that even if you don't --enable-gui it still checks for GTK, GLIB, PANGO, and CAIRO.

Fixed (but not uploaded yet).

Paragon

Edit: I removed all file duplications as good as possible and fixed some other minor bugs. In my opinion, the GUI is ready for some test runs, what do you think? The next goal I'm concentrating on is to get it run under Windows. I'll keep you updated ...


Top
 Profile  
 
 Post subject: Re: rcrcacki_mt GUI
PostPosted: 31 Jan 2011, 15:18 
Offline
Shoulder Surfer

Joined: 02 Jan 2011, 18:49
Posts: 16
The last few days I tried to get a Windows version running. I thought it is a good idea to use a real installer, so I gave NSIS a try and found it quite good for our purposes. Furthermore, I added the Gtk-Win project which installs all necessary GTK+ libraries needed to run rcracki_mt-GUI. I uploaded a Windows installer (32 bit) which installs Gtk-Win and rcracki_mt-GUI to gitorious.org. Of course, it's only a first test, but it would be nice if someone could test it and report if it runs or if any libraries are missing.
Unfortunately, I'm still using an old GCC version under Windows. For a release, I have to look for a newer one ...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 32 posts ]  Go to page 1, 2, 3  Next

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group