Hello all.
Experimental version of custom mode controller for TIACXWLN built-in adapters
is located at http://winm-soft.atspace.com
Who is interested may test it...
Hello AlexB.
I was trying to run your program on hermes with WM6 which according to wiki is equipped with TI chipset, I found references in registry to TIACXWLN drivers but unfortunately your custom mode controller don't want to work all I've got is "Cannot process memory block!........" after choosing yes "Cannot read configuration! It is possible device is off." but the wlan device is actually on. I'll send you my *.dmp files maybe you can manage to make it work on hermes.
I had been toying around with the custom mode driver and have had little success thus far. Another thread was started and I have since taken great interest in trying to achieve promiscuous packet sniffing on my Tytn. I believe the problem may lie within either the custom driver, tiacxwln.dll or the hardware itself.
A little more information...
Mode controller works (attempt) directly with adapter (ACX100, PCMCIA!!!), not with the driver (standard, not patched). Program extracts an address of adapter registers window from TIACXWLN driver (TIACXWLN1 device object) and next it enables some packet filters, executes commands and etc...
I have no new ideas now why it works badly on such built-in adapter (device process commands with success status)...
On Dell I receive all packets but sometimes only...
Alex is it possible for you to patch internal driver to use promiscuous mode and don't bother with custom controller?
The custom mode controller is probably the best way to go about activating promiscuous scanning, since it's affect can be made temporary. If this mode of packet scanning were always enabled, I believe it would not allow one to associate with an access point.
I've attached the dump files that were generated after the unsuccessful execution of tiacxwln_ctrl.. perhaps the author or someone else can derive a solution .
Hi, Alex.
I was looking for your tiacxwln_ctrl custom controller on your web site, http://winm-soft.atspace.com/ but I could only find TNETWLN and WCF-11 files. Has it been moved, or deleted? I'd like to try it on my HTC 8525 with WM6.
Walt
I've received a private request for the file that AlexB developed and had posted on his site winm-soft (it's no longer available) which is mentioned above.. it will not enable promiscuous scanning on the Hermes. I repeat, it is broken, it does not work. AlexB did a great job creating this hack, however I don't believe that it was ever intended to work with the 8525. If AlexB would be so kind as to provide his source then perhaps we would have a decent starting point to enable this feature, however anyone who would be interested in doing this would find 3 perhaps not so obvious hurdles.
1: The TIACXWLN.DLL driver needs to be hacked to enable monitor mode.
2: A program capable of capturing and storing .pcap files would be necessary at this point as the only program that I'm aware of capable of sniffing out weak keys is airsnort which only accepts pcap dumps.
3: The pcap file would be huge. ie - could quite possibly take up 1gb or more of a micro sd card.
Just my $.02. Comments are welcome. Now onto the file. Enjoy!
Hi everybody,
The TIACXWLN controller was developed (beta/gamma...) for Dell X51 PDA and program worked bad and it is discarded! That program got some pointers (parameters) from context parameters of standard tiacxwln driver... Standard driver in Dell and driver in HTCs are different... Some experience of controller development was used to make TNETWLN controller (also TexasInstr adapter)... All controllers try to enable only promiscuous mode (not monitor mode).
As yet there are no TIACXWLN promiscuous mode ideas and devices...
Now some ideas for TNETW1251 (with SDIO) exist.
Thanks for the clarification.
Alex, I don't understand your reluctance to release source code, unless you based it upon "inside knowledge" of someone's copyrighted code, in which case I understand completely. If (and I fit into this category myself from time to time) you are simply embarrassed by code that "worked bad and it is discarded!" then maybe you could release it to a small group of coders who would be able to make it work without a lot of public exposure.
My personal interest is simple. I have a Zaurus C3200 that I use to sniff out rogue access points on the networks I am responsible for. It's big and clunky, and only works on 802.11b networks, so I don't carry it all the time, whereas I *always* have my 8525 with me, and it will work on b/g.
As far as WEP cracking goes, with ARP injection you can get aircrack to find a key with files of around 1-2MB in size, so the pcap files would not be too big. Of course, as I understand it, you *would* need monitor mode for packet injection to work.
IMHO this is a valuable development work that should continue. I just wish I had the skills and time to do more myself!
Walt
About sources
Main idea of contollers is working in special modes in parallel with vendor driver/software (without patching and etc.). All information, command structures and register constants was extracted from: http://acx100.sourceforge.net/
Who is intersted in building of new TIACXWLN driver should analize these sources. There are many commands and constants in these sources but controller used only Packet Filter command. All that the controller needed was address of mapped window of registers (it was stored in vendor driver context)... TIACXWLN adapter on Dell X51v processed these asynchronous commands with success (by response) but vendor driver was as post-processor any commands...
Commands are used by controller (details see in Linux driver (acx_struct.h)):
1) ACX1xx_CMD_INTERROGATE (IE_RXCONFIG)
2) ACX1xx_CMD_CONFIGURE (IE_RXCONFIG, RX_CFG1_RCV_PROMISCUOUS)
...
Hi, thanks to Lancealot for upload this file.
I install this controll driver in my HTC Universal (Universal have Wi-Fi chip from same corporation as TyTN: tiacxwln).
But this controll utility is not work on my UNiversal :-(
That setings promiscous mode, so Universal is freezed :-(
Anybody have any ideas ?
* Please excusive my for my bad english, thanks.
Hi Alex
I hv Sedna and have the discvussed Wi Fi driver..My problem is that it connects to wi fi router (g) but I cannot surf..most of the times I have to on/off and it works, but after long periods it disconnects.I hope this will solve the problem, also if u can suggest any guidance,I will b greatful
AlexB does your sniffer allow you to capture wifi traffic in all channels?
Hi,
Sniffer captures "adapter driver <-> protocols stack" packets...
Standard driver of WiFi adapter returns packets only after connecting to some network therefore sniffer gets traffic from one network on some channel... In promiscuous mode adapter gives user packets with foreign destination address.
Related
Hi all,
i need a special device driver that will use existing COM port and emulate another COM port and network card (i got some binary protocol on serial line which holds GPS and IP signal and i want split it in that device driver into virtual COM with NMEA and network card proving IP (Ethernet) interface or maybe another virtual COM with PPP emulation).
Have anyone got experience in such and can estimate effort of such task?
Maybe someone will be interested in a deal of developing such device driver?
Bets regards,
Chris
Look at Gpsgate, it may be what you need.
http://franson.com/gpsgate/
Thanks, it looks interesting - especially their SerialTools (with VPorts). It looks a bit clumsy with its variant datatypes (operating on binary data would be not as pleasant as with simple datatypes) but mayby i will give it a try...
Nevertheless - are there any other suggestions / propositions?
If you go to download site for gpsgate you will get the option to download many other utilities linked to the program, some are 7 day, 14 day or 28 day trials. The option comes via email.
I have a problem that I hope some of the code gurus here can help me with. I have an HTC PDA that was codenamed Colorado. The Colorado is actually the Dell Axim X50 series. I have a thread on Aximsite http://www.aximsite.com/boards/showthread.php?t=140071 where I am trying to add a USB host hardware interface to the PDA. I have done quite a bit of hardware reverse engineering of the X50v device (I'm a old-time hardware hacker) and have been able to bring out the PXA270 USB host port1 interface to the outside world via two unused pins on the sync connector.
I originally noticed that the X50v A02 ROM had the OHCI driver included, so I rolled back to that release on my test PDA and have been attempting to get the interface operational. In my quest, I have determined that I need the usbd.dll driver as well as any client device drivers for HID, mass storage, etc.
I've used a number of the great utilities I've found on this site (thank you very much) to grab a copy of the Axim ROM and pull it apart. I consider myself great at working on hardware but my software skills have become rusty over the years (hey - I started by building this system a 'few' years ago: http://www.sol20.org/ )
What do I need?
I would appreciate getting some guidance on how to dissassemble the ohci.dll module so I can see if in fact, it was designed for the X50 or if it was left in by accident by HTC as the later ROM updates for the X50 series had the ohci.dll module replcaed with one named peripheral.dll which was about 1/5th the size.
Also, I'm wondering if either the ohci or usbd drivers require the irq and/or the membase of the PXA270 USB host port1 interface and if so, how do I determine those.
My original idea was to use a simple 2 port hub to bring out the interface. Unfortunately, I recently discovered that a hub requires a hub client driver. Because of that, I will settle on getting a USB flash memory key to interface directly as the drivers are already available. One of the problems I have is interfacing the 3v USB host lines on the PDA to the 5v data signals that may be present on the client device. The PXA270 USB host lines are already terminated on the PCB with 15K resistors. All that is needed is a transient protection chip and/or port driver chip.
I have installed the free Microsoft WinCE dev environments which I thought contained the source for the generic ohci driver, but I can't find it anywhere so I guessing it's not included in the free dev s/w.
Although this is only my 2nd post here, I do hope to be able to contribute technical information going forward. What I'm doing on the Aximsite is quite advanced as far as hardware hacking goes and I hope to be able to simplify it so a few others can 'play'.
Thanks in advance for any help and I wish everyone here a great New Year!
Wow. Well this is a bit over my head, but does sound great.
I will try pointing you toward a couple of useful tools:
1st is IDA probably the most powerful disassembler for ARM code. The free evaluation works fine, but won't save and closes about every 30 min. Still should do the trick if you just want to look at the code.
2nd to get sample driver code, you need Platform Builder. Not sure if that is what you downloaded, but try the provided link. Evaluation version contains all the source code MS is willing to give, it just has some limitations on ROM compilation (which you should not care about).
The only problem is, it's a real b*** to install. Takes hours even if you have a goo internet connection.
Hope this helps.
Thanks for the quick reply.
Do you know if there is anyone who knows a little on how the low level device drivers actually interact with the hardware ports?
Also, I assume that with just the ohci and usbd drivers, if the port is actually activated by pulling one of the data lines high, I should get the popup box asking for the name of the device driver. correct?
how to determine I/O base offset?
In trying to reverse engineer the ohci driver for a couple for the HTC units, I need to figure out where the I/O register base starts.
Are there any memory dump utils, like dumprom, that would indicate that?
I've installed platform builder and want to try compiling the standard ohci driver, but I need to know how to determine the start of the I/O registers on a given WM2003SE platform.
Any assistance would be greatly appreciated.
thanks
Hi,
i'm trying to get airscanner app to work on my trinity, but it seems it don't supports promiscuous mode (like most wm5 devices). In fact, it seems that most wi-fi hardware enabled device actually supports promiscuous but manifacturer disables it in low level part of OS, rom or device driver. Could anyone capable of that, enable it? It would be an huge gain for the community. In addition, once unlocked for a specific device, i think it would be quite easy to port the "mod" to any recent WM5/6 device.
Thanks!
Moved discussion from "Controller for TNETWLN" thread.
Handy Sniffer is next step of TNETWLN controller. As yet this sniffer can enable unofficial promiscuous mode only for TNETWLN WiFi adapters ("TNETWLN1", TNETW1250 chip with SDIO interface). For other adapters sniffer supports only standard system query for On/Off promiscuous mode (most adapters does not support this request). As I know standard driver for TIACXWLN also does not support promiscuous mode... If TIACXWLN from Athena supports promiscuous mode... congratulations.
Anyone had any look with HTC Wizard? Installed OK and dnt get any errors however doesnt seem to sniff anything apart from the AP im connected to.
Cheers
How do you test it?
1. Prepare WiFi adapter (disable Power Save mode!)
2. Swith on and connect adapter to network
3. Select adapter in Sniffer ("TNETWLN1")
4. Check menu "Extended TNETWLN"
5. Check menu "Promiscuous Mode"
6. Start of packet capture
What is the best PDA that works for this Handy Sniffer? Can you recommend one?
FujitsuSiemens LOOX C550 and N560 have TNETWLN built-in WiFI adapter. They are supported by HSniffer and they have powerful processors (Intel 500/600 MHz). You can use sniffer with any adapter that supports promiscuous mode.
Second test on HTC Kaiser - working. I must retst it on HotSPot place.
AlexB said:
4. Check menu "Extended TNETWLN"
Click to expand...
Click to collapse
Hi Alex, great work!
i'm trying handy sniffer with my Trinity, but i can't see "Extended TNETWLN" menu option, but only "promiscuous mode". What's wrong?
Anyone got successful with Trinity?
Thanks!
after following alex suggestion with a key into registry, i think i'm actually sniffing my network with my trinity. Anyway, i still don't see the extended TNETLWN menu (is it that important? ). I'm using a Trinity with Lasagna rom.
Thanks Alex!
Hi everybody,
I know about normal working of sniffer (promiscuous mode) on next devices:
1. FujitsuSiemens LOOX N520, C550, N560
2. Qtek 9100
Has anybody success with other devices or problems on these?
Hi everybody
ItalianTytan mentiond a RegistryKey for the trinty. Could you please post this hack?
i'm using as well a trinty and i'm only able to sniff my own networktraffic although im in the promiscuous mode.... btw i don't see the extendet menu either...
thx for you suggestion and the answer :-D
so long
konto
hi !!
i'm using a qtek9100.
when i select extended mode, a message tell me "disable the power save mode before adaptater ON"
what's that mine?
thanks!!
How can I convert the HEX packets to Text? Any apps available?
Thanks in advance for your help!
so it works on the tmobile mda? can you capture ivs? where is the developers webpage?
http://winm-soft.atspace.com/
I'm working to develop an application to use a rooted Nook STR as a handheld data input platform, which then sends the data to another Android device (tablet or phone; TBD) acting as a hub. From what I've been able to determine, the options for communications between the devices are:
Bluetooth
-Possibly available using a dongle, USB OTG cable, and enabling USB host mode as described here. This doesn't seem practical within the time/budget/scale of our application.
Wi-Fi
-Wi-Fi Direct would be ideal, but requires either Android 4.x or a patch/hack to enable it, which I haven't seen anyone working on (correct me if I'm wrong about this)
-Separate Wi-Fi hub to manage communications between the devices
Is there an alternative, implementable within reasonable time and cost, to facilitate device-to-device communications wirelessly and without additional separate hardware? My research hasn't turned up any solutions that aren't extremely awkward, but I'm relatively new to this, so hopefully someone has a better idea or knows of an obvious possibility that I'm missing.