Jump to content


Active Members
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Skinny

  1. I knew that WiFi implementations were different from manufacturer to manufacturer but yesterday I got to see it at the packet level. The question I wanted to answer was the following: After a device send outs a probe request or a broadcast, how long does the Pineapple have to send an SSID the device is looking for? Round 1: The first experiment was carried out with a Motorola Moto E tracfone. The phone's preferred network list (PNL) was preloaded with 4 common SSIDs. The pineapple had about 200 SSIDs in it's list. PineAP was running. Initially, I turned on all of PineAPs options to force the phone to connect, but after sifting through the packets, I noticed that before the Pineapple had broadcast the phone's intended SSID, the phone had already connected to the Pineapple. Going back, I did the experiment again but this time just checked Allow Associations (No Broadcast SSID or Beacon Response). The packets showed that all the phone did was send out a probe request to everyone with the SSID it was looking for. With only the Allow Association option checked, the Pineapple sent back a Probe Response validating that it was that SSID. The association followed. Classically, this is how the Pineapple is supposed to work. ANS 1) So in these cases, the pineapple is always watching for and will respond immediately to a probe request with an SSID tagged along with it. Even if the pineapple is in the middle of broadcasting a huge list of SSIDs, it will stop and service this probe request with a matching SSID to ensnare the client. Round 2: The second experiment was carried out using an Amazon Kindle Fire (the cheap model). In this case Allow Associations was not enough to cause an association because the Fire did not broadcast out a probe request with an SSID but just a probe request with a Broadcast. It was asking for all the other APs to respond with their SSID. It was performing a roll call. I'm told this is the reason Beacon Response was created, so I turned it on without activating Broadcast SSID. In hindsight, this was silly, because Beacon Response can not respond if you aren't allowing SSIDs to be broadcast in the first place. The result was that nothing was sent out, so nothing happened. For kicks though, I flipped it around and turned on Broadcast SSID but did not allow Beacon Response. The results were interesting. The Fire finally saw the SSID it was looking for and sent a Probe Request directed at the Pineapple. The Pineapple responded with a Probe Response, but then the Fire never took it further. After waiting awhile, the Fire sent out the same Probe Request but it refused to authenticate to the Pineapple. It was as if the Fire didn't believe the Pineapple to be it's true AP. As soon as Beacon Response was activated, things changed quickly. After the initial Probe Request from the Fire, the Pineapple absolutely hammered the Fire was probe responses. There were hundreds of repeat responses. This overwhelming onslaught convinced the Fire that this was the correct AP. The Fire authenticated. ANS 2) Unlike the Motorola, the Fire responded only after seeing the SSID it was interested in. Another interesting tidbit is that the Fire has a broadcast interval of 10s. This is pretty short, so it would preclude me from being able to find out if the Fire would react to a pineapple responding 45s after a broadcast. As it is, response times came just seconds after a request. Conclusion More testing is needed but I can see from just these two devices what the outcome will probably be. Since each manufacturer has its own way to implement WiFi, there will most likely be a range of responses. You'll probably have devices that will respond to the pineapple because they are always listening for a probe request and others, in an effort to save battery, that may only listen in certain intervals. The way forward for me will be to look back over my archive and see what devices are more common in the environments I've been encountering and learn how those devices operate under test conditions. At least now I know how to run the test.
  2. Results from Yesterday's Questions Here's a followup from yesterday. My setup for this experiment was screwed up. Everything is corrected now. The Pineapple broadcasts SSIDs in the following order. Names starting with: 1) Special Characters 2) Numbers 3) Capital letters 4) Lower-case letters The rate of broadcast is also a bit more encouraging than yesterday. I get roughly 175 SSIDs per second in the Normal interval mode. It looks as though I am receiving every Beacon frame from the Pineapple. I know this because there is no random nature to the SSIDs being broadcast. Everything is being received as outlined above. So if you have an SSID bank of 3000 names, it will take appoximately 17 seconds to broadcast everything on the list. The Low interval came in at about 115 SSIDs per second and the Aggressive was a blistering 275 per second. Why Does Any of This Matter? Lets say you are targeting a specific mobile device. That device will send out a probe request once every 30 seconds to 20 minutes depending on the device. My hypothesis is that when that request goes out, you have a certain amount of time to respond. If the list of SSIDs is too large, I think you might miss that window. Therefore, there would be a certain list size that is optimal that will be based on the amount of time devices are willing to wait for a response. Of course, I could be wrong. I may find out that many devices are always listening, therefore it wouldn't matter when you responded with the correct SSID. Intuitively though, this feels wrong because my daily experience tells me that most devices seem to finally attach to the Pineapple during or in sequence with their probe request interval. Next Steps For my next trick I'm hoping to see if I can experimentally identify the longest time a range of devices is willing to wait for a probe response. I'll let you know how it goes.
  3. I'm doing a bit of research using Wireshark to examine the behavior of the Tetra in different modes of operation. I'm getting results, but I don't trust that my equipment is reacting fast enough to the packets being broadcast. Can anyone tell me the rate at which the broadcast packets occur (number / sec) when the Pool Interval is set to Normal and the order the SSIDs are broadcast. With my Wireshark capture it indicates a rate of roughly 40 packets per second. Also, from the packet capture it looks as though the SSIDs start out broadcasting alphabetically, but as the capture progresses, SSIDs begin to get broadcast more randomly. The randomness is what makes me think I'm not seeing everything. If I'm not seeing everything, this brings up a bigger question. Can the devices being targeted in the wild keep up with all those broadcasts? Would it be better to start slowing down the Pool Interval for a more productive chance at snagging a targeted client? All fun things I hope to explore. Edit: If you're curious about the other two settings, I'm currently getting 7 to 10 SSIDs broadcast per second at the low interval and approximately 100 per second at Aggressive.
  4. @cruzr77 Windows 10 can be a pain sometimes. I was having the same problem you were having earlier today. However, the problem you are having could be for a number of reasons. My solution is in the post below. Others have had similar issues with Windows 10 Internet Connection Sharing (ICS). As Seb pointed out though, be sure to check settings. Be exact.
  5. In the process of working with the Pineapple Nano this morning, Windows 10 had a nasty little oddity waiting for me with Internet Connection Sharing (ICS). I thought I'd make everyone aware of the strangeness and the solution. The Problem Windows 10 ICS would not allow the Pineapple to connect through my windows box. After repeated attempts at a solution, I found that Windows 10 was deceiving me. When I looked at the adapter settings, the IP address would appear as one thing and in the command terminal, it would appear as a completely different address. The Fix The fix to this is to first click the Advanced... button at the bottom right of the IPv4 Properties box. After clicking, it should look like this: Highlight the 192.168..... address and click remove. Next, click ok twice and close the IPv4 settings box. Finally, right click on the Ethernet adapter governing the Pineapple and disable the adapter. Then right click on it again and Enable the adapter. The correct IP address should stick and ICS should work once again. How Does this Happen? Whenever I have finished using the Pineapple on my Windows box, I always turn off ICS. For some reason if the Pineapple is plugged back in and you go through the ICS setup process again, windows seems to give you the IP it wants you to have for ICS and let you keep the IP address you specified earlier for the device. It's a bit strange. If you leave ICS on after using the Pineapple, upon reconnecting the Pineapple, everything seems to work fine. Anyway, I hope this proves to be helpful to someone. Have a great day!
  6. I haven't ordered it myself, but according to the specs, this should work. https://www.walmart.com/ip/StarTech.com-1-ft-USB-Y-Cable-for-External-Hard-Drive-Dual-USB-A-to-Micro-B/39206896?wmlspartner=wlpa&selectedSellerId=339&adid=22222222227027081108&wl0=&wl1=g&wl2=c&wl3=56165805849&wl4=pla-88834007769&wl5=9012116&wl6=&wl7=&wl8=&wl9=pla&wl10=111830352&wl11=online&wl12=39206896&wl13=&veh=sem
  7. I have my own small business (shameless plug www.skinnyrd.com). A lot of my classes are tailored for specific clients. In one of the latest there was a day of ubertooth and WiFi Pineapple. It was more of an introductory level module but each student got to keep both pieces of equipment. I love being able to give students relevant, useful hardware.
  8. I have both the Tetra and the Nano. I teach the Nano and also use it in my 9 to 5 on a daily basis. The Nano is highly reliable, easily hidden, and good with power. I stick with it because of it's small size and because normally I am walking around with a full kit of gear with very little room for anything else. The Tetra is also a good option. I use the Tetra when I really need to reach out and gather as many SSIDs as I can in a given area. The Tetra is larger with it's larger and antennas. Also, to run it in portably, you need a substantial battery or set of batteries. This makes for an even larger footprint. I use the SSIDs gathered from the Tetra to feed the Nano, so each have a specific purpose for me. With the new firmware update that just dropped, I'm looking forward to seeing the 5GHz support. Hope this helps you choose.
  9. Sweet! Thanks for all the hard Seb. I've already uploaded the firmware and have some work lined up for it today. Looking forward to playing with the 5GHz support.
  10. How are you powering the Tetra?
  11. The AP you spoof with the pineapple must be an open AP in order to get a device to connect. Spoofing an AP that is encrypted will not work because during the 4-way handshake authentication process, the client will find out that you are not the AP you say that you are. I am not aware of a way to circumvent this limitation.
  12. For a stubby it depends on how it's built but for 2.4GHz stubby antennas, it's most likely just a shorter wire under the plastic. A normal, omni-directional WiFi antenna would be about 60mm long. That means it's cut for 1/2 wavelength reception. A stubby is around 30mm. It's cut for 1/4 wavelength. All things being equal, you're better off with the 60mm length. As far as transmit/reception pattern, it would be the same as shown above.
  13. Just to clarify, do you have a Pineapple Nano or a Pineapple Mark V? The Nano doesn't have a proper RJ-45 Ethernet port.
  14. A basic omnidirectional antenna has the radiation pattern of a donut. At the tip and bottom of the antenna you lose reception/power, so never point the top or bottom of the antenna at the target. The best orientation for the antennas is the orientation that positions your target's radiated signal to hit the broad side of the antenna directly. The more the target signal hits at an angle, the weaker the reception. Likewise when transmitting information, the target should be directly 90 degrees off the side of the antenna for maximum transfer. So if you are trying to attack a target across the coffee shop and you've got the Tetra on the table, positioning the antennas at 90 degrees vertically is fine. If the target is a floor below or above, push them down to be parallel with the Tetra.
  15. You should be getting somewhere around 37.5 hours of runtime with a 15000mAh battery (15000mAh / 400mA = 37.5h). Likewise with a 4000mAh battery it should come out to 10 hours. The nano does fairly well with power but as you've seen, the accessories can really start to drain things. This is very much the case if you decided to tether a phone to the Nano. Be careful with pulling too much current from the pineapple juice battery. It's a decent little battery, but the nano operates right at its capability. It's trivial to accidentally pull the voltage down to less than 5V.
  16. So there are a few things that are different in a modern Apple device when associating. Most new Apple devices will not probe using the name of the SSIDs in the PNL. It instead will send out a probe request that will demand the APs in the area to send a response. Once the APs respond, the device then knows if there are any available networks that match its PNL. Apple is not the only company doing this. Because of this behavior it is often a good idea to have a list of regional based APs already in your Pineapple that have a high likelihood of attracting a devices. Now let's assume the Pineapple already has an SSID in its list that matches the devices PNL. Although I don't think you're having any of these issues, look out for these. Some phones have a setting that requires the user to manually accept any association even to a known AP. Also, some apple devices will not associate with an AP when it is idle (the screen is blacked out & locked). I have an iPod that will not associate with any AP when its idle even though it will continue to push out probe requests. As soon as the screen is unlocked, then it will auto connect. I've noticed some Samsung phone with similar functionality. One other piece that could be a problem is APs that have WPA2 activated. If there is an SSID in both the device's PNL and the Pineapple SSID broadcast list and the device has it marked in the PNL as a WPA2 encrypted AP, then the Pineapple will likely fail at attracting that device. WPA2 requires a 4-way handshake where both participants (AP and device) must prove their legitimacy to each other. The phone will realize that the AP is not legitimate and the association will likely fail. You mentioned that "even if it does not connect as it sees the same AP in PNL then it will use its own MAC." I don't doubt this is the case although I've never tested it as you have. I think the problem is that the Pineapple is setup to show you the MAC addresses of things that are genuinely connected to itself or probing for something else. If the device does not connect to the Pineapple but uses it's real MAC address in the attempt, there might not be a good way to pick up on that attempt via the GUI. The logging module just shows probe requests and successful associations. An attempted association is neither of those. There might be a way to see it in Recon mode, but I doubt it. I suspect, but am not sure, that recon mode is just using probe requests to enumerate the clients in an area and other packet types.
  17. I didn't do anything but download the updated app and follow the instructions. I've heard before that some mobile service providers can limit tethering, but I don't know the veracity of such claims because I just use the tablet for it's WiFi capability. It's never been connected to a cell network.
  18. When it comes to seeing the real MAC address of an unassociated, modern Apple device, it's really difficult. Every now and then I come across an Apple device that will beacon out it's true MAC for one rare beacon, then it will return to rolling its address. In those rare cases it often beacons out a few SSIDs at the same time. I suspect this might be an attempted associated with the pineapple. The problem is that is you're in a rich WiFi environment, it's hard to ferret out the MAC you are looking for from all of the other beacons in the environment. You might be wondering how to determine when a true MAC displays itself. If the MAC address is AA:BB:CC:12:34:56, AA:BB:CC denotes the manufacturer of the device. When the apple is rolling, I've never seen it roll in such a way to randomly display an Apple MAC address. It always resolves to nothing or to another manufacturer. When the true MAC appears, it always resolves to Apple. You can check those first 6 MAC digits here to check: http://aruljohn.com/mac.pl The only way I've found to collect the true MAC is to have the device associate with the Pineapple. Once the device is associated, it always uses it's true MAC. You can get that MAC from the client list or from the Logging module. Never forget the logging module. If you setup PineAP to log probes and associations, Logging will keep track of all the MAC addresses that are probing and the SSIDs they are probing for. As for why you might not being seeing the SSID list; sometimes when you do a great deal of adjustments to the Pineapple in a single session, things can get muddled. You will tell it to beacon out SSIDs, but it won't. If you find the Pineapple performing this way, simply give it a reboot. It happened to me not 15 minutes ago. After a quick restart, my phone was once again overloaded with APs to choose from.
  19. Sounds like a fun idea. I'd be interested to see how it turns out if anyone follows up.
  20. Allow association does allow phones to automatically connect to the Pineapple but there are many things at play. In order to see your phone beaconing for an SSID, it is not neccesary to have Allow Associations activated. Your phone will send out beacons as long as WiFi is enabled. A phone will generally send out a beacon every 30 seconds to 4 minutes. When running Recon mode to find a phone, make sure to use a time interval that will guarantee a capture of the beacon. Secondly, if you have an iPhone, the MAC address that is beaconed out may not be the MAC address of the device. Newer Apple products randomly roll their MAC addresses for security purposes. If this type of phone is unassociated, then you will rarely see the true MAC. Also, if just using Recon mode to find devices in an area, filtering doesn't really matter. Filtering only matters when targeting a specific MAC or SSID to allow or disallow a device. If you are just sniffing for unassociated clients, don't worry about it. Just a note about Allow Association; Allow Association allows a device to connect to your Pineapple's open AP. In the networking module, that AP is named something. As soon as you Allow Association, any device can connect using that APs real name. When you fully enable PineAP, you then have the ability to push out SSIDs (multiple AP names) that are apart of the pool you collected or manually inputted. When trying to get a device to latch onto the Pineapple, you'll want to be beaconing out some attractive SSIDs as well as having Allow Associations on. When everything is turned on in the PineAP module, then things can get interesting. Your phone could beacon out it's MAC address and the SSIDs it is looking for. The Pineapple will collect those SSIDs or trick the phone into giving them up. The Pineapple will then store those SSIDs in the pool. The next time your phone beacons, the Pineapple will replay those SSIDs in the pool order to tempt your phone in automatically connecting. At that point the phone is no longer unassociated.
  21. If you are powering the device from the AC adapter, plug one end (the small end) of the Y-adapter cable into the ETH port of the Tetra. Plug only 1 other end of the cable into the USB port on your computer. You want to plug in the USB connector where the two separate cables connect. It's the fatter of the two. That should do the trick. This configuration caused my Windows PC to see the Realtek adapter. Trying to power the Tetra from a computer will result in negative consequences. The Tetra is a power hog compared to the Nano. It requires either an AC adapter or both Y-adapters plugged into the Tetra with the 4 remaining ends connected to a substantial USB battery pack.
  22. No, but you still have the option of administering the Pineapple via the management AP using WiFi.
  23. Double check to make sure the cable you are using to attach the phone to the nano is a data cable. I have several cables that can only be used for charging. They will not pass data.
  24. If your 5dBi antennas are cut for the 2.4GHz range, then going with 3dBi antennas would be a definite step down for you. Your current 5dBi antennas are 1.6 times more powerful than 3dBi antennas would be. You do bring up a very valid point regarding the existing antennas. The antenna gain of the current nano antennas are not given (or I just haven't found it), so there is no way to quantify the actual gain you would be getting by going from the nano stock antennas to the 3dBi antennas. For example, if the current antennas have a gain of 1dBi, then $10 to purchase the 3dBi anennas would get you 1.6x more power. However, if the current antennas provide something like -3dBi, then you would get benefit from 4x power. Guess this is a question best left for the guys in charge.
  • Create New...