I want to search for all letters and some special characters at the same time
?ludhHs?ludhHs?ludhHs?ludhHs?ludhHs?ludhHs?ludhHs?ludhHs?lludhHs
Something like this for a 9 Letter password with all characters. Does this work?
It sounds like you want to use the built-in charset ?a, which is a shortcut for ?l?u?d?s.
Try out this command:
hashcat -a 3 -m 0 your.hash ?a?a?a?a?a?a?a?a?a
Don't forget to swap out the mode and hash file for whatever you are cracking.
If you really were trying to use a custom charset with ?l and the characters udhHs, that's mostly redundant since ?l is already all the lowercase letters, but here's an example for that custom charset:
hashcat -a 3 -1 ?ludhHs -m 0 your.hash ?1?1?1?1?1?1?1?1?1
Related
I have a text file containing unwanted null characters (ASCII NUL, \0). When I try to view it in vi I see ^# symbols, interleaved in normal text. How can I:
Identify which lines in the file contain null characters? I have tried grepping for \0 and \x0, but this did not work.
Remove the null characters? Running strings on the file cleaned it up, but I'm just wondering if this is the best way?
I’d use tr:
tr < file-with-nulls -d '\000' > file-without-nulls
If you are wondering if input redirection in the middle of the command arguments works, it does. Most shells will recognize and deal with I/O redirection (<, >, …) anywhere in the command line, actually.
Use the following sed command for removing the null characters in a file.
sed -i 's/\x0//g' null.txt
this solution edits the file in place, important if the file is still being used. passing -i'ext' creates a backup of the original file with 'ext' suffix added.
A large number of unwanted NUL characters, say one every other byte, indicates that the file is encoded in UTF-16 and that you should use iconv to convert it to UTF-8.
I discovered the following, which prints out which lines, if any, have null characters:
perl -ne '/\000/ and print;' file-with-nulls
Also, an octal dump can tell you if there are nulls:
od file-with-nulls | grep ' 000'
If the lines in the file end with \r\n\000 then what works is to delete the \n\000 then replace the \r with \n.
tr -d '\n\000' <infile | tr '\r' '\n' >outfile
Here is example how to remove NULL characters using ex (in-place):
ex -s +"%s/\%x00//g" -cwq nulls.txt
and for multiple files:
ex -s +'bufdo!%s/\%x00//g' -cxa *.txt
For recursivity, you may use globbing option **/*.txt (if it is supported by your shell).
Useful for scripting since sed and its -i parameter is a non-standard BSD extension.
See also: How to check if the file is a binary file and read all the files which are not?
I used:
recode UTF-16..UTF-8 <filename>
to get rid of zeroes in file.
I faced the same error with:
import codecs as cd
f=cd.open(filePath,'r','ISO-8859-1')
I solved the problem by changing the encoding to utf-16
f=cd.open(filePath,'r','utf-16')
Remove trailing null character at the end of a PDF file using PHP, . This is independent of OS
This script uses PHP to remove a trailing NULL value at the end of a binary file, solving a crashing issue that was triggered by the NULL value. You can edit this script to remove all NULL characters, but seeing it done once will help you understand how this works.
Backstory
We were receiving PDF's from a 3rd party that we needed to upload to our system using a PDF library. In the files being sent to us, there was a null value that was sometimes being appended to the PDF file. When our system processed these files, files that had the trailing NULL value caused the system to crash.
Originally we were using sed but sed behaves differently on Macs and Linux machines. We needed a platform independent method to extract the trailing null value. Php was the best option. Also, it was a PHP application so it made sense :)
This script performs the following operation:
Take the binary file, convert it to HEX (binary files don't like exploding by new lines or carriage returns), explode the string using carriage return as the delimiter, pop the last member of the array if the value is null, implode the array using carriage return, process the file.
//In this case we are getting the file as a string from another application.
// We use this line to get a sample bad file.
$fd = file_get_contents($filename);
//We trim leading and tailing whitespace and convert the string into hex
$bin2hex = trim(bin2hex($fd));
//We create an array using carriage return as the delminiter
$bin2hex_ex = explode('0d0a', $bin2hex);
//look at the last element. if the last element is equal to 00 we pop it off
$end = end($bin2hex_ex);
if($end === '00') {
array_pop($bin2hex_ex);
}
//we implode the array using carriage return as the glue
$bin2hex = implode('0d0a', $bin2hex_ex);
//the new string no longer has the null character at the EOF
$fd = hex2bin($bin2hex);
I publish to a lot of channels with binary names. The names look like [binary_data]:[text data]. Sometimes I would like to subscribe to the channel as follows:
PSUBSCRIBE [binary data]:*
In this case if binary data contains an asterisk the matching can deliver unexpected results. Is there a way to escape the asterisk character in this circumstances?
Use \ with the asterisk (or question mark, or any other special char) you want to escape.
From the psubscribe docs:
Use \ to escape special characters if you want to match them verbatim.
my perl version on linux server is :
This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi
I have a test as below.
echo "mac:abcdefg1234" | grep -Po "(?<=mac:).*(?=\d+)"
The result is abcdefg123.
But the greedy match does not work.The result I want is abcdefg.
How can I get the content between "mac:" and "digital" (as many as is allowed)
(?<=mac:)[^\d]*(?=\d+) thats the content beetween.
[^\d]* means all not digital with length >=0. Typing a ^ after [ negates the character class. The result is that the character class matches any character that is not in the character class. It also match (invisible) line break characters.
For Ruby, using 2 spaces is the best.
For Python, using 4 spaces is the best.
But for ssh config file, how many spaces is the best?
I found the originally accepted answer a bit confusing so I thought I'd contribute some additional information.
To the original question, ssh config files allow, but do not require, indentation with whitespace (either tabs or spaces). Blank lines and lines beginning with a hash # are ignored.
The config file consists of stanzas, each beginning with the reserved word Host or Match followed by a list of options until the stanza ends at the next Host, Match or end of file.
The options can be specified as name value or name=value. Looking at the OpenSSH release notes, it appears the developers use the name=value format. Leading whitespace is ignored. Unquoted in-line whitespace is also ignored
The following (mixing with and without equals and whitespace) are equivalent
Host test1
Hostname = 192.168.0.100
Host test1
Hostname 192.168.0.100
Host=test1
Hostname 192.168.0.100
Note that the equal sign is significant when parsing options. Values with embedded equals signs need to be quoted. This contrived example demonstrates what happens without quotes.
Host test1
Hostname = 192.168.0.100
UserKnownHostsFile /tmp/name_with=equals /tmp/name2
Will look for known host in /tmp/name_with and in /tmp/name2 but not in /tmp/name_with=equals.
The configuration files (for ssh or other programs) do not need indentation.
They contain lines of type name=value.
Some programs allow spaces around the equal sign, others are more strict and do not accept them.
ssh accepts spaces around the equal sign but they are ignored. Use how many of them you like but don't abuse them and let the file be readable.
A small fragment from the documentation:
The file contains keyword-argument pairs, one per line. Lines starting with # and empty lines are interpreted as comments. Arguments may optionally be enclosed in double quotes (") in order to represent arguments containing spaces. Configuration options may be separated by whitespace or optional whitespace and exactly one =; the latter format is useful to avoid the need to quote whitespace when specifying configuration options using the ssh, scp, and sftp -o option.
We are using crontab to schedule jobs and it was not picking the files for processing that have [ or ] or ¿ . Is there any limitation in giving file name or these characters means something in UNIX? Is there any other variables like these we shouldnt use in file name?? Thanks in advance.
Following are general rules for both Linux, and Unix (including *BSD) like systems:
All file names are case sensitive. So filename vivek.txt Vivek.txt VIVEK.txt all are three different files.
You can use upper and lowercase letters, numbers, "." (dot), and "_" (underscore) symbols.
You can use other special characters such as blank space, but they are hard to use and it is better to avoid them.
In short, filenames may contain any character except / (root directory), which is reserved as the separator between files and directories in a pathname. You cannot use the null character.
No need to use . (dot) in a filename. Some time dot improves readability of filenames.
And you can use dot based filename extension to identify file. For example:
.sh = Shell file
.tar.gz = Compressed archive
Most modern Linux and UNIX limit filename to 255 characters (255 bytes). However, some older version of UNIX system limits filenames to 14 characters only.
A filename must be unique inside its directory. For example, inside /home/vivek directory you cannot create a demo.txt file and demo.txt directory name. However, other directory may have files with the same names. For example, you can create demo.txt directory in /tmp.
Linux / UNIX: Reserved Characters And Words
Avoid using the following characters from appearing in file names:
/
>
<
|
:
&
Please note that Linux and UNIX allows white spaces, <, >, |, \, :, (, ), &, ;, as well as wildcards such as ? and *, to be quoted or escaped using \ symbol.
It will be good if you can avoid white spaces in your filename. It will make your scripting a lot more easier.
I got the answer from this link. I am just pasting it here so that this info will be available even if that website goes down.
The only characters that are actually illegal in *nix filenames are / (reserved as the directory separator) and NUL (because it's the C string terminator). Everything else is fair game, although various utilities may fail on certain characters - typically characters that have special meaning to the shell. These will need quoting or escaping to be handled correctly.