Broadcom bcm43xx Injection

[uovobw]

Hi everyone,
Michael Buesch (from the bcm43xx-devel list) has recently posted an injection patch for the bcm43xx driver.
This driver is found on many devices, including Airport Express/Extreme and a lot of other cards.
The patch has not been tested with the latest aircrack-like tools because of lack of time - i suppose - of the author.
Is someone in the dev team interested in supporting that?
I opened this thread to be a discussion about it, if needed i can post the patch so even those who are not subscribed to the ml can read it.

thanks

[Mister_X]

Here's the mail:
This is a quick and dirty hack to inject packets into the bcm43xx driver.
Note that the driver won't let you send every kind of data blob. The packet must:

• be preferrably valid. I don't know to which extend the card supports invalid packets.
• _not_ have a FCS at the end. (important)

To inject packets, write them to sysfs device attribute "inject_nofcs". use find(1) to find it
Only root is permitted to inject packets.

Note that fragmentation is not supported with this hack.
The packet must include a full wireless header, payload and _NO_ FCS at the end. If your template has an FCS, simply strip the last 4 byte.

This is a hack and it won't go upstream.
If you are interrested in a real implementation of packet injection, talk to the 802.11 stack guys on netdev list.

Patch is attached.

[rexstuff]

The provided patch doesn't apply against the bcm43xx version supplied in the 2.6.17.1 kernel, or at least wouldn't for me. No idea why, maybe just some line numbers changed enough to throw it off. In any case, I edited the source manually and this new patch does work against the 2.6.17.1 kernel sources. Or at least, it builds without complaining. I'll see if I can get the injection working, but I'm probably too much of a noob.

--- bcm43xx_main.c   2006-06-29 09:52:36.000000000 -0500
+++ bcm43xx_main.c   2006-06-30 10:48:11.000000000 -0500
@@ -104,6 +104,13 @@
 #endif /* CONFIG_BCM43XX_DEBUG*/
 
 
+static ssize_t bcm43xx_inject_nofcs(struct device *dev,
+                                    struct device_attribute *attr,
+                                    const char *buf,
+                                    size_t cnt);
+static DEVICE_ATTR(inject_nofcs, 0200,
+                   NULL, bcm43xx_inject_nofcs);
+
 /* If you want to debug with just a single device, enable this,
  * where the string is the pci device ID (as given by the kernel's
  * pci_name function) of the device to be used.
@@ -3158,6 +3165,7 @@
    int i, err;
    unsigned long flags;
 
+   device_remove_file(&bcm->pci_dev->dev, &dev_attr_inject_nofcs);
    bcm43xx_sysfs_unregister(bcm);
 
    bcm43xx_periodic_tasks_delete(bcm);
@@ -3269,6 +3277,7 @@
 
    bcm43xx_periodic_tasks_setup(bcm);
    bcm43xx_sysfs_register(bcm);
+   device_create_file(&bcm->pci_dev->dev, &dev_attr_inject_nofcs);
    //FIXME: check for bcm43xx_sysfs_register failure. This function is a bit messy regarding unwinding, though...
 
    /*FIXME: This should be handled by softmac instead. */
@@ -3540,6 +3549,46 @@
    return err;
 }
 
+static ssize_t bcm43xx_inject_nofcs(struct device *dev,
+                                    struct device_attribute *attr,
+                                    const char *buf,
+                                    size_t cnt)
+{
+        struct bcm43xx_private *bcm = dev_to_bcm(dev);
+        struct ieee80211_txb *faketxb;
+        struct sk_buff *skb;
+        unsigned long flags;
+        int err;
+
+        faketxb = kzalloc(sizeof(struct ieee80211_txb) + sizeof(void *), GFP_KERNEL);
+        if (!faketxb)
+                return -ENOMEM;
+        faketxb->nr_frags = 1;
+        faketxb->frag_size = cnt;
+        faketxb->payload_size = cnt;
+        skb = __dev_alloc_skb(cnt + bcm->ieee->tx_headroom, GFP_KERNEL);
+        if (!skb) {
+                kfree(faketxb);
+                return -ENOMEM;
+        }
+        skb_reserve(skb, bcm->ieee->tx_headroom);
+        memcpy(skb_put(skb, cnt), buf, cnt);
+        faketxb->fragments[0] = skb;
+
+        bcm43xx_lock_mmio(bcm, flags);
+        err = -ENODEV;
+        if (bcm->initialized)
+                err = bcm43xx_tx(bcm, faketxb);
+        bcm43xx_unlock_mmio(bcm, flags);
+        if (err) {
+                dev_kfree_skb(skb);
+                kfree(faketxb);
+                return err;
+        }
+
+        return cnt;
+}
+
 static void bcm43xx_ieee80211_set_chan(struct net_device *net_dev,
                    u8 channel)
 {

[rexstuff]

Allright, apparently I'm a bigger idiot than I thought. The patches are virtually identical, but the first didn't work, no matter what -p# I used. Strange. In any case, the driver is 'working', in the same way it was working before, but I'm not sure I understand what Michael means by writing to sysfs device attribute. He says to use find, but not what to search for. As I understood it, the driver would create another device similar to ethX, and packets could be written to it in a similar manner. My confusion increases in leaps and bounds.

[Guest1]

Michael Buesch wrote:
> To inject packets, write them to sysfs device
> attribute "inject_nofcs". use find(1) to find it

that means to write to the /sys/devices/pci0000:00/0000:00:11:0/inject_nofcs
you should use "find" to search for this file, because the numbers in the path
are different on each computer.

Hope this helped, let me know if you make some progress. I'm really eager
to see a working packet injection on my broadcom 4318 card.

[Mister_X]

4318 doesn't work well on sta mode (txpower very low), don't think about miracles with this chipset :/

[Guest1]

I'm pretty new to packet injecting and I have a question:

How can I tell the packet was injected?

I updated the drivers, but if I write some packets to /sys/devices/pci0000:00/0000:00:0a:0/inject_nofcs, nothing happens. I'm not sure the packet is correct, can anyone send me a correct packet? Should an injected packets count in TX Bytes in "ifconfig"? Because all I see there is a zero.

Thx.

[Guest1]

I played a lot with bcm43xx and the patch and I finally managed to get it working on my 4318 card.
Packet injection works, it injects only a few packets a second, but still, it works.

When I compiled the latest kernel, bcm43xx driver was not working for me. So I used an older version
of it, applied the patch (had to do this manually, cause the source was different, and I also had to
import some other parts of the code, besides the patch), modified aireplay to simply write each packet
to the sysfs file Michael wrote in his post.

And it works!

[uovobw]

I played a lot with bcm43xx and the patch and I finally managed to get it working on my 4318 card.
Packet injection works, it injects only a few packets a second, but still, it works.

When I compiled the latest kernel, bcm43xx driver was not working for me. So I used an older version
of it, applied the patch (had to do this manually, cause the source was different, and I also had to
import some other parts of the code, besides the patch), modified aireplay to simply write each packet
to the sysfs file Michael wrote in his post.

And it works!

this is great news!
do you have a patch for aireplay 0.6 to make it write the packet to the sysfs entry?
even only a list of the lines to change would be great!
thanks again

[rexstuff1]

(apparently my name is no longer valid. Strange)

While I haven't been able to verify if injection works or not, I have been looking at the aireplay-6-ng code, and I can see the areas which will likely need modification.

The bcm43xx injection will work a bit differently than the other cards, because the packet is being written to a regular file descriptor rather than an interface. Currently, the openraw() routine used to initialize the device uses ioctl() calls with SIOC... parameters, which won't work on a regular fd. What will need to happen is the ethX interface should be used for reading packets, and set up as usual using openraw(), but then ouput needs to be redirected to sys/whatever. Setting up ethX as the reading interface using openraw() would also insure that the card has been properly initialised. Also, the ability to detect a bcm43xx card must needs be added. What I don't know is if you can use a socket with ethernet attributes on a regular fd, and what parts of the packet are included by the aircrack program, what parts are added by the socket's ethernet attributes and which are added by the driver (remember: the packet as written to inject_nofcs _must_ be valid but have no fcs).

What I'm guessing Guest1 did was hardwire aircrack to write directly to sys/whatever/inject_nofcs. His mods probably work with his card, but are less than ideal for writing a program to work with many cards, including the bcm43xx.

I'd modify it myself, but I am not confident of my ability or knowledge, or the time available to me. Also, I might be way off base Let me know.

[bBandit]

Followed the instructions here and modified the aireplay-ng source to write to /sys/devices/pci0000:00/0000:00:0e.0/0000:02:0a.0/inject_nofcs with these two lines in the send packet function :

int f = open("/sys/devices/pci0000:00/0000:00:0e.0/0000:02:0a.0/inject_nofcs",O_WRONLY|O_CREAT);
ret = write( f, buf, count );

I'm a really poor C programmer, dunno if this will do. The only thing i seem to be able to do with aireplay is fakeauth. The other attack modes like interactive or arpreplay doesn't generate any traffic. Is this because of the packages being sent is not compatible with the bcm43xx injection hack or is it something i'm doing wrong ?

[rexstuff1]

Again, a hack similar to Guest1's. Ideally: aireplay has the ability to use separate devices for input and output. For input, the standard openraw() routine should be used for initialisation. For output, the routine should be similar, but bind to /sys/whatever and not do any ioctl() calls (remember, we're actually using the same device, just writing to a different location). The input initialisation should be done first, I think. If I could guess as to why you're not able to perform most attacks, the socket you've created does not have ethernet bound to it, a la line 2201.

I could be wrong about all of this, of course. If someone with more knowledge wishes to correct me, I will defer.

I think I might take a stab at modifying it myself, soon. I need to come up with a way to determine if bcm43xx hardware is being used, and a way to get the location of inject_nofcs (command line parameters, perhaps? Get the information from a "find /sys -iname inject_nofcs"?)

As a final word, you should probably get rid of the O_CREAT flag.

[uovobw]

i really have no knowledge, atm, of C and driver-ish programming so i did only some slight modifications
based on what bBandit wrote and i have to say that it does work but it freezes
hard the machine after two or three packets are sent (i think they are, as i can see them from another machine)
I have really no idea about where to look or how to investigate it.
Is there a definitive way to get injection working on bcm?
Like a stable patch or such?
bcm43xxDevels seem to be not interested in it, although i do not understand why, and the issue has been declared "not serious" to be taken
to the netdev team.
Ideas?

thanks

[Guest1]

What I'm guessing Guest1 did was hardwire aircrack to write directly to sys/whatever/inject_nofcs. His mods probably work with his card, but are less than ideal for writing a program to work with many cards, including the bcm43xx.

Yes, that's right. I just simply modified aireplay-ng.c, in the function "send_packet", I added line "int f" just after "int ret", then I replaced this line:

ret = write( dev.fd_out, buf, count );

With these:

f = open("/path/to/inject_nofcs", O_WRONLY | O_CREAT);
write(f, buf, count);
close(f);

It's a *bad* solution, I know, but it works for me, and that's all I want.

[uovobw]

i am recompiling the 2.6.17.6 kernel right now.
I had to apply the patch by hand because both the one provided in this thread and the original one gave errors.
The kernel now compiles correctly.
I also modifed the aireplay-ng.c with the latest modifications.
I will keep updated as i test the whole.

bye

UPDATE:
ok, it works!
i patched both the kernel and the aireplay-ng.c file, upped the interface and used it to deauth my ap and to do some arp-replay on the wepped network i created
on purpose.
I also found that you cannot inject more than 100-120 packets per second or the machine locks up..
a part from that, it just works.
great!
thanks a lot to everyone.
It would be nice to keep this patch up as bot aireplay and the kernel update.
volunteers?