Developer Guide

From Cryptohaze Project Wiki
Jump to: navigation, search

You're insane. Or awesome. Quite possibly both! You are nuts enough to want to help out with this project, and to understand the source to add new functionality, patch bugs, or generally be useful.


Overview of Langauges & Technologies

The Cryptohaze tools are written with the host code mostly C++ (though a lot of it looks like C), with device code either written in CUDA (for nVidia), or OpenCL (for ATI/CPU use). There's work that can be done in any of these, though obviously being familiar with all three is useful. Fortunately, both CUDA and OpenCL look a lot like C - so if you're familiar with C and C++, you're probably good. If you're not comfortable with the CUDA or OpenCL side of things, there's still a lot that can be done on the host side, especially for Windows. A nice GUI would be useful, as would a Windows service, as would a tray icon to interface with the service... :)

Code Directory Structure

The source tree checked out (only bother with Cryptohaze-Combined - the others are obsolete and I really should remove them, and for that matter put the "Cryptohaze-Combined" tree as trunk) has a few directories, and I'll go through each of them here.

Top Level Directories

Several top level directories are generated as needed (most of the build* directories and the binaries directory). Others are part of the source tree & included in SVN.


The build_windows directory contains all of the mess required to build the tools on Windows. The "Cryptohaze-Tools" directory contains the main project solution for the build, and the other directories contain binary-specific build data. copyKernels.bat copies the needed OpenCL kernels into the right place for the binaries. The output of this should all be in the binaries directory.


This directory contains some of the open source dependencies that are needed to build the project. These are mostly present for building on Windows, as headers & source are pulled from here to build the needed parts on Windows. By building argtable, curl, and pdcurses into the binary instead of as libraries, it simplifies the build process and makes the binaries more or less self contained - they don't have library dependencies. I'm not opposed to library dependencies, I just don't quite know how to make them work on Windows. :)


Random development stuff can go in here. Random stuff also lives in src/Toys - I should standardize the location.


Documentation notes and change logs. Try to keep them updated - I'm not great at it, but am trying to get better.


Include files for the tools. The directory structure under here is described below, and is the same as the src directory structure.


Static binary libraries that are compiled into the project. This is things like boost libs, argtable for command line parsing, and libcurl (currently). By including the binaries here, people can build the project without requiring all of these properly set up, and the project will have the needed source compiled in, improving the reliability of the binaries on various platforms. It's been a long time since someone complained that the stuff wouldn't run on their system, so I think the static linking approach is well worth it.


Useful cross-platform stuff. Charset files, test hashes, verification scripts, etc. Of note in here is the grt_verification directory. This contains a few scripts to verify the GRTGen output - it should always be binary-correct to the md5s calculated. ANY CHANGES to the GRTGen code must be verified with these scripts to ensure it has not broken generation.


The main source code. The directory structure matches inc, and will be described below.

build* scripts

These build releases for the specified platform. For Windows, the project must be fully built in visual studio before running this, and the output directory must be manually zipped up. Looking to fix this...

src & inc structure

The src & inc directories have a number of subdirectories, corresponding (more or less) to project components and what the files are used for. This helps keep things cleaner, though is not currently perfect.


This directory contains common files to all the Cryptohaze projects. Any file in here should not be CUDA or OpenCL specific, and should have use across all the projects. Right now, this is not entirely the case, but the goal is to make it this way going forward. Ideally, source files in here will be primitive types and not have dependencies to other classes, or at least be able to function without them.


This is a directory for utility files that are CUDA specific. They should be usable in all projects.


This directory contains the CUDA device files (.cu files) for the CUDA rainbow table code. This is project and technology specific code.


This directory contains the host files for CUDA rainbow tables. These classes make CUDA specific calls and require being linked against the CUDA libraries to function.


This directory contains common rainbow table code that is not technology specific and does not require linking against technology libraries. This includes things like the table header and table search classes, display classes used with both OpenCL and CUDA versions, verifier code, etc.


This directory contains the OpenCL device kernels for rainbow table code. Note that includes are handled by the calling host code, not the kernels - OpenCL does not support the #include directives.


This directory contains, as might be expected, the host side OpenCL code for rainbow tables.


Multiforcer CUDA kernels live here! Surprise!


The bulk of the multiforcer code lives here - host side code dealing with CUDA specific functions.


This is Multiforcer related code that, ideally, has no CUDA dependencies. The display class and network classes live here.


This is a directory for OpenCL specific utilities and classes that can be used in any project. Of note, the Cryptohaze OpenCL class lives here, abstracting out a lot of the OpenCL specific quirks and making things easier to deal with.


Random development widgets and play code goes here. Or in devel - pick one.


PHP source code lives here for the various web related functionality.

Adding Multiforcer Hash Types

One of the common tasks people are interested in is that of adding hash types to the Multiforcer. I'll write up a full tutorial, but it involves adding the CHHashType{blah} classes, adding the needed magic in the CHHashes file, and implementing the hash type as a .cu file.

GUI Specs

If you're awesome enough to want to write a GUI, look here: GUI Design

Personal tools