haiti is a Ruby CLI and library that fingerprint hashes across 675+ algorithms, mapping each candidate to hashcat and John the Ripper references for authorized pentest and CTF workflows.
| Tool | noraj/haiti — hash type identifier available as both a CLI and a Ruby library |
| Category | hash analysis / reconnaissance utility |
| Primary Use | determining which algorithm produced a given digest so hashcat or John the Ripper can be configured correctly during authorized engagements |
| Safe Use | for authorized penetration tests, CTF and lab exercises, and defensive research where analysts must classify credentials found in their own systems |
| Telemetry Note | passive classification tool — performs no network activity itself; defenders should note that audit trails of credential cracking pipelines reveal tool choices like this one |
haiti, short for **HA**sh **I**den**T**if**I**er, is a Ruby tool by Alexandre ZANNI (@noraj) that answers one deceptively simple question: given a digest, which algorithm produced it? The repository at noraj/haiti ships the project as both a command-line utility and a library, which makes it usable interactively during an engagement or embedded in a larger Ruby automation pipeline. It is a fork of Orange-Cyberdefense/haiti, so its lineage is commercial security consulting rather than hobby scripting, and it carries an MIT license with over a thousand stars. The topics list (pentest-tool, ctf-tools, hash, hackthebox, tryhackme) makes the intended audience explicit: practitioners working sanctioned labs and engagements.
The feature set, as stated in the README, is compact but deep. haiti detects 675+ hash types, covering modern algorithms such as SHA3, Keccak, and Blake2 in addition to the legacy zoo of MD5, SHA1, NTLM-era formats, and application-specific digests. Critically, each identification is annotated with the corresponding hashcat mode number and John the Ripper format reference. That mapping is where the tool earns its keep: knowing a digest is "some SHA-2 variant" is trivia, but knowing it is hashcat mode 1740 versus mode 1750 is the difference between a correctly configured audit and hours of wasted compute. The README also brands the project as "Hackable," signaling that the detection database is meant to be extended by its users.
Architecturally, the dual CLI/library split is worth pausing on. The CLI gives a quick interactive answer — paste or pipe a hash, receive ranked candidates — which suits the rhythm of a CTF or an exam like those on hackthebox and tryhackme. The library mode lets you call the classification logic directly from Ruby code, so haiti can sit inside a credential-audit harness that processes dumps found on systems you are authorized to test, classifying each digest before routing it to the right cracking configuration. The documentation site at noraj.github.io/haiti covers both usage styles, and the README's screenshots of each mode confirm the intended ergonomics.
Installation is deliberately boring in the best way. The primary path is a single gem command: gem install haiti-hash. Note that the gem name differs from the repo name, a small gotcha the README handles by pointing at the installation page for additional methods including Docker, Debian, and openSUSE packages. The repology badge aggregates distribution coverage, which tells you this is a maintained project that upstream packagers have picked up — a meaningful maturity signal for a tool you might want present on a standardized assessment image. Continuous integration is visible via the ruby.yml workflow badge on the master branch, along with a commit-activity badge suggesting steady upkeep.
Where does haiti fit in an authorized workflow? The honest answer is: at the very start of the credential-analysis phase. When an assessor with written permission recovers password hashes from a client's own authentication store, the first bottleneck is format identification — proprietary and legacy applications emit exotic digest schemes, and misidentifying them wastes cycles. haiti resolves that ambiguity, then hands off its hashcat/John the Ripper references so the subsequent strength-audit of those credentials uses the correct mode. This is also a defensive exercise in disguise: password-cracking audits are how organizations discover their own weak-credential exposure, and accurate hash classification is a prerequisite for that measurement.
The README's comparison section is a rare piece of candor. Rather than merely asserting superiority, the author links to a documentation page explaining why haiti was created and includes a comparison table against competing identifiers. For a tool in this niche — where alternatives like hashID and hash-identifier have historically gone stale — the maintenance story matters more than raw feature counts. The 675+ type database and support for post-2015 algorithms like SHA3 and Blake2 are the concrete evidence that the database has not fossilized. When evaluating any identifier, the failure mode to watch for is confidently misclassifying an unknown modern digest as a legacy format; a current database is the mitigation.
From a defensive analyst's perspective, haiti deserves a place on the blue side of the board too. Incident responders handling a credential-store exposure need to know exactly which algorithms were in use to assess real-world crackability — a leaked Argon2 corpus and a leaked NTLM corpus imply very different risk narratives for the incident report. Because haiti is offline and passive, running digests through it leaks nothing and changes nothing, making it safe to use during evidence triage on isolated copies. The tool classifies; it does not crack, does not reach out to any external service, and leaves no footprint beyond shell history.
Operationally, treat haiti as infrastructure rather than a one-shot trick. Because it is a Ruby gem with a documented library API, teams can pin it in a tooling bundle and call it programmatically whenever their pipelines encounter an unidentified digest format — for example, normalizing hash formats across multi-tenant lab data. The hacktoberfest topic and the Rawsec Inventory listing suggest an active, community-visible project, which improves the odds that newly published algorithms get added to the detection set rather than sitting in an issue queue. The hackable claim implies the hash database is data-driven rather than hardcoded logic, though the README leaves the extension mechanism to the documentation site.
Limitations are inherent to the problem domain and worth stating plainly. Hash identification is heuristic: many algorithms produce identical-length hexadecimal output, so haiti necessarily returns ranked candidates rather than a single verdict. A 32-character hex string might be MD5, an NTLM digest, or half a SHA256 truncation, and only context — where the hash came from, what stored it — disambiguates. Senior operators treat the tool's output as a shortlist to be confirmed against the source system's documentation or configuration, not as ground truth. The hashcat/John the Ripper references attached to each candidate make that confirmation loop fast, since a wrong guess fails quickly and cheaply.
In sum, noraj/haiti is a small tool with an outsized leverage point in the credential-audit chain. It converts an ambiguous artifact — an opaque digest string — into actionable metadata: probable algorithm, hashcat mode, John the Ripper format. It is maintained, packaged across distributions, documented beyond its README, and dual-purposed as CLI and library. For authorized pentesters, CTF players, and defenders alike, it removes the tedious, error-prone first step of hash analysis. Install it with gem install haiti-hash, keep it in your assessment image, and let it do the classification grunt work your cracking rig should never have to guess at.
noraj/haiti.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.