Greetings all,
I have searched around for an answer without success so I thought I would post here to see if anyone may be able to point me in the right direction.
I have a need to develop an app for my research project, that has the ability to inspect and display the header information from an IP packet, recieved through the 802.11 wireless interface a PDA device. Bascially, I want to examine any packet 'sensed' (for the lack of a better word) by the RF interface and view the header info.
I have searched for managed code examples on how to obtain packets from an Windows Mobile inbuilt library's but have not found anything...
I am also looking at the OpenNETCF.org framework for any leads on how to achieve this..( & without sucess as well at present...)
If anyone has been down this path or has any advice I would appreaciate
it.
Many thanks
Cheers
Are you looking for capturing network packets or actual 802.11 frames.
Network traffic is less useful considering most AP's are network switches, and therefor the only network packets coming to your device will be directed at you and/or broadcast traffic.
Wireless frame sniffers on the other hand have the ability to collect all wireless activity in the area. These are useful when trying to find an open channel to put you AP on, but it can also be used to sniff the traffic of other wireless users on your network. Keep in mind though, that encrypted frames will require some extra processing power to read.
In pc land, you can play with Omnipeek to get an idea of the power of a wireless frame sniffer.
Hello guys,
I want to see how secure my wireless network is for someone who is using a PPC, so I have been searching for any software that will allow me to crack my encryption but so far I have not managed to find anything. I have found a few software that crack encryptions both on Windows and Linux, but none on Windows Mobile.
Any of you know any software?
Thank you.
evolish said:
Hello guys,
I want to see how secure my wireless network is for someone who is using a PPC, so I have been searching for any software that will allow me to crack my encryption but so far I have not managed to find anything. I have found a few software that crack encryptions both on Windows and Linux, but none on Windows Mobile.
Any of you know any software?
Thank you.
Click to expand...
Click to collapse
What a bizarre request If you've got a wireless network, set the router encryption to the strongest setting your PC's/PPC's will support and use the cracking tools on a Windows PC to test it. If you've got security and MAC filtering on the router, you're doing about the best you can anyway.
Trying to crack wireless security on a PPC is gonna be slow as - the Hermes only has a 400MHz processor, so it'll probably take four or five times (or more) longer to crack the security as it would if you did it on a desktop PC. The only software I know of that might work is MiniStumbler - kinda like the baby brother of NetStumbler, from http://www.netstumbler.org
My advice is this , give it up as a bad job, or make sure your PPC is permanently on charge coz the battery life will be crap with the WiFi on and packet capture/cracking tools running
Cheers,
Mark.
Great Mark I will try and see what happens with the software you told me as soon as I get a chance. Thank you.
Anyone else who knows a different way.. is welcome to say
Download the backtrack ISO LiveCD and run it on a laptop or PC which has a supported wireless device. That LiveCD comes with a suite of wifi cracking apps which you can use to penetration test your wireless network if you thusly desire.
Doesn't work with many Acer laptops though due to something stupid with the Acer motherboard design (and guess what laptop I have! haha)
Guys.....
I find lot of prepaid wifi network in hotels, restaurants, etc. in order to join the network, I must register with user name & password that will be given by the provider if I paid certain amount of money.
I just wondering is there a way to hack prepaid wifi?
thanks
You will need this l33t t00l: m0n3y.
I remember this was discussed long time ago...
as I recall, you can't do that using WM phone, neither a windows laptop..etc.. you need Linux OS and some special tools...and even though it's possible, it takes very long time 1-2 hour to break the password (according to the encryptions of course)
try to search the forum, you might end up with that thread
I cannot believe how often companies just use the same username and passwords.
You actually crack some networks in 40 mins.
using something like CommView® for WiFi PPC or Airscanner Mobile Sniffer can help in that process.
None of the above techniques will work since the companies use a form of IP Tables.
THE only way is to tunnel with DNS using something like NSTX, but its very alpha. (Easiest way to test if technique works is by trying to ping a website and see if it returns the correct IP address)
The technique is there, just needs a good coder and some time..
Tunneling over DNS. That's clever. But all the commercial hotspots I've ever used resolve every IP address to the login/order form page when you aren't already logged in. That is, you can't tunnel through DNS.
The methods that take "40 minutes" to crack the encryption are talking about something completely different - finding the WEP or WPA keys for a network that has security enabled. It wouldn't be useful for prepaid hotspots, as they generally do not use WEP or WPA encryption. Instead, they let you associate and get an IP quite easily. Then they direct you to the credit card order form.
One method that can be used on some of them is to spoof the MAC address and IP address of an authorized, logged in client. However, you will quite literally steal their internet access, as that client will be knocked off the network. I've done this myself but it doesn't seem to work anymore on any of the big networks like T-Mobile (in Starbucks).
Best bet is trying to find a vulnerability in one of the web applications running on the server. All the layer 2/3 stuff is pretty well locked down.
fluxist
They will resolve but wont actually PING, thats due to IP Routing Tables.
There is no way to crack wifi password for pocket pc and laptop centrino main board. And you need special wirelless hardware. Must be pentium 4 or above.. Airsniffer and other proğrams can helpful. its change on WEP or WAP protocol. WEP is the most hard. You can find how to crack on forums and videos on youtube
^ That is rubbish.
Centrino or not, it has nothing to do with it.
Its all down to the wireless card and whether or not it accepts mode monitor/master.
Its WPA not WAP and WPA is far harder than WEP due to having to be brute forced, unlike WEP which has the well known RC4 weakness.
I think he is referring to the fact that one cannot do promisc mode on PPC, so they can never collect the packets to try and compute a WEP key. And also the fact that on Centrino Wifi cards (2200BG, et al.) the linux drivers cannot due packet injection in promisc mode. However, this limitation is overcome in some recent patched drivers. See the Backtrack linux live cd (www.remote-exploit.org/backtrack.html) for details.
fluxist
I don't think there is a hacking tool for ppc which is too very effective or complete...
All so called cracking tools for ppc are buggy little ****s...
Aircrak ng is best for PCs ... em waiting 4 a version of it on ppc...
Hmmmm.... That would be very interesting if they came out with an application to crack WEP and WPA networks I could see WEP being cracked but not sure about WPA since WEP is extremely easy to crack usually in about 10 minutes or less depending on the strenght of the signal, but WPA is much more difficult since it requires a brute force attack. I'm not so sure that our phones are capable of that.
You are waisting your time thinking of this with a phone as the Colleting of packets will take so long and PPC don't support packet injection and you would be limited to WEP
Get your self a net book that supports CUDA then you stand a chance Google CUDA Brute Force
i can buy a pin to accesses it but i cannot sharing it via hotspot how can i share it
isn't have any application that able to crack the wep key iby pd device.
so that we can acces to a secured access point without know the wep key
Networking
It takes about one minute go to into an AP and change the required setting. Most computers will switch settings automatically.
I've been running AES for awhile now since I heard about something similar to this several months ago. Works fine.
Thanks
Venu
professional audio restoration
concrete polishing
gold recycling
Cracking a WEP encryption requires a WiFi radio that supports packet injection to function. This is not a standard WiFi radio feature and only comes on certain devices. Unless I've been doing it wrong all these years, you need a special device to do it even with most laptops. The chances that ANY phone manufacturer made a phone with the proper chipset is slim to none I would imagine.
I'm sure you're just doing penetration testing on your own network to test your security because suggesting anything else would be highly illegal...
Have you checked this out?
http://forum.xda-developers.com/showpost.php?p=4104663&postcount=33
Over the past couple of weeks since I got a GTX 760 for my main rig, I've been playing with getting Shield streaming to work through a NAT. With a combination of an Android app and Windows app, I've been able to get the Shield to stream through a NAT device.
This is alpha software, so it may not work for you. I'll be continuing development on it to make it more robust based on bug reports filed here and on the GitHub projects
This method is potentially more complex than running a VPN, but it is lower overhead and works in environments where VPNs cannot.
For those who don't care about the technical details, skip the next section.
Relay Technical Details
The Shield uses MDNS to discover compatible streaming PCs. It issues a query for _nvstream._tcp.local to which streaming PCs reply with PTR, A, AAAA, and TXT records. MDNS isn't routable outside of the local network (and sometimes blocked within the network too), so naturally PCs outside the Shield's local network won't be available as streaming targets.
To solve the MDNS problem, I wrote MDNS relays for Android and Windows that operate on UDP port 5354. The Android relay sends MDNS queries to the Windows relay where the Windows relay replays them local and sends the reply back to the Shield. The Android relay then takes the reply and parses it to look at the A record. It replaces the IP address specified in the A record with the IP address it received the MDNS reply from so it can properly connect to PCs behind a NAT. With the MDNS relay code in place, the Shield could see the PC and even start games.
There was still a problem getting the video stream back. It turns out that the way that UDP port 47998 is used on the Shield streaming software running on the PC prevents it from traversing NATs when going back to the Shield because it assumes that the source is always 47998. This is IMHO a bug because all other ports deal with NAT traversal properly, but needless to say I still had to deal with this.
The only option I had for fixing the port 47998 issue was to capture the packets as they go onto the wire in the Windows relay. I used WinPcap to capture the UDP packets leaving the machine. I then filter based on whether the packet was addressed to us. If it's a packet from the Shield to us on port 47998, then I save the source port of that packet. When I see a packet going out from us to port 47998, I extract the data from that packet and send it again on my own socket also bound to port 47998 (so the source port is correct) with the destination specified in the packet and the port that we saved from the Shield's last communication. With this code, the Shield can connect to a PC from behind a NAT.
Instructions
1. Download and install the Shield Proxy APK on the Shield from https://github.com/cgutman/ShieldProxyAndroid/releases
2. Install WinPcap on your streaming PC from http://www.winpcap.org/install/
2.1 Only required for v0.1-- Install the Visual C++ 2013 runtime library for x86 (use x86 even on x64 systems) from http://www.microsoft.com/en-us/download/details.aspx?id=39315
3. Ensure your router is configured properly as described in the next section.
4. Download and run the Shield Proxy Windows program on your streaming PC from https://github.com/cgutman/ShieldProxyWindows/releases
5. On the Android app, fill in the externally accessible IP address or DNS name for your router. You can get your external IP address from http://www.whatsmyip.org/ on your streaming PC.
6. Tap the start button to start the Android relay service
7. Stream like normal from the TegraZone app
NAT/Router configuration for Shield streaming
The following ports need to be forwarded to the streaming PC:
UDP 47998, 47999, 48000, 5354 (MDNS relay port)
TCP 35043, 47989, 47991, 47995, 47996
Troubleshooting
Make sure ShieldProxy.exe is allowed through Windows Firewall for Private and Public networks.
Make sure ShieldProxy.exe and the Android Shield Proxy service are running
Make sure the external IP address of your streaming PC is correct in the Android app (use http://www.whatsmyip.org/ from your streaming PC)
If TegraZone doesn't show your PC as online and you see "We haven't received any DNS responses. Is the Windows Shield Proxy running on your PC?",
Ensure the router is properly forwarding the specified ports to your PC. Note that TCP vs UDP matters when setting the router forwarding configuration.
Issues
If anyone encounters problems, please report them here or on the GitHub issues page. I'll try my best to get them fixed.
After getting all the initial setup done, it's seemingly ran great so far; considering the circumstances. Haven't had any errors besides some DNS thing I didn't get to read fully when it booted up Steam but did not have any impact on playability.
DLL error
I keep getting an error that MSVCR120.dll is missing. I checked the windows\system32 folder and it wasn't there, so installed the Visual C++ redistributable package for Visual Studio 2012 and 2013 Preview. This added the DLL to the system32 folder, but still getting the same error after a reboot. Tried copying the DLL to the directory for Shield Proxy and it then gives me an error "The application was unable to start correctly (0xc000007b). Click ok to close the application.
Any ideas?
Thanks and thanks for putting this together!
Cheers!
daethang said:
I keep getting an error that MSVCR120.dll is missing. I checked the windows\system32 folder and it wasn't there, so installed the Visual C++ redistributable package for Visual Studio 2012 and 2013 Preview. This added the DLL to the system32 folder, but still getting the same error after a reboot. Tried copying the DLL to the directory for Shield Proxy and it then gives me an error "The application was unable to start correctly (0xc000007b). Click ok to close the application.
Any ideas?
Thanks and thanks for putting this together!
Cheers!
Click to expand...
Click to collapse
I can't remember whether the 64-bit Visual C++ redistributable includes both 32-bit and 64-bit runtime dlls. The relay is built as a 32-bit program so it needs the 32-bit runtime even on a 64-bit machine.
For the next version, I'll build it with the runtime linked into the executable so people won't have to hunt down the runtime.
cgutman said:
I can't remember whether the 64-bit Visual C++ redistributable includes both 32-bit and 64-bit runtime dlls. The relay is built as a 32-bit program so it needs the 32-bit runtime even on a 64-bit machine.
For the next version, I'll build it with the runtime linked into the executable so people won't have to hunt down the runtime.
Click to expand...
Click to collapse
Thanks - installed the 2013 32bit preview and it worked like a charm after. Will start testing the remote streaming now. Thanks for the quick pointer. Appreciate it!
Cheers
daethang said:
Thanks - installed the 2013 32bit preview and it worked like a charm after. Will start testing the remote streaming now. Thanks for the quick pointer. Appreciate it!
Cheers
Click to expand...
Click to collapse
Cool, I updated the instructions to mention that the Visual C++ 2013 x86 runtime is required.
Oh, nice.
Since VPN method didn't work on my rig, I tried this one... and works great!
thanks a lot.
Seems to be working here as well, although similar to VPN, streaming outside of my WIFI connection doesn't seem to work. The game will start and every once in a while I will see video start (more often though just a blank screen followed by a timeout). My home connection has 55 down and ~12 up, so I think the connection on that end is good. I have tried from multiple remote locations, but none of them have worked so far. Will do some speed tests on the remote connections to see if they are the cause. Splashtop seems to stream fine when on remote connection, so I dont think its a connection issue. One thing that works better on this solution is the PC actually shows as available, for some reason it does not when on VPN.
daethang said:
Seems to be working here as well, although similar to VPN, streaming outside of my WIFI connection doesn't seem to work. The game will start and every once in a while I will see video start (more often though just a blank screen followed by a timeout). My home connection has 55 down and ~12 up, so I think the connection on that end is good. I have tried from multiple remote locations, but none of them have worked so far. Will do some speed tests on the remote connections to see if they are the cause. Splashtop seems to stream fine when on remote connection, so I dont think its a connection issue. One thing that works better on this solution is the PC actually shows as available, for some reason it does not when on VPN.
Click to expand...
Click to collapse
From what it sounds like, the MDNS relay is working fine and the router is definitely configured correctly because you get video sometimes. I assume you also see the message in the ShieldProxy.exe console: "Shield is now communicating with us on port XXXXX".
If I had to speculate, I'd say it's related to high packet loss. Shield streaming (both on the network and through my proxy) use UDP for the video stream and a PPTP VPN uses GRE packets which are both lossy protocols, while Splashtop uses TCP which retransmits lost packets. It may be that the ISP is doing some QoS stuff that's causing non-TCP packets to be dropped at a higher rate, but this is complete speculation.
The Shield pings the streaming PC and the streaming PC sends back video data, but if the pings aren't reaching the streaming PC or the video isn't reaching the Shield, you get the dreaded "Streaming failed due to network interference ... etc" message.
The upside is that we can better troubleshoot the issue based on the output from the Windows Shield proxy. If you could paste that here, I could take a look (remove the last 2 octets of the IP addresses, so 192.168.1.1 becomes 192.168.X.X). Also if you would post what ISP you're using and where you were trying to connect from (whichever ones you feel comfortable mentioning).
I can't seem to get any of those ports open except 47989, even when I change my setup to be directly connected to my SB6141 modem. Port 5354 always appears closed and can't be accessed so I never can see my computer when I try connecting with the shield proxy app posted above.
Anyway to change the port to something other than 5354 or any idea why the port always appears closed even when connected from computer to modem?
Thanks
Edit: It seems only ports that are being listened to on netstat -an will appear as open to a port checker. Shouldn't there be something on that list listening for 5354 in order for Shield proxy to connect to that port?
HobsonA said:
I can't seem to get any of those ports open except 47989, even when I change my setup to be directly connected to my SB6141 modem. Port 5354 always appears closed and can't be accessed so I never can see my computer when I try connecting with the shield proxy app posted above.
Anyway to change the port to something other than 5354 or any idea why the port always appears closed even when connected from computer to modem?
Thanks
Click to expand...
Click to collapse
Ports will appear closed even if the router is properly forwarding them to your PC, but the PC is blocking them. Check your Windows Firewall settings and make sure ShieldProxy.exe is allowed through for both public and private networks. I also found out the hard way that it won't always prompt you to allow for public networks if it's already allowed for private and vice versa.
I think it's normal for those other Shield Streaming ports to be closed until streaming actually starts, but 5354 should appear open while ShieldProxy.exe is running.
It is possible for me to (and I plan to) add some code to make the MDNS relay port configurable but I don't think that would solve your issue here.
EDIT: Also make sure you're testing 5354 (and other UDP ports) as UDP, not TCP. TCP 5354 is not the same as UDP 5354. In fact, you can host different services on the same ports on TCP and UDP at the same time.
cgutman said:
Ports will appear closed even if the router is properly forwarding them to your PC, but the PC is blocking them. Check your Windows Firewall settings and make sure ShieldProxy.exe is allowed through for both public and private networks. I also found out the hard way that it won't always prompt you to allow for public networks if it's already allowed for private and vice versa.
I think it's normal for those other Shield Streaming ports to be closed until streaming actually starts, but 5354 should appear open while ShieldProxy.exe is running.
It is possible for me to (and I plan to) add some code to make the MDNS relay port configurable but I don't think that would solve your issue here.
EDIT: Also make sure you're testing 5354 (and other UDP ports) as UDP, not TCP. TCP 5354 is not the same as UDP 5354. In fact, you can host different services on the same ports on TCP and UDP at the same time.
Click to expand...
Click to collapse
Ah good call out of my lack of attention to detail I forgot to run Shieldproxy.exe again after removing my router from the loop and rebooting everything. It appears to be working now. Unfortunately my Linksys E2000 with DD-WRT has been having major issues port forwarding but at least I know it's my router now and I can keep playing with it to get it working like I had to do with VPN.
Thanks!
v0.2 released
I've posted updated releases for Android and Windows on the GitHub projects. None of the changes in either version break compatibility with v0.1 so you can update them at separate times.
Android v0.2 Changelog:
- Fix several bugs preventing the "MDNS relay not running" warning from showing up consistently
- Tighten the check that determines whether the MDNS query will be forwarded
Windows v0.2 Changelog:
- Statically link to the VC++ runtime so installing the runtime isn't required anymore
- Tighten the check that determines whether the MDNS query will be forwarded
cgutman said:
From what it sounds like, the MDNS relay is working fine and the router is definitely configured correctly because you get video sometimes. I assume you also see the message in the ShieldProxy.exe console: "Shield is now communicating with us on port XXXXX".
If I had to speculate, I'd say it's related to high packet loss. Shield streaming (both on the network and through my proxy) use UDP for the video stream and a PPTP VPN uses GRE packets which are both lossy protocols, while Splashtop uses TCP which retransmits lost packets. It may be that the ISP is doing some QoS stuff that's causing non-TCP packets to be dropped at a higher rate, but this is complete speculation.
The Shield pings the streaming PC and the streaming PC sends back video data, but if the pings aren't reaching the streaming PC or the video isn't reaching the Shield, you get the dreaded "Streaming failed due to network interference ... etc" message.
The upside is that we can better troubleshoot the issue based on the output from the Windows Shield proxy. If you could paste that here, I could take a look (remove the last 2 octets of the IP addresses, so 192.168.1.1 becomes 192.168.X.X). Also if you would post what ISP you're using and where you were trying to connect from (whichever ones you feel comfortable mentioning).
Click to expand...
Click to collapse
I think you are right in regards to packet loss. I have Comcast at home, and have tried various providers (ATT LTE, ATT WIFI so far with this solution and VPN over some other WIFI networks). I will be testing it again in the next couple of days and will report back with the additional details requested. I have the ASUS NT-R66U router as well. Thanks for the reply and offer of assistance, really appreciated.
Cheers!
Finally had some time to play with this more than some quick tests. This seems to run so much smoother than my old VPN configuration.
I don't know if anyone else has experienced with this but even though it's running like almost perfectly smooth sometimes the connection just completely drops. VPN would have big lag spikes but would rarely drop me.
Edit: Hm not sure if this is normal but there seems to be a larger audio latency (> 200-300 ms) which wasn't as bad with VPN. If I go to a friends house instead of playing around at work I'll try hard wiring my shield to ethernet to see if that improves anything.
HobsonA said:
Finally had some time to play with this more than some quick tests. This seems to run so much smoother than my old VPN configuration.
I don't know if anyone else has experienced with this but even though it's running like almost perfectly smooth sometimes the connection just completely drops. VPN would have big lag spikes but would rarely drop me.
Edit: Hm not sure if this is normal but there seems to be a larger audio latency (> 200-300 ms) which wasn't as bad with VPN. If I go to a friends house instead of playing around at work I'll try hard wiring my shield to ethernet to see if that improves anything.
Click to expand...
Click to collapse
Glad to hear that it's smoother than VPN for you.
The Shield Relay is just the same Shield streaming traffic just sent over the Internet rather than your home network. This comes with benefits (speed) and drawbacks (lower reliability). Both of the oddities that you mention are probably related to packet loss, latency spikes, and routing changes that are more prevalent on the Internet than the average home network.
I suspect that the reason the stream drops during big lag spikes is because the lag spikes are due to packet loss or high latency. If the Shield's pings to the streaming PC get lost or arrive very late, the PC will timeout the stream, stop sending video, and the stream will drop.
The audio latency is probably due to variances in the latency and routing of the Internet. It's possible that the video packets and the audio packets take different paths through the Internet, so they can reach the Shield at different times. Normally the latency is close on a home network because there's only one route from your computer to your Shield, but the Internet can have tens or hundreds of routes to get your packets from point A to point B (sometimes even the route from A -> B is different than B -> A).
Nvidia could timestamp the audio and video packets so they can be played back at the same time, but that would force the Shield to delay displaying the video while it waits for the audio packets to come (and vice versa). Since this is a gaming feature, they probably don't want to introduce more latency.
ok how to know if everything if ok ?
ok how to know if everything if ok ? ?
i done everything like it write over here and i don't get any error just "stop" after i click run in the shield.
so everything working right?
Yosizach said:
ok how to know if everything if ok ? ?
i done everything like it write over here and i don't get any error just "stop" after i click run in the shield.
so everything working right?
Click to expand...
Click to collapse
Do you see both lines like "Shield is now communicating with us on port XXXXX" and "Relaying MDNS traffic to XXX.XXX.XXX.XXX" on the Shield Proxy running on Windows?
cgutman said:
Do you see both lines like "Shield is now communicating with us on port XXXXX" and "Relaying MDNS traffic to XXX.XXX.XXX.XXX" on the Shield Proxy running on Windows?
Click to expand...
Click to collapse
dmm...no i don't see it ...this is what i get when i run the
ShieldProxy.exe
all i get is "shield streaming proxy for windows v0.2"
joined MDNS multicast group with interface 192.168.1.13 (my pc)
listening on Microsoft for shield traffic
relay is up and running..."
what i am doing wrong .. i open all the ports i have RT-AC66U so..
Yosizach said:
dmm...no i don't see it ...this is what i get when i run the
ShieldProxy.exe
all i get is "shield streaming proxy for windows v0.2"
joined MDNS multicast group with interface 192.168.1.13 (my pc)
listening on Microsoft for shield traffic
relay is up and running..."
what i am doing wrong .. i open all the ports i have RT-AC66U so..
Click to expand...
Click to collapse
Does your PC show up as available in the TegraZone app with Shield Relay running on Windows and Android? The start button on the Android relay doesn't do anything other than just start the relay service in the background. You still need to use the TegraZone app to access streaming. If you see an error message saying "We haven't received any DNS responses. Is the Windows Shield Proxy running on your PC?" then check that ShieldProxy.exe is allowed through Windows Firewall on public and private networks.