Stage 3: CowPatty
CowPatty Stage 3
Introduction:
Cowpatty being a tool that related to some of my interests I wanted to take a deeper look into how it works. At the start I understood the basics, feed it a 4-way handshake, SSID name and a dictionary file and it would spit out its best guess of the SSID. While Cowpatty has the ability to 'guess' the SSID's password, its only effective / used to audit networks that have poor / common / default passwords. Interestingly enough in this Defcon video titled "Weaponizing Your Pets: The War Kitteh and the Denial of Service Dog" - Provided he made his warkitteh sniff for packets and save them, he could attempt to hash SSID+handshake to get passcodes. He got quite the list of SSIDs, Some WEP which I dont think is a setting on new routers (hopefully). I do not condone Weaponizing you pets or strapping batteries to them, do not attempt. However, it was neat! Since CowPatty has to match keys it has to got through a large dictionary file and with that different overheads can begin to exist when applying operations to this data. Since CowPatty uses openssl sha1 hash, my first attempt to optimize Cowpatty will be to implement libkcapi's sha1sum hash within its coreutils lib.
Learning about Libkcapi:
First, I need to understand Libkcapi and figure out where and how it needs to be used. I checked out the Github, Libkcapi allows users to access the Linux kernal crypto API, with this performance could improve on different systems, Libkcapi "does not perform any memcpy for processing the cryptographic data. The library uses scatter / gather lists to eliminate the need for moving data around in memory."
These are the applications available within Libkcapi. I will be using coreutils - sha1sum. Thankfully the Github has a section on integration of libkcapi into other project, therefore my first step in this process will be integrating the files, getting it to compile and seeing if i can call a function from within Cowpatty.
Integration of Libkcapi
Im starting by installing libkcapi and running a test to ensure that I can actually use it and/or I have a bad version. I took a clone of the git and followed the steps for installation.
Then to I must test if it works, In the test package there is a script to do this. When I ran it, all passed! Looks like this is a good package, we will continue the integration. Looking online there isn't a lot of documentation of others doing / using it. Firstly, I need to know how to call the proper hash function, admitting this took my longer than I thought, I started at the testscript and tried to find where is was testing hashes
While it wasn't obvious where it was in the script I noticed this loop and the -c flag, with these variables in the command which mean its associated with type of hash + datasets. I knew I was on the right track, opening up kcapi.c and looking at the main -x flag only made me more confused. as It didn't call the function, it was setting up a struct then later going through sets of IF statements, most likely related to the other flags. Cntrl + F "sha1” - found me a great example of some commented out code of what to call.
Now I know of some sample data to feed from cow patty before I attempt to replace the OpenSSL call. Most of cowpatty's work happens in the function on the right, along with the openssl function call. Since I only have the command line call I'm abit stuck, My first thought is lets callgraph this execution out and see what happens!
This is good, while at first it looked crazy, I see something I should check out, a pbkdf function. Though countless hours of attempting and I’m bit unhappy with the result I couldn't find a way to call libkcapi successfully from within cow-patty. I both tried importing the C source + header files into my code then compiling and using shared libraries generated by running libkcapi ./configure with a specified path + desired tool. The issue I kept running into was when I had a call to a function supposedly set up. The error I would receive at compile time was usr/bin/Id: cannot find -libkcapi.
Looking into the usr/bin/ I could clearly see the shared library there libkcapi.so
Some comments said that it could be a link to a so.1, so by further reading I attempted to create a symbolic link to the libkcapi I created within the libkcapi folder. I’m disappointed I got beat by this boss, I’m not the most familiar with c however I figured I could figure it out in a reasonable amount of time. I will have to go with my backup plan of looking into the flags, while libkcapi was promising openssl is very optimized, changes would be small or even worse performance. Within the Q&A of the Gitrepo it states that "the OpenSSL SHA1 code is faster then the C and i386-assembler
implementations ".
Working with Compiler Flags:
Well, this is not the direction I wanted to go however we should see if its possible to get more performance by editing the compiler flags. The first method I will be using will be using profile guided optimization. One thing that I learned quickly is that Gcc and clang are very different. While on the surface they do the same thing, clang is much more optimized and lightweight. This maybe more optimized then I thought.
To start profile optimization, we will have to add this flag -fprofile-instr-generate to our compile command + I would also like to give -03 as well.
Once I run and collect some profiles, I must merge the data using the llvm-profdata merge function then feed the results to a flag specifying profile data -fprofile-instr-use=code.profdata.
Testing Takes awhile ...
Results of Creating Profiles on Each System:
By adding profile guided optimization, I reliably got a 1% change. While I tested with many different flags all results in no-change or larger ranging values. While I didn't get to go the route, I wanted to in optimize this program I learned a lot about how cowpatty works along with the associated libraries. Looking at the bench-marking results I got excited when the results from my VM began to roll in because the improvement is easier to see when were pushing more keys/sec so I was under the impression the change was larger. Cross platforms all have similar results
Another task I could have tried however I felt it was unfair would be testing / using a recent PR change to the makefile. While in small tests I saw no changes, I believe it was more restructuring + allowing RM functionality.
Conclusion
While my c skills are understandably sad I was able to erk out 1% changes by creating a profile. I learned all about trying to implement shared libraries, about libkcap, differences between clang vs GCC and vectorization in both compilers. Both because from the start I was learning / reading from the gcc docs, it didn’t help me much for clang. SPO600 has offered a great look into how things work at a lower level, coming with difficulty, its definitely interesting. Cowpatty being software widely distributed (packaged with backtrack + kali) , optimizations would happen a lot. My thoughts on closing this project and this final semester, it was too short, this semester was packed with the most interesting material.
Anyhow Happy Holiday’s! Off to snowy Muskoka I go!
Integration of Libkcapi
Im starting by installing libkcapi and running a test to ensure that I can actually use it and/or I have a bad version. I took a clone of the git and followed the steps for installation.
Then to I must test if it works, In the test package there is a script to do this. When I ran it, all passed! Looks like this is a good package, we will continue the integration. Looking online there isn't a lot of documentation of others doing / using it. Firstly, I need to know how to call the proper hash function, admitting this took my longer than I thought, I started at the testscript and tried to find where is was testing hashes
While it wasn't obvious where it was in the script I noticed this loop and the -c flag, with these variables in the command which mean its associated with type of hash + datasets. I knew I was on the right track, opening up kcapi.c and looking at the main -x flag only made me more confused. as It didn't call the function, it was setting up a struct then later going through sets of IF statements, most likely related to the other flags. Cntrl + F "sha1” - found me a great example of some commented out code of what to call.
Now I know of some sample data to feed from cow patty before I attempt to replace the OpenSSL call. Most of cowpatty's work happens in the function on the right, along with the openssl function call. Since I only have the command line call I'm abit stuck, My first thought is lets callgraph this execution out and see what happens!
This is good, while at first it looked crazy, I see something I should check out, a pbkdf function. Though countless hours of attempting and I’m bit unhappy with the result I couldn't find a way to call libkcapi successfully from within cow-patty. I both tried importing the C source + header files into my code then compiling and using shared libraries generated by running libkcapi ./configure with a specified path + desired tool. The issue I kept running into was when I had a call to a function supposedly set up. The error I would receive at compile time was usr/bin/Id: cannot find -libkcapi.
Looking into the usr/bin/ I could clearly see the shared library there libkcapi.so
Some comments said that it could be a link to a so.1, so by further reading I attempted to create a symbolic link to the libkcapi I created within the libkcapi folder. I’m disappointed I got beat by this boss, I’m not the most familiar with c however I figured I could figure it out in a reasonable amount of time. I will have to go with my backup plan of looking into the flags, while libkcapi was promising openssl is very optimized, changes would be small or even worse performance. Within the Q&A of the Gitrepo it states that "the OpenSSL SHA1 code is faster then the C and i386-assembler
implementations ".
Working with Compiler Flags:
Well, this is not the direction I wanted to go however we should see if its possible to get more performance by editing the compiler flags. The first method I will be using will be using profile guided optimization. One thing that I learned quickly is that Gcc and clang are very different. While on the surface they do the same thing, clang is much more optimized and lightweight. This maybe more optimized then I thought.
To start profile optimization, we will have to add this flag -fprofile-instr-generate to our compile command + I would also like to give -03 as well.
Once I run and collect some profiles, I must merge the data using the llvm-profdata merge function then feed the results to a flag specifying profile data -fprofile-instr-use=code.profdata.
Testing Takes awhile ...
Results of Creating Profiles on Each System:
By adding profile guided optimization, I reliably got a 1% change. While I tested with many different flags all results in no-change or larger ranging values. While I didn't get to go the route, I wanted to in optimize this program I learned a lot about how cowpatty works along with the associated libraries. Looking at the bench-marking results I got excited when the results from my VM began to roll in because the improvement is easier to see when were pushing more keys/sec so I was under the impression the change was larger. Cross platforms all have similar results
Another task I could have tried however I felt it was unfair would be testing / using a recent PR change to the makefile. While in small tests I saw no changes, I believe it was more restructuring + allowing RM functionality.
Conclusion
While my c skills are understandably sad I was able to erk out 1% changes by creating a profile. I learned all about trying to implement shared libraries, about libkcap, differences between clang vs GCC and vectorization in both compilers. Both because from the start I was learning / reading from the gcc docs, it didn’t help me much for clang. SPO600 has offered a great look into how things work at a lower level, coming with difficulty, its definitely interesting. Cowpatty being software widely distributed (packaged with backtrack + kali) , optimizations would happen a lot. My thoughts on closing this project and this final semester, it was too short, this semester was packed with the most interesting material.
Anyhow Happy Holiday’s! Off to snowy Muskoka I go!
Comments
Post a Comment