Better Laptop Option?

Usually you just download an ISO image, which is usually what's referred to as a "hybrid ISO". Just copy this image straight to the flash drive, and I don't mean copy it into the filesystem, I mean write it to the block device itself, not a partition or file system (the image file itself contains the partitions and filesystems needed, as it is a binary image). some people like to use

dd if=somelinux.iso of=/dev/sdx
, but I find just using

cp somelinux.iso /dev/sdx
more elegant and there's really not much difference, dd isn't really any more low level than cp ... do note that when I say

/dev/sdx
the x may be any letter, depending on what block devices are installed in your system .... do check with

fdisk -l
(need superuser privilages for this) to find out which device filename is the usb drive and make sure you are writing to the correct device (or else disaster will quickly ensue and you will most likely get pissed and want to break things if you happen to corrupt some other hard drive.)

you can also do tail -f /var/log/dmesg, and when you plug in the flash drive you will see it show up in the logs.

There are tools that can do this from windows, you'd have to google it because I don't remember the names of the tools, but you can also usually burn the same image to a CD or DVD and boot from that, although the loading and install will be slower, due to the fact that reading from CDs is a lot slower than a flash drive, but with the CD you don't have the problem of needing linux to make a linux bootable USB drive.

The ubuntu website (and pretty much all linux distros) are well documented and have manuals and instructions on how to install, but if you do it as I said you will most likely not have problems. I also recommend using a USB 2 flash drive, not a USB 3 drive, as some computers have issues with USB 3, especially booting from them (and then you have some computers that have trouble booting from usb at all because the BIOS doesn't support it properly, in that case you have to use a CD/DVD)

If you have trouble, go into BIOS/UEFI setup, disable "secure boot", and change the boot order of devices, or override to make it load from the USB stick before trying other devices. If you still have trouble try fiddling with the secure boot CxE option if it's available. And if you have any more trouble than that I suggest taking the offending hardware outback and putting a few .40 rounds through it

usually it's ESC before post, or F2, and sometimes DEL to enter firmware setup program, and usually another key like F9 to show boot menu of devices to boot from ... but this varies depending on the hardware/firmware of the particular computer, but it should be in the computers manual ... usually I can figure it out by hitting all those keys in rapid succession at POST to "bruteforce it" so to speak if it's a computer that I don't know.

The cool thing about "live" operating systems, is that you can plug it into any computer and boot from it ... especially useful when using computers that aren't yours and don't particularly trust or think may be security compromised or malware infested, keyloggers etc.

Linux can read any filesytem, microsoft ntfs, apple HPFS+, and the many many linux/unix filesystems, but it's interesting that windows and macs can't read linux filesystems, and in fact windows cant read Mac OSX filesystems, and MacOSX can't read Windows filesystems but linux can read anything (meaning a USB drive formatted with a linux filesystem won't even show up when plugged into a windows computer, and they won't see anything at all , but vFAT is the most portable filesystem that every operating system supports, but it isn't a particular good filesystem besides being the most portable.

 

and then go download RUFUS and it will create a bootable usb from the iso
https://rufus.akeo.ie/
and it works with many different iso, windows and linux....scroll to the bottom of the page for a list/links

 

kali linux even has a feature that you can configure where if someone tries too many failed password attempts to unlock the encrypted volume, it overwrites the LUKS header, that is if someone tries to bruteforce or run dictionary attacks against your password to break into the encrypted volume, it nukes it rendering it dead, like rigor mortus, habeas corpus

And good luck cracking an 80+ character password ... most attackers would probably try bruteforcing the password thinking it's probably far easier than the actual encryption key which is basically an act of futility, but I do believe 127^80 > 2^256 ... so you'd have better luck just bruteforcing the key ... which means trying 115792089237316195423570985008687907853269984665 possible keys ... so ... good luck, but do feel free to die trying

 

I was gonna say the same thing...."do die trying...."

 

More than likely the cause of death will be old age ...

:sZbiH-<tnL;o'A}N9!QI8A+u;ky&TC2l:EPgy>IVX<]Rls^!Hp=(UaMvmFNL=zo1?*h*oa\QrN0{,S,

you won't be able to bruteforce that, i promise. I don't care who you are or how much computing power you have.

that's 127^80 ... or

2015104980786931900164137821000068589311716573932559816640324348245990754955110382457924801499622974027960030934714446797808099131920119657609094828582247942160278476801

possible passwords to try ... it'd only take a couple trillion years or so to compute all of those and hash them

 

No, thanks....

will not bother with that.......

LOL

 

yes it's a very big number, something of the order of the number of hydrogen atoms in the universe ... so finding the correct password is like picking hydrogen atoms at random out of all the hydrogen atoms in the universe and finding one specific one ... like a needle in a very large haystack, except the needle isn't a needle rather just another piecee of hay that looks like any other piece of hay.

 

and if by chance the password is found for that will it uncover all of the secrets of the universe?

 

The universe would probably die from heat death, all starts die, all black holes evaportate ... subatomic particles rip apart ... before then.

Of course you already now the password, I posted it ... but it's just an example, That password has never been generated before, and will never be generated again no matter how many times the program is run (probability is asymptotically approaching 0) ... well maybe if you run the program a googolplex number of times or something, then maybe you might get the same number twice, but that would take probably at least trillions of years, or maybe a googol years

googolplex" 1010^100 ... and that number is so long that it wouldn't fit on this page, not even close.

 

Did you figure out that number or is that somewhere written in abook? See, I don't even know that. I never said i had any computing power......only my instincts......they compute enough for me than to figure out codes and numbers....no force required.....

 

I didn't actually take the time to calculate how long it would take to run the program that many times. It takes about 1 millisecond (actually a bit less probabaly, milliseconds is the smallest unit of time I calculated the run time as, which is 1/1000 of a second) to generate that password, so maybe we could assume that it would take a googolplex milliseconds to run that many times, which is far longer than the universe has existed! There simply isn't enough time ... and with numbers that large, a few orders of magnitude really don't make much difference at all.

wikipedia: googolplex.

 

Well, at least you now know that i think you are smart enough where you could have figured that out.....Take that as a compliment.

 

I'm really actually pretty bad at math ... that's what happens when you don't study math for 8 years. I made a mental note to never let my math skills slack again

 

I don't really understand brute-force attacks but Can you explain in layman terms why this would be an impossible password to brute-force?

Like I understand why it would be difficult to guess if you had to cycle through every character each time in the same sort of process, but it's difficult for me to imagine that there are not programs out there that could parse the integers, translate the letters and symbols to numerical data, gather that info and reduce a lot of the process that would be done if cycling through each character.

 

I'm not sure how layman I can make it, but I'll try.

It's not impossible, given enough time ANY password can be bruteforced. A 4-5 character password can be bruteforced in a matter of seconds on a fast machine. Anything more than 7 or 8 characters though and it quickly becomes infeasible, because the amount of time needed to try all possible combinations of characters for a password of length n grows exponentially as as n increases. That is, the number of possible passwords grows exponentially as the length increases. The number above from the post you quoted is actually incorrect, I was using the full ASCII character set, but if we restrict that to only printable non-whitespace characters, i.e no spaces or control characters like ESC or backspace, etc ... we have 95 possible characters in each position in the password string. Note: that math above that you quoted was actually incorrect, as I was considering the full ascii character set including non printable control characters, which are unlikely (but technically could possibly be used) to be used in a password string ... but with something that long it really doesn't make a whole lot of difference, if you have a number with 100 zeros after it, knocking of three or four zeros (i.e. the number is about 1,000 times smaller) you are still pretty much screwed.

The printable character set is this: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

This is the most laymans definition I think that will be most understandable to most people, the paragraph below here:

So if we have a password that is only a single character long, it could be any one of the characters above, meaning that there are 95 possible passwords. We can simply try each of those characters, eventually one that we try will be the correct password. If our password is two characters long we would 95^2 possible passwords, that is 95 squared possibilities for passwords of length 2. So you could try for example, aa, ab, ac, ad ... ba, bb, bc, bd ... ca, cb, cc, cd ... you get the picture. So we can say that if we have a symbol set of s possible symbols, that for a string of length n symbols long there are s^n possible combinations.

Now we don't necessarily know how long the password is, so we would have to try all possible one character passwords, then two character passwords, three, four, etc increasing the length until we either crack it or run out of time to continue. If the password can't be cracked in a few days then most people will give up. This function is really a summation of the series {s^1 ... s^max} .. max being the maximum length after which we give up knowing damn well that past that length it will never be cracked in a reasonable length of time.

How many passwords can you try per second? It depends on how fast your machine is, my CPU can generate and hash many million passwords per second, but for an 8 character password, if we know the length is 8 there are 95^8 possible combinations of characters, which is 6,634,204,312,890,625. Let's assume that my machine can generate and hash 10,000,000 passwords per second (which is reasonable for a fairly poweful CPU, computers are fast. it would take 663,420,431 seconds to try that many; that is 7,841 days, which is approximately 21 years!! Making the length longer by only one more character would make it take 95 times as long, so a 9 character password would take about 1,995 years! If you had 1,000 computers, or a compute cluster with the computing power of 1000 times my PC working on it you might could bruteforce a 9 character password in about 2 years. And it only gets worse as the lenght increases and after a certain length all the computing power in the world wouldn't be enough to crack it in anything close to as short as the human lifespan. Keep in mind it's worth if we don't know the length, because we would have to try short passwords first, and if that fails increase the length up to some maximum length or amount of time spent and then give up. 8 and 9 character passwords are still considered weak, especially if they are composed of dictionary words ... 16+ characters and you're pretty much outta there no matter how much computing power you have, maybe someone like the NSA with supercomputers that can try billions of passwords per second it might be feasible but would still take time, and that's if they devote every bit of their computing power to cracking ONE password; and I guarantee the 80 character random string that I gave as an example, that even they would have "much trouble" cracking it before the sun dies out.

Bruteforcing is the last thing you would want to try, because it will almost never be feasible in a reasonable amount of time unless the password is trivially short, like less than 5 or 6 characters is about the limit or else you will be truly waiting forever. Most attackers would try dictionary attacks, using a list of words, trying each word in the list, or possibly permuting words according to some common type of permutation rules (word mangling), as the number of words in the dictionary is far less than the number of possible character combinations. If that fails, then try a bruteforce attack as the last resort but the chances of being successful are slim if it can't be cracked with dictionary attacks and such.

A very simple password cracker might be something like this (i had to write this as part of a problem set for a class I took) ... there are much more sophisticated password cracking tools out there (trying permutations of words, appending/prepending digits to dicitonary words etc, like some people choose a word and add a number at the end, like "SlutBitch69" ), but they will still be ineffective against something truly random and extremely long, since it will still have to resort to a bruteforce attack as there are no dictionary words at all and any that occur in something that long is pure coincidence, and irrelevant due to it's length:

#define _XOPEN_SOURCE

#define SYMTAB_SIZE (0177 - 041)
#define PASS_MAX_LEN 8
#define SALT_LEN 2

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <stdbool.h>
#include <assert.h>
#include <ctype.h>

void symtab_init(char *symtab);
bool dictionary_attack(const char *path);
void bruteforce_attack(int max_len);
void bruteforce_helper(char *s, int len, int pos);
bool hash_try(char *attempt);
void crack_exit(int ret);

char symtab[SYMTAB_SIZE];
char *salt = NULL;
char *hash = NULL;

int main(int argc, char *argv[])
{
const char *dictionary_path = "/usr/share/dict/words"; // path to wordlist file, i.e dictionary

if (argc != 2) {
fprintf(stderr, "Usage: %s SALTEDHASH\n", argv[0]);
return 1;
} else if (strlen(argv[1]) <= 2) {
fprintf(stderr, "E: salted hash is too short\n");
return 1;
}

// allocate memory for salt and hash
if (!(salt = (char *) malloc(sizeof(char) * (SALT_LEN + 1))))
exit(EXIT_FAILURE);

if (!(hash = (char *) malloc(sizeof(char) * strlen(argv[1]) + 1)))
exit(EXIT_FAILURE);

// copy salt and salted hash to global memory
strcpy(hash, argv[1]);
strncpy(salt, argv[1], SALT_LEN);

// initialize symbol table
symtab_init(symtab);

/**
* Try using a dictionary attack first, since this is much faster for
* passwords that happen to occur in the dictionary. If unsuccessful,
* then proceed to attempt a brute force attack on the password.
*/
if (dictionary_attack(dictionary_path))
crack_exit(0);
else
bruteforce_attack(PASS_MAX_LEN);

// free memory
if (salt)
free(salt);
if (hash)
free(hash);

return 0;
}

/* Initialize symtab by filling with all printable characters, in reverse
* order as they appear on an ASCII table. I am making the assumption that
* lowercase characters are probably the most common characters to appear in
* a password, and that passwords are more likely to begin with a lowercase
* character. This might help speed things up quite a bit in that case.
*/
void symtab_init(char *symtab)
{
for (char *endp = symtab + SYMTAB_SIZE, c = '~'; symtab < endp; symtab++)
*symtab = c--;
}

/**
* Attempts a dictionary attack against the salted hash, using the dictionary
* file in "path"
*/
bool dictionary_attack(const char *path)
{
// string to hold current attempt
char s[PASS_MAX_LEN + 1] = "\0";
FILE *fp = fopen(path, "r");

if (!fp) {
fprintf(stderr, "E: couldn't open %s\n", path);
return false;
}

// read from dictionary
int c;
while ((c = fgetc(fp)) != EOF) {
// if whitespace, this means end of word in dictionary
if (isspace(c)) {
if (hash_try(s)) {
printf("%s\n", s);

// close file and return true to indicate success
fclose(fp);
return true;
}

// make empty string
strcpy(s, "\0");
} else {
// make a new null terminated string to hold c, so we can use strcat
char append[2];
memset(append, '\0', 2);
append[0] = c;

// append to s
strcat(s, append);
}
}

// dictionary attack unsuccessful, close file and return false
fclose(fp);
return false;
}

/**
* Attempts a bruteforce attack against a salted hash.
*/
void bruteforce_attack(int max_len)
{
// string to hold current attempt
char s[PASS_MAX_LEN + 1];

// set string completely empty
memset(s, '\0', PASS_MAX_LEN + 1);

// generate passwords of length 1 up to max_len
for (int i = 1; i <= max_len; ++i) {
// begin with an empty string on each iteration
strcpy(s, "\0");
bruteforce_helper(s, i, 0);
}
}

/**
* Generates all possible passwords of length len
* Takes 3 arguments, the string to append to, the length of password
* in which to try all possible permutations of, and the character
* positon to start at. If the password is found it is printed on standard
* output and the program is exited.
*/
void bruteforce_helper(char *s, int len, int pos)
{
// target password length reached
if (len < 1) {
if (hash_try(s)) {
printf("%s\n", s);
crack_exit(0);
}
return;
}

for (int i =0; i < SYMTAB_SIZE; ++i) {
// change characters in s at current position
s[pos] = symtab;
bruteforce_helper(s, len - 1, pos + 1);
}
}

/**
* Tries hashing a password attempt. Returns true if it matches the target
* hash, false otherwise.
*/
bool hash_try(char *attempt)
{
return (strcmp(hash, crypt(attempt, salt)) == 0);
}

/**
* Cleans up memory pointed to by global variables and exits the program,
* returning ret as exit status
*/
void crack_exit(int ret)
{
// these pointers should never point to NULL at this point
assert(salt);
free(salt);
assert(hash);
free(hash);

exit(ret);
}
A pseudorandom password though has no predictable pattern and won't be in any dictionary, so you would be forced to use a bruteforce approach. If you don't underrstand the code, you might be able to get a pretty good idea of what it does by reading the comments.

I can't really explain salts, and hashes here ... not in layman's terms. You can wikipedia those terms for more info, but do be warned that it get's academic very quickly, as it is cryptography and tons of math. In essence though, the password string is hashed using a hash function such as SHA-256, and then a random "SALT is generated and prepended to the hash". This ensures that two users that happen to use the same password will not have the same hash, and knowing the hash of user 1 will not allow you to access to user 2's account even if they both used the same password (basically a defense against rainbow table attacks). The password isn't actually stored in the database, the output of the hash function is much longer e.g 2^256, which is a truly huge number, and much much harder to bruteforce than most passwords, the only way to verify the password is correct is to hash a password, and compare it's hash to what's stored in the database. If they match, the password is correct, if they don't then the password was incorrect.

TLDR:

Sorry if this was really really long, I don't think it's too easy to explain it shortly in laymans terms except just simply saying "bruteforcing is trying all possible passwords, or keys until we stumble upon the correct one by chance" It's worth noting that we might be extremely lucky and the first password we try turns out to be correct, but it is highly unlikely, statistically the password or key will be likely found about halfway through the possible keyspace, so you may reasonable cut the expected time in half, but with such huge amounts of time, cutting it in half doesn't make it that much better (think 10 milllion years versus 20 million years), and this is only statistically, the correct password might actually be the very last possible password out of all possible passwords, meaning that you would truly have to try every single one of them (if we happen to be extremely unlucky).

edit: if you find any repeated explanations of the same thing, its probably cause I was a bit barred out and probably forgot that I had already explained that part already. and feel free to check out my github repo link in my sig, one of the programs in there is the program used to generate that huge password, if you might want to take a peek at how it makes passwords like (it's actually a pretty simple program to use, and has a lot of options, letting you select character classes, add prefixes, and include/exclude specific characters ... of course it comes with docs and a help option showing you all the commands it accepts and what they do.

 

It depends on what dictionary you choose, there are lots of password dictionaries out there, and yes, many of them include misspellings and such. I have a dictionary that's 256MB after compression, when you decompress it it blows up. I'm not sure how many words are in there, but there's a lot. Another one I have is 4.5GB compressed ... and includes many more words, and stuff that might be machine generated using word mangling rules like chaging o's to 0's and stuff like that, as well as number sequences and such. Multiple words are harder, as this is basically exponentiation, you would have to try dictionary word one, try appending all words in the dictionary to that first word, if that fails go on to second word, now append all words in the dictionary to that one, and so on and so forth ... this quickly becomes basically a bruteforce attack as it is "exponential" so to speak.

Comment: dictionary attacks are not bruteforce attacks. bruteforcing literally means trying EVERY possible password. Dictionary attacks are intended to avoid this by only trying the most likely passwords to save time.

And yes, this definitely adds more hay to the stack, the bigger the dictionary, the closer the time is going to be to a bruteforce attack. But if you have a dictionary with a couple trillion words, that's still far more efficient than bruteforcing even though a truly huge dictionary might still take quite some significant time.

If it's not in the dictionary then you're probably not gonna be able to bruteforce it in a reasonable time.

this is a good TLDR ... generating passwords takes time, and hashing passwords take a lot of math which takes time.
Computers can crunch math very quickly, but doing it trillions of trillions of times ... well, start counting in your head to a trillion and let me know when you've finished

 

But we count much slower than computers, I think that's the part I have difficulty with when understanding these number scales. It seems so automatic for most the functional calculations on a computer program, however I did try a really large exponent function and I got an output that's unintelligible to me.

document.write(Math.pow(420, 34));

The output...


1.5505146482685425e+89

 

that's 1.55 * 10^89 ... 155 followed by 87 zeros (roughly, the less significant figures probably don't make a huge difference in how "large" of a number it is), scientific notation basically. the only way to represent truly large floating point numbers. beware of floating point imprecision ... and overflows. a cpu data type might only be 64 bits wide, floating point registers are sometimes 80 bits wide, they store numbers like that as a mantissa and exponent, so there is a degree of imprecision; you must sacrifice precision in order to store such a large range of values in a finite sized number of bits. It uses some number of bits for the fractional part, and some number of bits for the exponent part ...

https://en.wikipedia.org/wiki/Floating_point

those microseconds DO add up ....

try Math.pow(x, (1.0 / 34.0)) ... basically the 34th root ... you will probably get a number close to one, but with a lot figures, though doing the calculation in reverse may not give you precisely what you started with.

or you could try a negative exponent .... in which case you would end up with an extremely small number, but still with a lot of zeros. it takes just as many bits to store the number 2 in an "int" (usually 32 bits) as it does to store 2,000,000 ... it takes 32 bits of memory whether the number is small or not, just a lot of the leading bits will be zeros.