sud0nick

I didn't think I would get more done before the release of 2.3 but I did and here is the changelog for 2.4. I will try to put together an updated tutorial video since I added a significant new feature. [->] Added Injection Sets which can be created, exported, shared, and imported between Pineapple users. Inject Sets work like previous versions of Injections but are now modular and can be chosen when cloning a portal. [->] Fixed a bug with portals that use self-signed SSL certificates. Injection sets allow you to create multiple versions of the inject files and choose which set to use when cloning a portal. They can be exported and imported with ease so I encourage you to create your own custom login forms using the new interface, export, and share with everyone else. I may even create a separate thread strictly for sharing Injection Sets if the admins don't mind.

A+ is kind of a useless cert in my opinion. I haven't seen a single job posting that requires or even wants it. It mainly goes over computer hardware and the test is all about how to find the control panel (at least that's what I remember from a few years ago). It's really a waste of time. I do see a lot of companies requiring Security+ at a minimum though. Look into CBT Nuggets. They have some great videos that I've used for getting my MCP, MCITP, MCSA, and CEH. They won't help with the wording of some questions (which can get wonky) but they will definitely help you understand the material and how it applies to the real world. Edit: For some reason I thought you mentioned Security+ instead of Network+. Net+ is also a decent cert to have and I'm sure there are CBT Nuggets available for it.

As far as radio controlled quads go once it flies out of range of the transmitter the GPS will override its path and a new flight path will be taken back to the home location (speaking in terms of the NAZA-M V2 flight controller and the compass/GPS system that comes with it). Of course once the auto return feature has kicked in there is nothing to prevent a second spoofing attack from taking it right back off course again unless if the flight controller would possibly recognize the new coordinates are not the same as the home location. I'm not sure where it stores the coordinates of the home location and if those would be overwritten by a spoofing attack.

Is this after you set it up? Otherwise the solid green and flashing blue is probably from the setup test that verifies you own the Pineapple. When you go to http://172.16.42.1:1471 in your browser it should ask you for the current color sequence. If you have already done this then try resetting like Rkiver said.

Well I don't know how long it's going to take for the new version to be released but I assume the delay is due to Hack Across Europe. Since it hasn't been released yet I decided to make a few more changes. Here are the changes since the last changelog. [->] Added a tab for Auth Log to show captured credentials [->] The default Test Website has been changed to InfoTomb. The request is made via HTTPS unlike past requests. [->] Dependencies are now downloaded from InfoTomb, an anonymous file hosting site. All download sessions are SSL enabled and MD5 checksums are verified for every download. [->] Dependencies are no longer installed through setup scripts but instead are copied to /sd/depends/ making the installation process much faster. The size of each archive has also been reduced making the download time shorter. [->] The SSL version of wget is now installed via opkg if not already installed on the Pineapple. This is for downloading dependencies via HTTPS.

You should create a script to setup those symlinks otherwise when you update to a new firmware version it's all going to disappear (except for the stuff on the sd card).

You're not mistaken. It certainly does require you to create a new password.

It probably is a power issue. The wall wart I got with my Pineapple died randomly so I've been using one that puts out 12V 2A which is a little too much. It works just fine after about 10 minutes but when I first boot it up only the first 3 tiles load and all the others are blank. It kind of locks up for a couple minutes then I can use it.

I resubmitted v2.3 to the Pineapple Bar. Luckily I was able to get some more fixes worked in before it got approved. DataHead had an issue where CSS styles linked by @import statements were not being parsed so I added support for that. A couple other things were fixed as well. Here is the updated changelog. [->] Added CSS parsing when cloning a portal so images referenced in CSS files are downloaded. [->] Portals are now cloned significantly faster. [->] Dependencies are no longer installed through setup.py scripts but instead are copied to /sd/depends/ making the installation process much faster. [->] Fixed issue caused by reinstalling dependencies after updating PortalAuth. [->] Fixed issue with following relative URLs in meta refreshes [->] External JS files are now downloaded into the images directory and the link modified within the HTML EDIT: I almost forgot. When cloning a portal the site it first reaches out to is what you put in the Test Website field. I was able to successfully clone my personal website and it was (visually) an exact duplicate just modified to work with nodogsplash.

Pretty neat! Good job!

You should add the infusions one by one and check after each installation to see where the problem begins.

Your gut can fool you. At this point you have nothing to lose by trying a factory reset. Make sure you follow the instructions carefully.

I agree completely but I figured I would get some other opinions.

Yeah I've used wget many times before, and I even found the exact article where you copied this from lol. I remember looking into for PortalAuth when cloning was first brought up many pages back in this thread but I also remember coming across some specific reasons why I could not use it (although I can't remember them now). Regardless, I can make the Target URL the same as the one that the cloning script reaches out to and there should be no problems in cloning a page. By adding the use of wget the infusion would be taking an unnecessary extra step. Wget is only going to do for you what is already being done by the requests library in my cloning script. EDIT: I forgot you mentioned you wanted it to be used for DNSSpoof in which case it would make more sense to copy an entire site rather than doing what my cloning script does now. Since PortalAuth is meant for cloning portals to be presented with nodogsplash I'm wondering if this extra feature really belongs in PortalAuth or if it's beyond the scope of it as you stated before. What do you guys think? If you feel it belongs I can probably make it happen (after I'm done with my finals this week).

Right now the test server field is not the same as what the cloning script tries to reach out to. I can make it that way if you want but I think that my script is built more for portals which involve less content than a full website. I tried cloning my website once with it and I got an error that said the web server reset the connection so the clone failed.

You didn't need to uninstall PortalAuth. The dependencies are separate and after uninstalling you would see the Install Dependencies link in the small tile. For the server info you could maybe find a Google page that displays basic info but you would need to have the Expected Data field match exactly what the page returns otherwise Portal Auth will always think there is a captive portal present.

Open the large tile and in the config tab you should see a link at the bottom that says Uninstall Dependencies. One thing I've included in v2.3 is it attempts to do a full uninstall before installing depends so it can clean up. This will help when switching between versions and only one additional dependency is required. If you look in /sd/depends/bs4 you should not see a symlink labeled bs4. It has appeared when trying to install depends before when they already existed and has been causing problems. Since the installation process is quicker now you should be able to do this in less than 30 seconds. Let me know if you are still having trouble.

cheeto, I know you think that it would enter an endless loop before but what really happened is what I described above (read #2 in post #131). I know this because I have taken the time to test and prove it on the back end, not just look at the web interface and wait for it to respond. Also, like I've said before make sure you uninstall your depends before moving to a new test version. I looked at the errors you sent me and they are the same I ran into in testing and why I recommend uninstalling depends first. Once you uninstall and reinstall depends that error should disappear.

I'm not sure if anyone has tried cloning an xfinity portal with PortalAuth but I know people have manually done it before.

Another update: I was able to increase the speed at which images are downloaded. A newer test version has been posted on my site. EDIT: v2.3 has been submitted to the Pineapple Bar.

Here are a few updates. 1. A new test version is up on my site. I have added DataHead's request to parse associated CSS files and download the images. The script accounts for multiple images across multiple CSS files and updates the links in each to point to the new location. 2. I still need to work on downloading images faster. I have come to the conclusion that Cheeto's issue, where he states that the Pineapple becomes unresponsive is due to two problems. Problem one is that my script takes forever to download large images (they don't even have to be that large, something as small as 900kb can take a long time). The particular portal he was attempting to clone contains one very large image. The second problem that I have come across is trying to send a separate AJAX request while one is currently active; the system will not do it and there is no way to multithread in JavaScript. While the AJAX connection is open to clone the portal all other AJAX requests will be queued up waiting for the open one to close. Almost everything the Pineapple does through the web interface requires an AJAX request. This is why it appears to "lock up" but you can still SSH into it and run commands. This is still presenting an issue for me in creating a kill switch for the cloning process. In the mean time, if the cloning process appears unresponsive and you want to kill it simply SSH into your Pineapple and run the following command. kill $(ps | grep "python /sd/infusions/portalauth/includes/scripts/por" | awk '{print $1'}) This will stop the cloning process and log an error in PortalAuth stating it was terminated. 3. Another dependency has been added (python module tinycss) in order to parse CSS files. Along with that I have modified the dependency scripts to automatically install all dependencies in /sd/depends. My reasoning for this is in previous versions the depends were first installed internally and then could be moved to the sd card but if there wasn't enough internal space in the first place you were out of luck. Now there is no need to download then move, it is all done at once. Also, the time to install dependencies has been reduced greatly as I no longer run the setup.py script for each. I simply copy the module directories into /sd/depends/ then create a symlink in /usr/lib/python2.7/site-packages so they can be accessed from any script. Before installing the new test version please uninstall your dependencies, there is still a bug I'm working out there as well. As always if there are any problems please let me know.

Do you mean to connect to the network first and then sniff it? I have an AC router at home and my Pineapple connects to it easily but I think that's because it is backward compatible with n wireless-n networks.

In my opinion, those who demand infusions should make one themselves. I'm sure he will get to it when he has the time. If you're impatient then build it yourself and contribute to the community.

This doesn't make sense to me. Shouldn't any little change to the data change the value of the checksum?