dark_pyrro

Tried running it with sudo?

That's probably because the links "broke" as the GitHub repos where re-arranged when the Mk2 Squirrel was released.
Just visit GitHub directly instead to get access to the payloads. Be sure to select the correct directory structure depending on if it's a Mk1 or a Mk2 Squirrel.

What product was detecting it as malware and did it provide any information of why it was detecting it?
The text below is from a quite recent post by the Hak5 head dev of Cloud C2
"Question: "C2 cloud download from hak5 says it has malware"
Answer:
**TLDR; its a false positive. CloudC2 contains no malware nor anything malicious. **
This is an unfortunately (and ironically) a side affect of providing our software in an *easily accessible zip for all architectures*.
This arbitrary determination by random AV scanners is unfortunate and **nearly impossible to combat.** AV detection is a game of "if my AV detects it and yours doesn't, mine is better" so even false positives spread like wildfire. Understandably because in the case something is actually malicious this protects more users quicker (something we can all appreciate).
So what nuance are these AV companies missing in their determination of Cloud C2? 
Architecturally Cloud C2 is designed to** only communicate with Hak5 devices**; there is no way to even abuse Cloud C2 to provide access to even the host its running on. The executables don't even communicate with the host machine they run on -- this is both by design and for your privacy and security; *Cloud C2 is effectively a sandbox*.
We expressly provide the sha256sum of the archive, and within the archive a list of sha256sums of each individual binary so that you can be sure they haven't been intercepted or tampered with. Each binary is built and tested by us in house from the same codebase and then provided to the user via our own hand built infrastructure so that you can be sure no one is able to alter the software nor track you.

**In even more detail:**
The combination of features Cloud C2 provides, from a *blindly heuristic perspective*, has just fooled many scanners into** false positive**; looking to naive data models that it "could be used maliciously" due to the fact that it:
- requires a token and a license key to access; providing security and ensuring you're the only one who can complete the setup process
- contains a self contained web server that can communicate in a custom protocol scanners have never heard of and don't understand (expressly so that your Hak5 devices are secure when using Cloud C2)
- supports https and uses aes256 to communicate with Hak5 devices, making traffic uninspectable
- contains a ssh server so you can remotely shell in (only) to your registered devices with a single click
- supports one click OTA updates as a self updating binary
- contains a cross platform compatible database architecture
- contains a fully built-in web ui (which would appear as an embedded file system)
-  supports user accounts with fully configurable role based access control for your data security
- supports full audit level internal logging of requests made to your server and actions taken by your server users
**All with zero external dependencies packaged into a single executable.**
The **only communication Cloud C2 server makes**:
- directly with your Hak5 devices you've explicitly registered with your server,
- to validate the license and only the license information."

There is perhaps an increased chance of getting an answer if instead posting in the Mark V section of the forums. However, most likely not that many around that has Mark V experience though (or devices to be able to recreate the issue).

You could only use the Ducky as the keyboard automating the adb stuff. You would still need some device to actually have adb installed. I've done it using the Bash Bunny, but it depends on your use case.

As I posted on Discord, ssh doesn't work out of the box, you will have to hack/tweak the Crab to enable that. But it will also void warranty since you're not expected to do such things to the Crab. As soon as you start to change things, you're really on your own (at least when it comes to any claims against Hak5 as a company). One important thing to remember when it comes to the Crab (compared to other Hak5 devices), is that there is no "factory reset" option. So if you get stuck or brick the Crab, you can't easily revert it back to an "out of the box" state. Therefore, it's important that you don't do things that you haven't got the knowledge to back out of (if it's even possible to back out of it). If you, despite the warnings, try to do things to the Crab, you will most likely start by accessing it using hardware serial and go from there. It's not the "ordinary" Linux box either, it's Android based which also requires some extra knowledge when it comes to how that OS "branch" works. I've got ssh set up on my Crab along with a web server, etc. etc. But I wouldn't at all recommend it if you don't know what you are doing and the risks that comes with it.

The original ones should be 5 dBi omni directional 50 Ohm RP-SMA and designed for 2.4 GHz

I temporarily switched over to the Key Croc since it makes it easier to develop/test payloads instead of blindly run things using the Bunny with the help of LEDs, log files, etc.
Got it to work in the Croc and then went back to the Bunny (used a Mk1 Bunny, but that won't make any difference compared to using a Mk2 one).
This is the payload I used. The payload can for sure be a bit more "pretty" (while loop to wait for target IP address, etc.) but it works for a PoC scenario.
Getting the target IP can instead be made in the more "usual" way (i.e. using GET TARGET_IP)
ATTACKMODE ECM_ETHERNET sleep 5 TARGET_IP=$(cat /var/lib/dhcp/dhcpd.leases | grep ^lease | awk '{ print $2 }' | sort | uniq) /usr/bin/adb tcpip 5555 sleep 1 /usr/bin/adb connect ${TARGET_IP} LED FINISH  

From where are you trying to clone the repo? From the Bunny?
If this is from the Bunny (I assume it is judging from the errors posted this far), is your Bunny connected to the internet? In what way?

However, it's possible to "force" adb to be installed on the Bunny. Did the operations below and got adb to execute. Not sure if there are more things needed to be installed for specific adb functionality, but that will probably show in one way or the other when using it.
wget --no-check-certificate https://archive.debian.org/debian/pool/main/a/android-platform-system-core/android-liblog_7.0.0+r33-1_armhf.deb dpkg -i android-liblog_7.0.0+r33-1_armhf.deb wget --no-check-certificate https://archive.debian.org/debian/pool/main/a/android-platform-system-core/android-libbase_7.0.0+r33-1_armhf.deb dpkg -i android-libbase_7.0.0+r33-1_armhf.deb wget --no-check-certificate https://archive.debian.org/debian/pool/main/a/android-platform-system-core/android-libcutils_7.0.0+r33-1_armhf.deb dpkg -i android-libcutils_7.0.0+r33-1_armhf.deb wget --no-check-certificate https://archive.debian.org/debian/pool/main/a/android-platform-system-core/android-libadb_7.0.0+r33-1_armhf.deb dpkg -i android-libadb_7.0.0+r33-1_armhf.deb wget --no-check-certificate https://archive.debian.org/debian/pool/main/a/android-platform-system-core/adb_7.0.0+r33-1_armhf.deb dpkg -i adb_7.0.0+r33-1_armhf.deb  

This should work (it at least does on one of my lab/test systems, not CAFR though)
STRING This is a full string with a ^ SPACE SPACE STRING few d¨ead k^eys combo  

You can try the PowerShell script I wrote that downloads the C2 binary. It won't let you learn that much about the process, but it will get you started (and it's not that much to learn really, since it's a simple thing to get C2 up and running even if you do it all "manually").
https://codeberg.org/dark_pyrro/CloudC2-DL-script-PowerShell

Some users got Squirrels that didn't have the correct firmware flashed from factory, but that was really early, even before it was officially released. Not at all sure if this is the case here, but I would suggest submitting a support ticket to get assistance.

I wouldn't worry that much about the specs with such requirements. Just install it and run it and you'll figure out when the hardware is the limiting factor. Using the RPi you mention will most likely be just fine to start with if just using a very few devices that isn't that active.
The same thing goes with the scenario if scaling things up, just test with what hardware you have available. And, if planning for 20-30 devices, you need to step up from the free community version and buy the Professional version, and in that case you should have access to standard support (not just community support) and can most likely ask official support about any hardware setup suggestions depending on your use case scenario.

Yes, you need to QUACK things. The author is a competent user, so I'm not sure why it has been forgotten. Perhaps too quickly "converting" it from the USB Rubber Ducky to the Bunny.

Even if 1.1.1 works fine, there's still a potentially faulty flash storage device, and you don't want that. Just because you're running 1.1.1 doesn't make it go away, it's still there.
https://hak5.customerdesk.io/

If it stops after the execution of
Then, I would probably focus on the line
The part
is more commonly used (according to my experience) on a Ducky to get a drive letter.
So, either you most likely need to wrap it in quotes and also escape special chars, or use another way of obtaining the Bunny drive letter using a PowerShell session instead.

I'd suggest that you open an issue report on the GitHub of the LaZagne creator. That doesn't seem payload, or Bunny, related. It's sounds more like something to do with Python (since the LaZagne exe seems to be Python based and that an exe is created using pyinstaller or such).

Darrens GitHub was "cleaned" when the 2nd gen Ducky was released. One reason was probably that users started to flash the firmware of the 1st gen Ducky on the 2nd gen one which rendered the new Ducky inoperable/useless.
To get hold of 1st gen Ducky firmware files and flash utilities, try the following links. Remember though that these links aren't official sources, so using them is at your own risk!
https://code.google.com/archive/p/ducky-flasher/
https://github.com/midnitesnake/usb-rubber-ducky

https://github.com/hak5
https://github.com/hak5/bashbunny-payloads/tree/master/languages
 

It all depends on your setup (of which I know very little of, which also makes it difficult to troubleshoot). If you have a firewall somewhere between your Hak5 device(s) and the C2 server, then you'll have to open the ports needed (which is specified in the documentation).

Did you try to just let the Pineapple itself download the update by issuing a check from the web UI (instead of manually trying to "sideload" the firmware update to the Pineapple)?

Try running
opkg update again, since you have issue downloading the Hak5 "package feed"

it's basic Linux and you can find how with a simple search, you use the date command with options/parameters to set the date, such as
date -s "yyyy-MM-dd hh:mm:ss"
 

If you need more specific details about compiling from source, then it's not the path you should walk.
The correct way to install is as you mention, but... there are dependencies that aren't met regarding libpcap specifically which stops tcpreplay from executing even if you installed it in the way it's supposed to be installed.
You could try (as I mentioned in a previous post) to create a symlink between the already existing libpcap file and the one tcpreplay wants. Might not be optimal and "unorthodox", but it could make it run.
libpcap should be located in /usr/lib
so...
cd /usr/lib
Create a symlink (this is the possibly "unorthodox" thing)
ln -s /usr/lib/libpcap.so.1 /usr/lib/libpcap.so.0.8
ls -la (or ll) on /usr/lib/ should show the created symlink in the directory listing
libpcap.so.0.8 -> libpcap.so.1
Execute tcpreplay