Jump to content

01:B1:70:FF

Members
  • Posts

    2
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

01:B1:70:FF's Achievements

Newbie

Newbie (1/14)

  1. Thanks for the reply, Telot! In looking further at the files I saved and parsed from that day, I saw, from one of my pineapple sessions, 12 unique MACs that were listed in mgmt::auth lines in the karma.log file, but I had only 5 clients listed in my dhcp.leases file. In contrast, in parsing out MACs for probe requests in the karma.log file, I came up with 44 unique MACs. Airodump-ng had well over a hundred client MACs listed in some of the recorded scans, though I think I saw some data there that didn't look quite so reliable. Obvious MACs that wouldn't count would include 00:00:00:00:00:00, and it looked like some were very similar in their info. Counting the airodump log I saved that had the nearest time stamp to the dhcp.leases and karma.log files, I counted 85 total clients, and 38 clients who looked like they were probing for open networks. Of course, the larger portion of those were looking for the local wifi essid. Fortunately, that was an open network. I used an app on my tablet called Fing, and did periodic ping sweeps of the subnet we were on via the local wifi. By the end of the day, I had collected 123 unique IP/MACs, though some could have been in completely different sections of the site than my pineapple could see. As to the phone, that does help explain some of what I was seeing, because when I watched my phone try and re-associate, it seemed to insist on the same BSSID it had previously associated with. On the other hand, my tablet is an HP Touchpad running CyanogenMod 9 Alpha (ICS), and I have a pretty good track record of getting it pineappled with a little coaxing from airdrop-ng. I wish I was better at reading the 'story' from karma.log. For instance, is it saying something bad about what happened in a probe request when it says KARMA ssid malloc'd so free it? I'd like to figure out better what is happening when I see things like a bunch of probe requests before I ever see an auth and association. Also, I'd appreciate knowing better what's happening that makes the pineapple only work with clients trying to associate with open networks. I've read this other places in the forums, and was a bit confused. I thought Jasager would say yes to most any probe request and invite them in. Is it that the client sees the connection going open when it expected some encryption or security, and decides not to trust it? By the way, in case you're interested, the name basically is "1 bit off" spelled as the last part of a MAC address, so you can call me 1 bit, or whatever. Mr. MAC works, too! Thanks again for the response and additional information.
  2. Hello, everyone! I've been working with my Pineapple, and have a few questions. But first, here's what I have for a setup: Hardware: Fon 2100 Firmware: Mark III, version 2.1.2 Host: Laptop running BackTrack 5 R1 Network: eth0: 172.16.42.42 Wlan0: Alfa AWUS 036H in monitor mode wlan1: Onboard atheros chipset connecting to internet, we'll say 192.168.1.x Pineapple address: 172.16.42.1 I've flashed a fresh firmware on it, and the only changes I've made since then are: Changed the root password, of course Changed the SSID in the wireless config The pineapple pings ok. In fact, the pineapple "pineapples" ok, meaning I can get 'guests' on it. It just doesn't fill up with 'guests' like the screenshots Darren posts. I was in a target-rich environment last week, and could only get about a dozen guests, even with the help of some deauth fun via airdrop-ng on my Alfa. Looking at what airodump-ng said was around me indicated that I had somewhere around 10 times that amount of machines that could have potentially been "pineappled". I've also done a fair amount of work in a 'test' environment, where I try my hand at getting my tablet and phone to "climb aboard" the pineapple. I see that they are on the local wifi, so I run airdrop for a little bit. I can see on the devices that both of them are getting deauth'ed ok. When I let them try and reconnect, I have pretty good luck getting my tablet to associate with the pineapple, but my phone (an HTC Rezound) will not associate with the pineapple at all. Looking at the karma log file, here's what I see: KARMA CTRL_IFACE Requested ESSID is TCwifi KARMA: Probe Request from <phone MAC> for SSID <ssid> KARMA ssid malloc'd so free it With the tablet, I will see that set of logs several times, and then eventually see the mgmt::auth line along with the other lines that log the association with the pineapple. But I never see an auth or association for my phone. And not just my phone, the vast majority of the "buddies" I could have made were showing the same thing. I saw a lot of different MAC addresses show those three log lines of the probe request, but for whatever reason, they never went ahead and tried to associate with the pineapple. I should note that both the phone and the tablet indicated a stronger signal from the pineapple than from the wifi they requested association to. I'm just running karma on the pineapple, and leaving the other work to BackTrack, be it deauth, packet capture, etc. I plan to be in another target-rich environment in a few days, and hope to have a much better run at "helping" guests with their connection to the internet. Any suggestions on what I could be doing better, or other log files I need to look in (filename and location), or even how to understand better what these log messages mean in karma.log? Thank you very much for any help with this.
×
×
  • Create New...