Jason Cooper

Active Members
  • Content count

    504
  • Joined

  • Last visited

  • Days Won

    8

About Jason Cooper

  • Rank
    Hak5 Pirate
  • Birthday

Contact Methods

  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Great Britain
  • Interests
    Cards,
    Computers,
    Cryptography,
    Hacking,
    Lock Picking,
    Programming,
    And many more
  1. Try #/bin/bash # references the interface wlaninterface=wlan0mon # sets the base file name for the wireless survey recon=scouted # sets the file name for the pcap file to write too pcapfile=DaCapFile # sets the lenth of time to run the survey for - in seconds recontime=30s # sets the lenth of time to run the packet capture for - in seconds capturetime=600s # general house cleaning to remove previous captures rm $recon*.csv &> /dev/null rm $pcapfile*.cap &> /dev/null # setting wlan0 into monitor mode airmon-ng check kill airmon-ng start wlan0 # running the wireless survey airodump-ng -w $recon --output-format csv $wlaninterface &> /dev/null & sleep $recontime kill $! # finds the open WiFi network with the most active traffic and get the channel number channel=$(grep -a 'OPN' $recon*.csv | sort -nrk11 | tail -1 | awk '{print $6}') # removes the comma from the output of the previous line ch=${channel::-1} #finds the open WiFi network with the most active traffic and get the ESSID network=$(grep -a 'OPN' $recon*.csv | sort -nrk11 | tail -1 | awk '{print $19}') # removes the comma from the output of the previous line ssid=${network::-1} #running the packet capture airodump-ng -c $ch --essid $ssid -w $pcapfile --output-format pcap $wlaninterface &> /dev/null & sleep $capturetime kill $! The only change made is that I've moved the house clearing and survey parts so that they run before the you process the survey results. I suspect that in your earlier testing you had an old recon file present which it then used and as the script leaves the recon file on the filesystem at the end you'd only encounter the issue when you moved the script across but not the recon file. The good news is that this bug actually highlighted a logic bug that would be very difficult to spot otherwise (the logic bug was that each time it ran it was using the recon file from the previous time you ran the script not this time, which if you've changed locations wouldn't be much use).
  2. I assume that when you say that it's an array of strings you have something like var messages=[ "message 1", "message 2", "message 3" ]; If it is then the chances are that it's not so much an error caused by the missing semi-colon as a string containing an unescaped quote that's terminating the string too early. I don't think a debugger would help much as it is an error at the compiling stage. Have you tried running jshint against the code? It may narrow down the error a bit more. If jshint doesn't help you track down the source of the problem you could always fall back on a good old binary search to find the source of your problem. Simply comment out the first half of your strings in the array and see if it the error goes away, if it does you know the error is in the first 7,000 strings, if it doesn't you know it's in the last 7,000 strings. Then repeat the process on the block of 7,000 strings with the error in to narrow it down to 3,500 strings, repeat again to narrow it down to 1,750 strings, and keep going till you've narrowed it down to a number of strings that you can actually look at manually.
  3. If you're combining awk, sed and cut together and you're planning on using the code in the long term then you'd probably want to be considering moving over to a Perl or Python script instead for that part, as it will be easier to maintain. I'm not sure on the exact layout of your CSV file, but something like the following might produce the result you're after (you'll probably have to tune the field numbers being used to extract the $bssid and $ivs variables). #!/usr/bin/perl use strict; use warnings; my $maxIVs; my $maxBSSID; while (my $line=<STDIN>) { my @field = split /\s*,\s*/, $line; my $bssid = $field[0]; my $ivs = $field[10]; if (!$maxIVs || $ivs > $maxIVs) { $maxBSSID = $bssid; $maxIVs = $ivs; } } print "$maxBSSID"; If you make the script executable then you can use it in a bash script to populate a variable (you would probably want to change the path to match wherever you put the script). TARGET_BSSID=`./maxIV < test.csv`
  4. Try using ! instead of % to delay the expression evaluation. @echo off setlocal EnableDelayedExpansion FOR %%Z IN (SDESK1 SDESK2 SDESK3 SDESK4) DO ( set UserID=%%Z echo !UserID! )
  5. you need to stop CMD from expanding the environment variables too early (i.e. before %%Z is populated by the for loop) try adding this before the for loop Setlocal EnableDelayedExpansion
  6. Are they acting as routers or switches? If they're acting as routers then you could connect to one and use traceroute to your main router's IP and see what IP's it goes through. You could also fire up wireshark and see what packets are being passed about.
  7. Best advice when first learning to code is to set yourself simple goals. Too many people try to learn to code by tackling a complex problem, but you really need to learn the basic concepts before tackling anything complex. Try creating python scripts to do each of the following: display a message ("hello world" is very common one) accept some input from the keyboard and display a message with it in (perhaps ask the users name then display a hello message to them e.g. "Hello Fred") count from 1 to 10 (e.g. "1 2 3 4 5 6 7 8 9 10") accept two numbers from the keyboard and then output their total accept as many numbers from the keyboard until the user enters something that isn't a number and then display their total accept as many numbers from the keyboard until the user enters something that isn't a number and then display their average
  8. You should always consider what would happen if a function/statement failed, both from a security point of view and reliability point of view. Then you need to consider what the chances are that the function/statement will fail. For something like mysql_real_escape_string the impact of it failing is very high and the chance of it failing is probably average. Having made this judgement then you look to see if there is a better way (hint, read up on paramaterized queries).
  9. Two questions that I would start with: Does it have a documented API available that you can use? If it doesn't have a documented API then walk away, or you'll spend more time on maintaining any thing you get working with the system than you would save. What do you commonly do that you think could be automated? If you're continually making identical actions against the system then perhaps automating those actions will save you some time. Do you have system report that you then have to open new cases for, or do you regularly have to go in and change the state of cases that haven't been updated for a set period?
  10. Most password hashes stored in a database will be using a standard hashing algorithm (SHA-512, SHA-256, MD5, etc. Note MD5 should be considered a poor choice these days) and will either indicate it in the hash some how. for example in a Linux shadow passwd file hashes starting with $1$ are using MD5, those starting with $5$ are SHA-256 and those starting with $6$ are SHA-512. Failing the hashes indicating what they are then the next logical place to look would be the source code, finding the line that says hash=sha256(password+salt); is much easier and quicker than trying to figure it out from a plaintext/ciphertext comparisons. This leads onto the question of why would developers make it so easy for you to identify the hash being used, the answer is simply that it shouldn't matter that you know what type of hash is being used. The algorithm isn't the secret part, the password is. If the password it too simple or short then the hashing algorithm used is irrelevant as it will quickly be brute forced. On the other hand, if the password is long and complex enough then cracking it would take too long, even with knowledge of the hash, salt and and hashing algorithm. Once the need to keep the algorithm used secret is dismissed as worthless, then actually indicating the type of algorithm used gives the developers power to respond to issues that arise. E.g. If an algorithm is becoming a security concern then you can add a modern hashing algorithm to be used when setting new passwords and keep the old algorithm for verifying older accounts, effectively phasing out the old algorithm over time. You could even update the users hash to new algorithm then next time they successfully login.
  11. (Note any figures in this post aren't exact, the're just approximations) That's correct. A plaintext and hash look up table can take up a lot of room as each hash will be 128bits (md5) or 256bits (sha256) in size. That would result in your look up table for md5 taking up about 50GB and the sha256 version taking up about 100GB. These days this sort of storage size id available on SSD's so you could create a very fast look up table your word list, now back when rainbow tables were popular storage space was a lot smaller, and 50GB was a significant amount of space to sacrifice for a simple look up table. Now consider what would happen if instead of just your word list you wanted to cover 90% of possible 8 character passwords consisting of numbers, uppercase and lowercase letters? Well for an md5 you'd be looking at 3,000TB or space requirement and for sha256 you'd need about 6,000TB, even with today's storage surplus we can't get near to that (government agencies probably have the resources, but your average technical person won't). With a rainbow table you can set your chain length to be something your computer can calculate in a set period, let's we can calculate a chain with a length of 1,000,000 in a minute, so we choose a chain length of 1,000,000. Now the rainbow table will only need to store an one entry for every 1,000,000 hashes. This brings our space requirements for md5 down to a tiny 3GB and sha256 down to 6GB at the expense of taking up to one minute per hash being cracked. The initial state is simply that when using a rainbow table to crack a hash you need to know what value to start your hash chain with. The wikipedia entry for rainbow tables is a good place to start. As to where to start, I would suggest that initially you look at creating a simple password hash pair lookup table and try it with subsets of your dictionary. Once you've got that done you have a good understanding of the limitations and then you can revisit rainbow tables.
  12. To add to the other Cooper's answer, here's the basic theory of rainbow tables: Seed your current hash with a known value. for 1 to X { Store the current hash in the rainbow table for 1 to Y { Generate a password from the current hash Hash the password and set the result to be the current hash. } } Store the current hash in the rainbow table The X value controls the number of hash chains you want to include in your rainbow table and the Y value controls the lengths of those hash chains. To decrypt a hash with the final rainbow table you take the hash, generate a password from it and then calculate that password's hash. If this new hash isn't present in your rainbow table then repeat the process. Keep repeat untill you either get a hit in your rainbow table or you have repeated it more than Y times. If you've repeated the process more than Y times then you haven't got the password in your rainbow table. Assuming that you got a hit from your rainbow table then you simply take the previous entry to the one you found in your hash table and start the process of generating passwords from the hash, and then a hash from the password. As each hash is generated you compare it against the hash you want to decrypt and when you hit it you'll have the password that generated it. As you can see rainbow tables are very different to a precomputed hash value look up table. The rainbow table takes up less space but at the cost of having to do more calculations when decrypting a hash value. Now the real issue here is that both rainbow tables and a precomputed hash value look up table are only worth anything if the hash doesn't include salt (or only includes very small quantities of salt). A salt is simply a random value that is stored with the hash and used to alter the way the password is hashed (e.g. added to the end of the password before hashing). If a salt is used you would need to precompute every hash + salt combinations. Note every bit of salt added doubles the number of the hashes you would need to precompute and store, so even a small about of salt can render precomputation impractical. Are rainbow tables completely worthless these days? No, but once you've generated ones for the usual hashes without salts (md5, sha1, sha256, etc.) then you're done, and I suspect you will rarely use them.