scapy update from 2.3.2 to 2.3.3 breaks pyrit on Arch: 'BitEnumField' object has no attribute 'names'

[ghost]

Updating from scapy 2.3.2 to 2.3.3 recently broke pyrit. I install both scapy and pyrit from Arch repositories, but as far as I can tell, the problematic file is unchanged in this repository (by the way, Arch should really use this repo instead of the Google Code upstream; perhaps, I should make an AUR package?).

Reproducible invocation: cat dict.txt | pyrit -i- -r file.cap attack_passthrough

Result (after 2.3.3 upgrade):

Traceback (most recent call last):
  File "/usr/bin/pyrit", line 6, in <module>
    pyrit_cli.Pyrit_CLI().initFromArgv()
  File "/usr/lib/python2.7/site-packages/pyrit_cli.py", line 115, in initFromArgv
    func(self, **options)
  File "/usr/lib/python2.7/site-packages/pyrit_cli.py", line 163, in new_f
    f(*args, **kwds)
  File "/usr/lib/python2.7/site-packages/pyrit_cli.py", line 912, in attack_passthrough
    ap = self._fuzzyGetAP(self._getParser(capturefile), bssid, essid)
  File "/usr/lib/python2.7/site-packages/pyrit_cli.py", line 179, in _getParser
    parser.parse_pcapdevice(dev)
  File "/usr/lib/python2.7/site-packages/cpyrit/pckttools.py", line 601, in parse_pcapdevice
    self.parse_packet(pckt)
  File "/usr/lib/python2.7/site-packages/cpyrit/pckttools.py", line 614, in parse_packet
    if dot11_pckt.isFlagSet('type', 'Control'):
  File "/usr/lib/python2.7/site-packages/cpyrit/pckttools.py", line 66, in isFlagSet
    return (1 << field.names.index([value])) & self.__getattr__(name) != 0
AttributeError: 'BitEnumField' object has no attribute 'names'

FYI, downgrading scapy to 2.3.2 helps.

[JPaulMora]

Arch should really use this repo instead of the Google Code upstream;

That would be great, yes.

FYI, downgrading scapy to 2.3.2 helps.

Alright, thanks for the info.

[ghost]

Opened a PR with a fix that accomodates both scapy 2.3.2- and 2.3.3+.

[ghost]

Just wanted to let you know that Arch Linux package community/pyrit by Levente Polyak levente@leventepolyak.net now packages this upstream.

[Susan-Susan]

Same problem here. How would I "just downgrade scapy"? What would the exact cmd be? We are using Kali-Rolling.

[strasharo]

@Susan-Susan , there's a defect submitted to the Kali developers for this one: https://bugs.kali.org/view.php?id=3801

[ghost]

@Susan-Susan, unfortunately, Kali doesn't yet have the patch in their repository. This project contains a Python package, which can be installed via pip or setuptools. If you're the one who maintains your Kali Rolling machine, run the following commands:

apt-get uninstall --purge pyrit # Get rid of the system pyrit package
apt-get install python-pip # Install Python v2 package manager
pip install git+https://github.com/JPaulMora/Pyrit@dev # Install newer Pyrit

If your machine is managed by someone else, you should probably link that person to this page; they'll know what to do.

Side note: Kali is kind of an advanced-user system (and they switched to a rolling model to boot); if you want to use it, you'll need to learn how to manage it. At least some basic Debian maintenance know-how (systemd services, aptitude packaging, Python packaging, update-alternatives, popular build systems like Makefiles/Autotools/CMake) would be nice.

[ghost]

@strasharo does Kali still package the unmaintained Google Code upstream? If yes, they should probably follow suit and switch to this active fork (could you please update the ticket with that? thanks).

[Susan-Susan]

Unfortunately, we can't hire additional staff members just to update a program.

"apt-get update/upgrade/dist-update" is regularly run and updates a long, long list of programs without a single problem.

I'm not sure why it specifically skips updating the programs that we vitally need, like pyrit.

apt-get uninstall --purge pyrit # Get rid of the system pyrit package

That just gives: E: Command line option --purge is not understood in combination with the other options

Ugh.

[strasharo]

@bacondropped added it as a note, I have pointed them to the location of the fix in the additional notes of the ticket as well.

[ghost]

That just gives: E: Command line option --purge is not understood in combination with the other options

Oh right, you need apt-get remove --purge pyrit here, sorry about that. Or just apt-get remove pyrit. Tell us how it goes. UPDATE: Since I don't know if all prerequisites are installed on your Kali, you should run these commands beforehand as well:

apt-get install libpcap-dev libssl-dev
apt-get install git

Unfortunately, we can't hire additional staff members just to update a program.

You don't need staff members to update a program, you need staff members who know Linux. Installing Kali for people who don't meet that requirement is like giving hydrazine to a high school class, telling them to make rocket fuel, and then expecting them not to blow up the building.

But if you want a Unix system and you don't want to hire a system administrator, you may want to look into Unix vendors who provide technical support, specifically Red Hat and Solaris. Kali is a community effort, not a commercial product; Pyrit is as well.

Besides, I feel like I'm obligated to tell you that running what's essentially an IT counterpart of an intercontinental ballistic missile while having no clue how to control it is a recipe for disaster.

"apt-get update/upgrade/dist-update" is regularly run and updates a long, long list of programs without a single problem.

None of these commands provide a guarantee that nothing will go wrong, especially the last one.

I'm not sure why it specifically skips updating the programs that we vitally need, like pyrit.

Kali ships the first version of Pyrit, which is no longer updated. This repository is the active fork of that version. A breaking change in scapy, a library used by Pyrit, broke that unmaintained version, and Kali's package repository did not receive the patch. We've informed Kali maintainers of this.

---

@strasharo sweet, thanks!

[bbdetail]

I ran into a problem running pyrit after installing

pip install git+https://github.com/JPaulMora/Pyrit@dev # Install newer Pyrit

I ran the above and it installed successfully with

Successfully installed pyrit-0.5.1

But when I tried running pyrit it said

/usr/bin/pyrit: No such file or directory

It seems that Pyrit puts its binaries in wrong folder than you’d expect. The actual path for Pyrit is now /usr/local/bin/pyrit . To fix this, you can softlink the path to your profile

ln -s /usr/local/bin/pyrit /usr/bin/pyrit

[ghost]

It seems that Pyrit puts its binaries in wrong folder than you’d expect. The actual path for Pyrit is now /usr/local/bin/pyrit .

It's not wrong. /usr/local is where you should install packages that you built yourself (as is the case with installation from Git), and /usr/local/bin should be in your $PATH.