Documents: Added docs/limits.txt

docs/changes.txt

@@ -34,8 +34,10 @@
 ## Technical
 ##
 
-- Changed the way large strings are handled/truncated within the event buffer if they are too large to fit
-- Fixed our use of strtok_r () calls
+- Documents: Added docs/limits.txt
+- Files: Switched back to relative current working directory on windows to workaround problems with unicode characters
+- Hash Parser: Changed the way large strings are handled/truncated within the event buffer if they are too large to fit
+- Hash Parser: Fixed our use of strtok_r () calls
 
 * changes v4.0.0 -> v4.0.1:
 

docs/limits.txt

@@ -0,0 +1,72 @@
+##
+## Maximum password lengths vary depending on kernel, hash type, and encoding
+##
+
+See https://hashcat.net/faq/lengths
+
+##
+## Generic hash modes only support salt lengths up to 256
+##
+
+This limitation on salt lengths only affects generic hash modes, such as md5(pass.salt).
+
+Dedicated hash modes allow unlimited salt length support.
+
+##
+## File and folder names including UTF-16 characters are not supported
+##
+
+UTF-16 is mostly seen on Windows. UTF-8 (as mostly used on Linux and macOS) are fine.
+
+Important: That does not mean UTF-16 file content, which is fully supported. 
+
+It only means the filename itself.
+
+##
+## The use of --keep-guessing eventually skips reporting duplicate passwords
+##
+
+This does not mean that valid passwords are skipped; they are always reported.
+
+Only if you hit the same password twice for the same hash the password may be shown only once.
+
+If --keep-guessing is not used, this can not occur.
+
+This limitation cannot be fixed, because it would require too much device (GPU/CPU) memory.
+
+If we wanted to report back all possible password candidates executed in a single kernel invocation, it would require this much memory:
+
+Number-of-MCU * Max-threads-per-device * Max-accel * Max-inner-loops * sizeof (plain_t)
+
+For example, on a Vega64: 64 * 512 * 1024 * 1024 * 20 = 687,194,767,360 bytes
+
+##
+## Hashcat GPU memory usage may be limited by maximum allocation sizes of OpenCL drivers
+##
+
+Most hashcat hash modes only use a single OpenCL allocation. 
+
+The size of this allocation is limited by GPU drivers / OpenCL runtimes. 
+
+Only a few modes (like scrypt) make more than one allocation.
+
+##
+## The maximum number of functions per rule is limited to 31
+##
+
+This makes the size of one rule 128 byte. 
+
+On the other hand, there is a 25% OpenCL single allocation memory limit.
+
+A typical GPU of today has 8GB = 2GB/128 = 16M rules max
+
+If hashcat supported more functions per rule, it would be limited to fewer rules. 
+
+This is a trade-off game.
+
+##
+## Position identifiers in rules are limited to 36
+##
+
+The upper limit of maximum 36 positions for various rule functions (0-9, A-Z) was a design decision by the original authors of the rule engine.
+