Repository navigation
Releases: Cynosureprime/procrule
Release list
v1.36
procrule release notes
v1.36
-u works again, as an alias for -8
v1.35 removed -u outright, so procrule -u exited with
procrule: invalid option -- u and every script, alias and job file carrying
it stopped. Both spellings are now accepted and mean exactly the same thing,
so a run written against either side of that change works.
-8 is still the spelling to use, and the reason is unchanged: mdxfind -8
selects the same engine there, because mdxfind -u already loads a userid
file and could never have carried this meaning. One letter, one meaning, in
both tools.
-u is kept rather than restored as the primary. procrule has no userid file,
so the letter is free and there is nothing for it to collide with — keeping it
costs nothing and breaking it cost everyone with a -u in a job file.
If you have been carrying a -u, nothing needs to change. If you are writing
something new, write -8.
Nothing else changed
The rule engines, the dispatch between them, discovery and the output format
are untouched. The whole source change is the option parse: one character in
each of the two getopt strings, a fall-through case label, and the help text.
A byte-mode run and a -8 run produce exactly what v1.35 produced.
Documentation
procrule(1) documents the alias inside the -8 entry, naming -8 as the
spelling to prefer and -u as kept for scripts written against v1.30 and
earlier. SYNOPSIS still shows -8 alone, deliberately. mdxfind(1) has
dropped its claim that procrule spells this switch -8: that was written
against procrule v1.30, where it was -u, and it told the reader to type
something the binary of the day rejected.
v1.35
Correct usage() against the options it describes -8 said "Replaces the former -u", which documents what was rather than what is; the rename belongs in RELEASE_NOTES.md and nowhere else. -L said "Implies -u" and -G said "Honours -u", both naming a flag that now exits with "invalid option -- u". And -A was described as keeping a candidate equal to its input and an empty candidate, when it emits a MARKER in place of the absent line, and has five of them rather than the two the text named. The -A entry now names :SAME, :EMPTY, :REJECT, :BADRULE and :NEG, and states the property that makes the option worth having: both engines report the same marker for the same outcome, which is what lets a byte stream and a -8 stream be diffed line for line. No functional change, fprintf text only. Every option the optstring accepts now appears in the help, and nothing appears that it does not accept.
v1.30
Discovery output could not be checked, ranked, or survive a kill -l was never connected to discovery: Linefile appears nowhere in run_discovery, so -G wrote an empty audit file however it was driven. Without word:rule:result a discovered rule cannot be verified, and truncate and extract rules reach short targets from almost any long base word. Both discovery workers now emit audit records in the normal-mode format, including $HEX[] on the word. -s carried bare rule names, so a rule matching 500 times looked like one matching once; a real run produced 48,816 rules at 1.04 matches each. It now leads with the count, and marks rules whose matches came from a non-ASCII base word. -o stays bare, because it is fed back to procrule and hashcat and must remain a valid rule file. -H previously filtered only Phase 2 chains and now applies to Phase 1 singles as well. Progress meters wrote a carriage return with no newline unconditionally, which in a redirected log is one very long line burying the summaries. They are suppressed unless stderr is a terminal; -q forces quiet. -r was accepted with -G and silently ignored, which is how someone concludes a seed rule set was tested when it was not. It now warns. A run killed after Phase 1 lost everything, since all output was written at completion. SIGINT and SIGTERM now set a flag the workers check, so partial results are written through the normal path. An interrupt during Phase 2 preserved 969,473 rules and 1,988,367 audit records. -C restricts the catalog by rule class, reusing the existing CatalogValid mechanism. -Z dumps the catalog with class and validity and needs no inputs, separating "rule absent" from "engine did not match". The UTF-32 engine refused any rule using a literal double quote, reading it as an operand that opens and never closes. That was the whole of its divergence from the byte engine: 138 of the 17,320 catalog rules. The compiler now asks the parser twice, once with quoted operands and, only on failure, once with quotes as plain characters. All 17,182 previously valid rules produce byte identical output, and the two engines now agree at 17,320. ruleproc.c takes the 61 opcode defines from rule_ops.h rather than keeping a second copy.
v1.28
Define Neon here: procrule's link has no other definition
procrule.c declared
extern int Neon;
and nothing in procrule's link defines it. The only definition is in mdxfind.c,
which is a different program. Every non-ARM build compiled the reference out,
so it linked everywhere and the gap stayed invisible until the release began
passing a real ARM value rather than a bare -DARM.
AArch64 was safe too: get32_init selects get32_neon64 first and get32_neon32
is never compiled there. It is 32-bit ARM at ARM >= 7 that needs the symbol,
and it failed with an undefined reference to Neon at link.
Defining it and leaving it zero would not be enough. Neon gates the NEON hex
decoder at runtime, so a bare definition links and then always picks
get32_scalar -- a silent no-op of exactly the kind this file was corrected for
one revision ago. get32 is a lazy-init function pointer, so the probe sits in
get32_init immediately before the choice it feeds: no change to main, and it
cannot run too late.
The probe reads Features from /proc/cpuinfo and looks for neon or simd, the
same test mdxfind makes. These are static binaries run on whatever board turns
out to be present, so asking the kernel beats trusting the -march they were
built with. A missing or unreadable /proc/cpuinfo answers no, which costs speed
and not correctness -- get32_scalar decodes the same bytes.
Verified on arm-linux-gnueabihf: armv6, armv7 and armv8 32-bit all compile and
link, where armv7 and armv8 previously failed at link. armv7 and armv8 grow
from 228K to 584K, which is the NEON path now actually being built. Intel is
unchanged and the 1.27 known-answer tests still pass.
v1.26
Discovery (-G) now honours -u phase1_worker, discover_worker and the catalog validation all called the byte engine directly, so procrule -u -G searched in byte terms regardless. That is worse than no benefit: it reports zero rules, which cannot be told apart from no rule existing. A word and its grapheme-correct reversal in vocalised Arabic found nothing either way, though the rule that explains it exists and the engine can run it. All three sites now branch, and the rule catalog is validated by whichever compiler will execute it -- the two accept and refuse different sets. A locale-ambiguous rule counts as a hit if any of its variants reaches the target. That case now yields seven rules, each verified; ASCII discovery is unchanged. The usage text was also missing six options -- u, L, M, p, B and V. Every getopt letter is now listed.
v1.22a
v1.20
v1.16
Fix SSSE3 get32: unsigned long → uint64_t for Windows x64 (LLP64) compatibility.
On Windows x64, unsigned long is 4 bytes (LLP64) vs 8 bytes on Linux/macOS (LP64). This caused the SSE hex decoder to produce corrupted output for $HEX[] encoded input on Windows.
Bug found by @Blazer.
