Menu
▾
▴
airjack-hackers — developers of airjack driver internals
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|
|
From: Joshua W. <Jos...@jw...> - 2003-09-22 11:54:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is the first release of my file2air tool. From the README: - --- file2air uses the AirJack drivers to inject packets into an 802.11 network, using a binary input file for the transmission information. I've included a few sample packets in the ./packets/ directory for testing purposes. file2air will read the binary input file and transmit the contents onto a wireless network. It is assumed the input file is a valid 802.11 packet, with an appropriate 802.11 header, and is an even word size (e.g. evenly divisible by 4). Through command line options, the user can override the destination,=20 source and BSSID addresses with arguments, and can specify the number of packets to send with an arbitrary delay between each packet. - --- The README also has some examples on use that can be used for, well, nefarious purposes. Code: http://home.jwu.edu/jwright/code/file2air-0.1.tar.bz2 MD5: http://home.jwu.edu/jwright/code/file2air-0.1.tar.bz2.md5 GPG: http://home.jwu.edu/jwright/code/file2air-0.1.tar.bz2.asc My intention when writing this tool is to create a series of test cases to launch against a wireless AP or STA to determine software and firmware implementation flaws - similar to what the PROTOS tool-suite did for SNMP. I've found it useful on more than one occasion, so I cleaned it up and am releasing it under the GPL. This tool also contains a library I wrote to abstract packet injection with the AirJack v1 drivers - similar to the standard libpcap functions. Some of the functions don't work properly (notably read and write) but hopefully it will make it easier for people to use AirJack for their own testing purposes. Thanks to Abaddon, Dragorn and FX for their various contributions. Questions, comments, suggestions? Email me. - -Joshua Wright Senior Network and Security Architect Johnson & Wales University Jos...@jw...=20 http://home.jwu.edu/jwright/ pgpkey: http://home.jwu.edu/jwright/pgpkey.htm fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBP27i7o/i/ArUS0pzEQJOwgCg7nS4SyeU9qgHJbO47El6hdpOEaQAoMBM q83NmNT4W+hUpnGPxqFk6RTV =3DGW+8 -----END PGP SIGNATURE----- |
|
From: Timothy B. <ti...@tu...> - 2003-08-21 23:01:34
|
[Hope this doesn't hit the list twice... some how sourceforge hates me.] Attached is just the tar ball of the initial build process... Uh. Yeah, right now it's just Makefiles. I got caught up in making config.in and Makefile.am but that's for latter. This is for now. --timball -- GPG key available on pgpkeys.mit.edu pub 1024D/511FBD54 2001-07-23 Timothy Lu Hu Ball <ti...@tu...> Key fingerprint = B579 29B0 F6C8 C7AA 3840 E053 FE02 BB97 511F BD54 |
|
From: Timothy B. <ti...@tu...> - 2003-08-21 22:58:40
|
Attached is just the tar ball of the initial build process... Uh. Yeah, right now it's just Makefiles. I got caught up in making config.in and Makefile.am but that's for latter. This is for now. --timball -- GPG key available on pgpkeys.mit.edu pub 1024D/511FBD54 2001-07-23 Timothy Lu Hu Ball <ti...@tu...> Key fingerprint = B579 29B0 F6C8 C7AA 3840 E053 FE02 BB97 511F BD54 |
|
From: Abaddon <ab...@80...> - 2003-07-30 16:39:45
|
sorry it took so long to get this out to you guys, here is the header file that has the interface, pay close attention to the struct ieee80211_drv as it has the callbacks and such that need to be filled in to make a hardware driver... its still subject to change, but thats what I've been working with, im probably going to remove some of the callbacks as i dont really need them... I solicit your suggestions... --Abaddon |
|
From: Abaddon <ab...@80...> - 2003-07-06 03:46:23
|
at some point pretty much everyone on this list (save perhaps the one person on here from defcon.org) should have a key signing, and setup a signature checking system for all releases, i think we owe it to users to give them some level of assurance that what they are loading into their kernel hasnt been backdoored... no rush at this point, at least not until its officially released... --Abaddon |
|
From: Abaddon <ab...@80...> - 2003-07-06 01:54:37
|
-----Forwarded Message----- From: Abaddon <ab...@80...> To: air...@li... Subject: [Airjack-hackers] list options Date: 05 Jul 2003 14:29:03 -0500 i have changed permissions on the list options to allow everyone that is a member of this list (its a closed lists in general) can view the subscriber list... i expect everyone will play nicely with the other children if i do this, anyone abusing it will be shaved, sterilized, and destroyed...thank you... --Abaddon |
|
From: Abaddon <ab...@80...> - 2003-07-06 01:54:30
|
-----Forwarded Message----- From: Abaddon <ab...@80...> To: air...@li... Subject: [Airjack-hackers] build environment Date: 05 Jul 2003 14:27:05 -0500 also, timball, i will be needing a preliminary build environment, this doesnt have to be good, it has to only be better than one of my makefiles and you know my make files might as well be shell scripts... so everyone with comments, suggestions, death threats, or whatever to do with the build environment, timball (ti...@tu...) is taking point on that... --Abaddon |
|
From: Abaddon <ab...@80...> - 2003-07-06 01:53:51
|
ill be reposting messages like this all night as people get on the list, bare with me until everyone is signed up... --Abaddon -----Forwarded Message----- From: Abaddon <ab...@80...> To: air...@li... Subject: [Airjack-hackers] initial details of driver API... Date: 05 Jul 2003 13:55:23 -0500 i will start to post details of the driver API's tonight on this list... as it stands there are three sections of code in airjack2... the first layer is the os layer, this defines a number of things like os_copy_from_user() and os_spin_lock(), etc, the rest of the sections should never call an os dependant function directly if it can at all be avoided, this way we dont have to rewrite everything... the second layer is the bus abstraction, this is how airjack2 plans on working for so many different bus types, anything regarding talking to the card (not what you say, but how you say it) will go through the bus abstraction, so it shouldn't different code (for the most part) for cardbus as it is for pcmcia (however there are differences in such things as DMA handling where available)...also there is a device event handler that is common to all bus types abstracting away handling of such things as device insert and removal...a bus is described by a struct ieee80211_bus the third layer is the hardware (or driver) layer, this is just a listing of callbacks to control the card, these are pretty low level callbacks (see below for some exceptions) so you dont really need to know much about how the driver is working, it just tells airjack how to make the card do some basic things...this is described by the a=20 struct ieee80211_drv the fourth layer is the airjack system itself, this mostly takes the low level abstractions from the bus, the os and the hardware layers and smashes them together at high speeds to make a driver...this consists of functions to allocate and register bus's drivers and actual devices...this also consists of a number of generic function callbacks that i expect most drivers to use and thus they wont need to do anything but fill in very low level function stubs...however if there is some high level function that the airjack system simply wont handle, then all drivers can override any airjack generic callback on driver registration...each individual device (combination of bus and driver, allocated and registered to represent an actual physical device thats been inserted) is represented by a=20 struct ieee80211_dev so to recap, the major structures are: struct ieee80211_bus: this describes (and abstracts away) a bus (e.g. pcmcia, pci, cardbus, usb, or compact flash), this should be as os independent as it can be guys... struct ieee80211_drv: this describes an individual driver for a chipset, while this is usually only going to have low level hardware callbacks that differ from other drivers, it does hold all the callbacks for card access and event management, so you can override them if needed, but you should strive to only have to use the low level hardware callbacks to make this work... struct ieee80211_dev: this describes an actual device that has been inserted into the machine, it combines both a bus and a hardware driver with the indevidual device stats, status, capabilities info, and config... a word on user space interfaces...the new airjack will include an airjack specific interface, and that is all you need to configure any airjack device, this is desirable so that the same code can easily configure a linux airjack driver, as well as a bsd airjack driver... however, every os abstraction layer will also be required to support that platforms existing legacy configuration interface...this is so that legacy apps will still work, and it will easy the switch...i dont plan on removing this any time soon so you can count on it being there... the new airjack drivers are going to support all the operating mode including station, adhoc, adhoc master (where applicable), host AP, and a couple special airjack modes (ill describe that in a later email), obviously not all drivers will support all modes but we should do our best to make them all work...for releases this weekend dont expect anything but station mode and airjack modes to work...also dont expect encryption of any kind to work at this point... i will in the future be supporting all encryption modes, plus WPA, tkip/mic, aes, and many more as well as a number of other user development forms (such as wep with a repaired KSA, etc)...it should be made easy for all cards to use all forms available even if their hardware does not (we will need to set many of them in host encrypt mode and do it on the host cpu in those cases)...we should make it easier for people to develop such techniques on airjack drivers... one of the reasons why security has been so bad on wireless had been in part due to the difficulty of average developers getting access to test out their ideas and have their code supported on a large number of platforms,one of the goals of airjack is fix that problem by making it easy for developers and researchers to rapidly develop and prototype new security features for 802.11 networks, as well as prototype research tools to test the security of existing security measures... actual code details for this API (enough to start you working on chipset drivers) will be released late to night to this mailing list...this and other emails i will repost a few times because i know many people are not signed up yet (still hung over from the 4th and whatnot ;)... timball: start gathering up atmel chipset info if you could, ill email out the hardware layer structure to the list tonight id like to try to get this working on those crappy atmel cards you have at about the same time i finish my port to prism2 and aironet...also, and maybe more importantly i want frequency hopping support on that symbol card of yours (please tell me you still have it), so track down as much as you can on that as well... anyone else: even though i just said i was porting aironet driver to this, i cant release those that i am writing due to conflicting NDAs, i am however writing it up privately not for release to verify that it can be done easily by someone else... i am currently looking for volunteers to take exiting GPL'ed aironet code and porting it to the airjack framework... i am also under NDA with atheros, and as such i cant release my ar5k drivers, however i am writing them and i am testing out the cardbus bus layer to ensure that development of them is very possible and pretty easy...there are GPL'ed drivers out for these so i am hoping to get someone to help with these as well (i have one taker for this, but i really want this support before the DefCon release guys)... as for broadcom and intersil 802.11a/g chipsets, i currently have no NDAs so i am going to be reverse engineering the windows drivers (did you hear me DMCA *flips DMCA off*) and getting this going for those as well...anyone that wants to help with that is welcome... any questions should be directed to this list if possible guys...expect me to be off and on all the rest of the weekend as i have alot more code to finish to make my monday commitment... --Abaddon |
|
From: Abaddon <ab...@80...> - 2003-07-05 22:38:39
|
i have changed permissions on the list options to allow everyone that is a member of this list (its a closed lists in general) can view the subscriber list... i expect everyone will play nicely with the other children if i do this, anyone abusing it will be shaved, sterilized, and destroyed...thank you... --Abaddon |
|
From: Abaddon <ab...@80...> - 2003-07-05 22:36:43
|
also, timball, i will be needing a preliminary build environment, this doesnt have to be good, it has to only be better than one of my makefiles and you know my make files might as well be shell scripts... so everyone with comments, suggestions, death threats, or whatever to do with the build environment, timball (ti...@tu...) is taking point on that... --Abaddon |
|
From: Abaddon <ab...@80...> - 2003-07-05 22:05:01
|
i will start to post details of the driver API's tonight on this list... as it stands there are three sections of code in airjack2... the first layer is the os layer, this defines a number of things like os_copy_from_user() and os_spin_lock(), etc, the rest of the sections should never call an os dependant function directly if it can at all be avoided, this way we dont have to rewrite everything... the second layer is the bus abstraction, this is how airjack2 plans on working for so many different bus types, anything regarding talking to the card (not what you say, but how you say it) will go through the bus abstraction, so it shouldn't different code (for the most part) for cardbus as it is for pcmcia (however there are differences in such things as DMA handling where available)...also there is a device event handler that is common to all bus types abstracting away handling of such things as device insert and removal...a bus is described by a struct ieee80211_bus the third layer is the hardware (or driver) layer, this is just a listing of callbacks to control the card, these are pretty low level callbacks (see below for some exceptions) so you dont really need to know much about how the driver is working, it just tells airjack how to make the card do some basic things...this is described by the a=20 struct ieee80211_drv the fourth layer is the airjack system itself, this mostly takes the low level abstractions from the bus, the os and the hardware layers and smashes them together at high speeds to make a driver...this consists of functions to allocate and register bus's drivers and actual devices...this also consists of a number of generic function callbacks that i expect most drivers to use and thus they wont need to do anything but fill in very low level function stubs...however if there is some high level function that the airjack system simply wont handle, then all drivers can override any airjack generic callback on driver registration...each individual device (combination of bus and driver, allocated and registered to represent an actual physical device thats been inserted) is represented by a=20 struct ieee80211_dev so to recap, the major structures are: struct ieee80211_bus: this describes (and abstracts away) a bus (e.g. pcmcia, pci, cardbus, usb, or compact flash), this should be as os independent as it can be guys... struct ieee80211_drv: this describes an individual driver for a chipset, while this is usually only going to have low level hardware callbacks that differ from other drivers, it does hold all the callbacks for card access and event management, so you can override them if needed, but you should strive to only have to use the low level hardware callbacks to make this work... struct ieee80211_dev: this describes an actual device that has been inserted into the machine, it combines both a bus and a hardware driver with the indevidual device stats, status, capabilities info, and config... a word on user space interfaces...the new airjack will include an airjack specific interface, and that is all you need to configure any airjack device, this is desirable so that the same code can easily configure a linux airjack driver, as well as a bsd airjack driver... however, every os abstraction layer will also be required to support that platforms existing legacy configuration interface...this is so that legacy apps will still work, and it will easy the switch...i dont plan on removing this any time soon so you can count on it being there... the new airjack drivers are going to support all the operating mode including station, adhoc, adhoc master (where applicable), host AP, and a couple special airjack modes (ill describe that in a later email), obviously not all drivers will support all modes but we should do our best to make them all work...for releases this weekend dont expect anything but station mode and airjack modes to work...also dont expect encryption of any kind to work at this point... i will in the future be supporting all encryption modes, plus WPA, tkip/mic, aes, and many more as well as a number of other user development forms (such as wep with a repaired KSA, etc)...it should be made easy for all cards to use all forms available even if their hardware does not (we will need to set many of them in host encrypt mode and do it on the host cpu in those cases)...we should make it easier for people to develop such techniques on airjack drivers... one of the reasons why security has been so bad on wireless had been in part due to the difficulty of average developers getting access to test out their ideas and have their code supported on a large number of platforms,one of the goals of airjack is fix that problem by making it easy for developers and researchers to rapidly develop and prototype new security features for 802.11 networks, as well as prototype research tools to test the security of existing security measures... actual code details for this API (enough to start you working on chipset drivers) will be released late to night to this mailing list...this and other emails i will repost a few times because i know many people are not signed up yet (still hung over from the 4th and whatnot ;)... timball: start gathering up atmel chipset info if you could, ill email out the hardware layer structure to the list tonight id like to try to get this working on those crappy atmel cards you have at about the same time i finish my port to prism2 and aironet...also, and maybe more importantly i want frequency hopping support on that symbol card of yours (please tell me you still have it), so track down as much as you can on that as well... anyone else: even though i just said i was porting aironet driver to this, i cant release those that i am writing due to conflicting NDAs, i am however writing it up privately not for release to verify that it can be done easily by someone else... i am currently looking for volunteers to take exiting GPL'ed aironet code and porting it to the airjack framework... i am also under NDA with atheros, and as such i cant release my ar5k drivers, however i am writing them and i am testing out the cardbus bus layer to ensure that development of them is very possible and pretty easy...there are GPL'ed drivers out for these so i am hoping to get someone to help with these as well (i have one taker for this, but i really want this support before the DefCon release guys)... as for broadcom and intersil 802.11a/g chipsets, i currently have no NDAs so i am going to be reverse engineering the windows drivers (did you hear me DMCA *flips DMCA off*) and getting this going for those as well...anyone that wants to help with that is welcome... any questions should be directed to this list if possible guys...expect me to be off and on all the rest of the weekend as i have alot more code to finish to make my monday commitment... --Abaddon |
