dark_pyrro

You have the error in the output that should lead you in the correct direction My guess is that it's a newer version of libpcap on the system (or available for installation). One "dirty" fix would be to symlink 0.8 to the existing one, but it might result in bad behavior since there could be diffs between what the tcpreplay version expects/needs from the lib and the onboard version.

There's a limitation in C2EXFil that stops transfers of larger files. Might be good to know since tcpdump files can grow pretty quickly.

Ask in the Cloud C2 or Packet Squirrel section of the forums

Ask Shark questions in the Shark Jack section of the forums

In what way should things be "best"? What's the definition and criteria? Define "monitoring". What's going to be monitored? Anything else apart from work hours?

There was a user just now on Discord that reported similar issues. Perhaps it's a bad batch. Not usual, but could happen. Submit a support ticket if the Turtle continues to misbehave.

I would suggest taking the VM out of the equation as a first step. Even if you are able to see the Turtle from the VM and it's possible to communicate with it, it just adds unnecessary complexity to the scenario.

For example: Alfa AWUS036ACM (which has already been mentioned) and Aukey WF-R13, that is the same as EDUP EP-AC1605 v1 (v2 has the RTL 8812 chipset = bad) There are other models based on the same chipset, but if you are in need of external/replaceable antennas, then the ones above are a good choice. I have them both, and actually an AWUS1900 as well that has just collected dust for many years now. Some seem to have a certain faiblesse for Alfa products, and if so, use the mentioned ACM adapter. It has worked well for me in different setups (I have one of my ACM adapters "permanently integrated" with the Pineapple Mark VII). What is the reason for the need of long range? Remember that even if you have "super range" on your end, you might not necessarily be able to "hear" the targets if they themselves doesn't have the equal possibility to transmit over a long range.

Have you ever been able to reach the firmware recovery web page on the Turtle? It's a bit unclear to me. You say and So, from that I assume that you've tried to put the Turtle in recovery mode, but you haven't been able to reach the firmware recovery web page. If so, can you ping the Turtle on 192.168.1.1 when you've put it in recovery mode? Are you getting an IP address in the 192.168.1.0/24 range on the device to which you connect the Turtle? Regardless of getting any IP address, does it show any networking interface at all on the device to which you connect the Turtle, i.e. do you get a network interface showing up? What device are you connecting the Turtle to? OS? I also assume that you are trying to connect to the Turtle using the USB side of it, not the Eth RJ45 port side of it. I can't be the judge of your soldering skills, but pictures of both sides of the PCB where you have done some soldering operations would be good in order to see if there is some bad soldering.

I would say, none of them. As I wrote in the other thread you posted in: I would avoid anything based on RTL881x due to crappy drivers. If you already have one, then use it. But if I would buy one, I would go for something based on MT761x (like the MT7612 chipset that is the same as the MK7AC adapter for the Pineapple is using).

I would avoid anything based on RTL881x due to crappy drivers. If you already have one, then use it. But if I would buy one, I would go for something based on MT761x (like the MT7612 chipset that is the same as the MK7AC adapter for the Pineapple is using).

Just to be sure about the method, are you using the DNSspoof module of the Mark VII?

You have to describe in detail what you're doing so that it can be reproduced by someone else trying to aid in troubleshooting things. Also, what printer (make/model) are you using?

Ask in the LAN Turtle section of the forums, and you might have better luck getting an answer.

A full capture contains all EAPOL messages (M1->M4) along with a beacon frame, as the docs visualize https://docs.hak5.org/wifi-pineapple/ui-overview/recon#handshakes Partial captures doesn't contain everything of the above, but can still be possible to crack. You will need at least M2, preferably along with M1 or M3. If you get a full capture, then use it. Otherwise, just try to crack it with what you got. Use the Hashcat format if you plan to use Hashcat (obviously). There are tons of info out there about how handshakes work and the Pineapple isn't unique in any way in that sense.

I guess you have to time your clicks better. If you can't get it working, just remove the Micro SD card and insert it in some device (computer) using a Micro SD card adapter and delete the inject.bin file (or rename it if you want to keep it for some reason) and then re-insert the Micro SD card into the Ducky.

What have you tried this far? Putting the PS between a target computer and the network, or the network and a target printer? (or something else)

What OS are you using on the device to which you're connecting the Pineapple? What USB cable are you using? The one that came with the Pineapple, or something else? Tried different cables and/or USB ports?

and that is 1.4? Anything is possible, but if you mean using something else than the current Debian version, the answer is no (if you don't care to involve yourself in a ton of work). Do you have any other Hak5 devices that successfully connects to your C2 server? In what way are you running your C2 server? Locally, self hosted on the internet, or some VPS (or such)? Are you running the C2 server manually or as a service? What command line are you using to start the server? (Don't post any IP address or domain name that you might not want to share) The device.config file is in the correct place on the Croc? Is the cc-client error log file in /tmp on the Croc showing any errors? What happens if you try to ssh from the Croc to the C2 server on port 2022? It won't let you log in but it will at least "reply" if things are working as it should.

If that's your conclusion, then do it. It will void warranty though.

Keep things in English, I won't Google Translate that

So, it wasn't actually doing a successful factory reset then (given the LED pattern you describe). Regarding the factory reset process. Can you confirm that you did unplug the Bunny 4 (four) times when the green LED turns off. Just so that I can be sure you understood the instructions in the documentation correctly. The reason why I'm asking is that Bunny users have misunderstood the instructions before and just unplugged it 3 (three) times in total which is not enough for a factory reset. The below (that you quoted from the documentation) is a total of 4 (four) times, not 3 (three).

What USB cable are you using? The one that came with the Pineapple or something else? Try different USB cables and different ports (and perhaps other computers).

OK, judging from your comment, the factory reset is successful then and you get the "police LED" for the set amount of minutes. In what way do you get this? What does it come from? If the Bunny isn't possible to be accessed, there should be no way of getting any error message from it. A specific comment about this; you shouldn't ever do a Debian upgrade on the Bunny since it possibly will break features of the Bunny. It won't fully break it, but you might run into issues that makes it necessary to factory reset it.

Why would you want TwinDuck on the 2nd gen Ducky? I can't understand why there's a need for it.