dark_pyrro

Just some comments: Should be /etc/apt/sources.list And aren't valid commands, it should be apt update apt upgrade However, I would be careful to do an upgrade. It might work, but can also possibly break Bunny functionality. It's possible to add [trusted=yes] to each line in /etc/apt/sources.list but it will probably not be stopping apt/dpkg from complaining. Also, when installing packages using apt, it's possible to add -oAcquire::AllowInsecureRepositories=true For example: apt install build-essential would be apt -oAcquire::AllowInsecureRepositories=true install build-essential Errors will most likely still show in some form or at some point, but Jessie is an old distro release so not that surprising.

Streaming tcpdump output directly to Cloud C2 isn't something that is built-in as far as I can remember off the top of my head. It's possible to remotely stream tcpdump output to remote Wireshark sessions though, but that's another use case scenario.

What "proxy network"? You have already told that you can't access Google based services (which was the reason to need to sideload modules), so how would you be able to ping Google if it's restricted/banned?

You will probably want to run it with the "package" parameter to get the tar.gz file ./build.sh package

That's most likely because there are some bad CR handling in the files you've downloaded. Probably not because of the files themselves, but some local setting that seems to add bad carriage returns (^M) to the script file. Could be Windows line endings that Linux doesn't like.

So, you totally skipped what I previously told you about using the build.sh script?

What kind of "direct copy"? Did you just copy things straight from GitHub to the Pineapple file system?

The dev stuff shouldn't be installed on the Pineapple itself, but on some other device/computer.

Start by reading the module development documentation. You probably need to use the build.sh script in the directory of the module you want to sideload to create the tar.gz. This will require that you have some tools installed such as npm https://hak5.github.io/mk7-docs/docs/modules/modules/

If you can't get the Pineapple to run via VPN and circumvent possible restrictions, then you can probably download modules from the Hak5 GitHub repo and sideload the modules manually to the Pineapple.

I've heard rumors (probably via ChatGPT) that MrJaMilne dropped the dreams of pursuing a cybersec career and instead started a pig farm in Idaho a few years ago.

The only more detailed info that I know of when it comes to antennas is what's available in the FCC test report on page 5 https://fccid.io/2AA52MK58

The ways you mention are the best ways. Either official customer support (not community support) or using the email that order information was sent out from Hak5. The few times I have needed to ask something about an order, I've just replied back on the order email from Hak5 and almost gotten instant response. One thing to remember is that Hak5 isn't Ford or Sony, it's a small number of people taking care of support and all other things related to running a business. That might make it take a while longer although I can understand some part of the frustration if needing to wait for weeks.

Yes, I've experienced that on Linux based computers. I've seen others that has had similar issues as well. Not really had any reason to dig deeper into it though since it's not my main target environment when using the Bunny. I have made some tests using the USB Rubber Ducky on the same PCs and haven't been able to recreate it, so it could perhaps be Bunny related. If you need this to work and want to report it, then I'd suggest creating a support ticket.

Answered in the other thread where you asked about this.

I wouldn't agree to the fact that Python 3 is installed as a dependency when just installing the mentioned packages. I would have noted that when I was working on the previously linked instruction on how to get a more recent version of Impacket on the Bunny. I did quite a lot of iterations before I had sorted out all the issues that was involved in getting that working so it would have been quite obvious that any Python 3 version installed by apt would need to be removed first (and that would be a part of the instruction in that case). When you say that the older responder.deb works; does it work in the way that it just runs or do you get NTLM hashes from a target? What OS is the target running in that case? A fully updated Windows 10 or 11? Just curious.

This is most likely due to the fact that Python 3 was installed using apt before you built Python3 from source. I would recommend purging the version installed using apt, or simply do a factory reset to start with a clean slate and not install Python 3 using apt, but only build the relevant version for Responder.

To really make sure netifaces is installed and available for Python 3, then enter the Python 3 prompt, by running: python3 Enter: import netifaces There should be no error message(s) if netifaces is installed correctly for Python 3 Just to test it further, list available interfaces: netifaces.interfaces()

Also make sure you install netifaces for the correct Python environment (not for Python 2).

I quote myself If you use "python" only, you should under normal circumstances be starting Python 2 on the Bunny. To use Python 3 you need to specify it when starting Responder, i.e. use "python3" (both manually at the command line or in the payload script), not just "python". There is a shebang on the first line of the Responder.py file that could/should make the script use python3. Better though to start Responder with python3 from command line to be sure it is used.

The LED sequence seems a bit odd. It shouldn't do it that way if either succeeding or failing (failing not equal to "LED FAIL" as per the payload script, but failing to get loot). I guess that Responder fails due to the fact that the payload is using a Responder command line option that is deprecated if I remember it correctly ==> "-r". If you run Responder manually and include the option "-r", it will abort. That could be the reason why the loot directory is created (since that is happening before Responder is executed), but nothing else happens. If Responder was successful in running the payload, it would blink yellow until it got some loot (i.e. some file named something including "NTLM").

Not quite sure what you mean by that. You let the Bunny run whatever payload is available in the switch position you select. If you select switch position 1, it will run the payload in the switch1 payload directory. And the same logic for switch2. If you haven't purged Python 2 (or created some symlink that starts Python 3 when typing "python"), you should start Responder with python3 specifically, otherwise Responder will start with Python 2.

Perhaps because there are no cookies, pictures, form data or such in a txt file

Well, it doesn't matter. I still can't see that it's mounted as storage. Try to format the card using gparted (or such) in EXT4 and only one (1) partition (no label). Then just insert it and don't let the Nano format it (using the "tool" in the web UI). Make sure fstab looks like how you pasted in an earlier post, but without the swap part. Also make sure there are no spaces in the paths. The paste you did in the previous post includes spaces and that will not work. The "device" path most likely needs a change. For example: option target '/ sd' option device '/ dev / sda1' Should look like this: option target '/sd' option device '/dev/sdcard/sd1'

It should work, I know since I've done it several times. Time may change things though, so what was working a bit back in time may not work now. The apt stuff is most likely because of the fact that Jessie is old nowadays and it's not strange that such errors would occur. Getting a more recent debian-archive-keyring package could solve it and/or edit the sources.list file. Or, use apt-key to import keys from a key server (if available).