dark_pyrro

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.

Perhaps try GUI + backspace

Well, 12 is 12 and not 17, so nothing much to do about that really
Space isn't possible to use according to the specs since it's not alphanumeric

Note that C2 isn't a command in itself. What Darren is doing in the video is pressing tab (twice probably) to make the system "reveal" what known commands that starts with "C2". In any case, the available C2 commands should be located in /usr/sbin and those are the same that is shown in the video at about 8:20. If the commands aren't there, you should probably check what firmware version the Turtle is running. I can't see any reason why the Turtle should be on anything else than a version that supports C2 (which should have been introduced from version 5), but check it anyway to be sure.
The firmware version should be available in the top left corner of the Turtle text based UI/menu system, or by checking the file
/etc/turtle/VERSION

If you have an ordinary USB storage device attached to your computer; how do you safely eject that storage device before you remove it from the computer? That's the way you unmount the Croc. The reason why you should do that is because it's not a good thing to have a storage device mounted to two different devices at the same time (in this case your computer that the Croc is attached to, and the Croc itself). This might lead to corruption if not doing things correct.
Note though that unmounting the Croc from the computer does not involve physically removing the Croc from the Computer since you still need to be able to access the Croc. It just involves ejecting/unmounting the Croc from the OS, not removing it from the USB port.

Sounds like a parallel discussion on Discord. In that case it was the USB cable.

Have you tried switching NETMODE in the payload?

It's of course possible to change the IP range, it's just OpenWrt. Nothing I would recommend though since I prefer to keep things using the default settings.
Removing the already existing stuff from known_hosts (or equivalent name depending on OS) isn't that annoying, I do it all the time when flipping between devices.

OK, I put the code up on Codeberg, use it if it fits your needs. It can be trimmed down if not in need of any logging or such. As said, it's just something simple I put together and hasn't been used that much at all, so there is for sure room for improvement or tweaking.
https://codeberg.org/dark_pyrro/Shark_Loop

Difficult to say. It sounds like the boot loop the Bunny was affected by way back, but it's not possible to use the same procedure to try to get the Croc out of any loop (if it's really a boot loop). Could be that the firmware/update file is stuck on the udisk for some reason and therefore the Croc tries to update every single time it's booting up. A factory reset/recovery won't help, most likely, since the udisk is left untouched (at least the majority of it) after an update or factory reset, so any "garbage" firmware file will still be there. I'd suggest submitting a support ticket.

Not sure why you are using INJECT_MOD

Be more specific about what's not working
Don't (or actually DON'T!!!) flash firmware variants that aren't supposed to be used with a specific product. The SJC firmware is for the SJC only.
Why not just read the official documentation, then you would have gotten answers to some things that you seem to have issues with (however, still not fully clear what those issues are)
See comment below on screenshot 2.
 
Regarding the screenshots specifically:
Screenshot 1; nothing strange here, it's what the "menu" looks like when executing that script, please be more specific about to which issue this is related
Screenshot 2; still nothing strange, you have probably (or; you have) been running ssh against that IP address (probably sessions against the Shark before and after the firmware update) and you need to remove that entry in known_hosts to be able to run a ssh session against that IP again, it's just standard ssh behavior, nothing Shark related specifically, just basic "ssh knowledge"
Screenshot 3; nothing strange here either when operating the battery based Shark, those commands are simply not available for the battery version (and some of those executed aren't even commands)
In detail...
HELP - not a SJB command
UPDATE_PAYLOADS - not a SJB command
from the official documentation
"The UPDATE_PAYLOADS command was introduced with firmware 1.2.0 on the Shark Jack Cable and requires an internet connection."
https://docs.hak5.org/shark-jack/managing-payloads/untitled
LIST - not a SJB command
the official documentation has a typo here since it refers to the ACTIVATE command when making it clear that the LIST commands is for the SJC, but... anyway... it's not available on the SJB
https://docs.hak5.org/shark-jack/managing-payloads/the-list-command
LIST_PAYLOADS is just an alias for the LIST command, so the same goes here as for the LIST command
ACTIVATE and the alias ACTIVATE_PAYLOAD - not a SJB command
from the official documentation
"The ACTIVATE command was introduced with firmware 1.2.0 on the Shark Jack Cable"
https://docs.hak5.org/shark-jack/managing-payloads/the-activate-command
UPDATE_FIRMWARE - not a SJB command
from the official documentation
"Shark Jack Cable users may conveniently upgrade their device's firmware by running the UPDATE_FIRMWARE command"
(and then the word "Shark Jack Cable" is mentioned in almost every step in the instruction, so it's quite obvious it's not for the SJB)
https://docs.hak5.org/shark-jack/software-updates/over-the-air-upgrade
The commands above, and the fact that they are "SJC only, can also be read here
https://docs.hak5.org/shark-jack/getting-started/default-settings#shark-jack-helpers-and-commands
 
So... all in all... I can't see anything being wrong with your battery based Shark, it's exactly as it should be and according to the official documentation (if there isn't any other issues that can be more specifically described in order to troubleshoot it).

It depends on what you want to do, and how
I think using uci is far easier if the settings are a part of what's within the "uci scope"
To show not just the value, but the whole "uci path" as well, for a LED setting (using red LED as an example here):
uci show system.led_red.trigger
To show just the value itself:
uci get system.led_red.trigger
Set a value for a LED color:
uci set system.led_red.trigger='default-on'
uci commit system
/etc/init.d/system restart
Addressing green and blue is done in the same way:
uci set system.led_green.trigger='off'
uci set system.led_blue.trigger='off'
Possible trigger settings should be:
default-on
off
heartbeat
netdev
    with extended options for netdev specifically:
    option mode 'tx rx'
    option dev 'eth0'
    option dev 'wlan0'
    option dev 'wlan0-1'
    option dev 'wlan0-2'
    option dev 'wlan0-3'
    option dev 'wlan1mon'
    option dev 'wlan2'
    option dev 'wlan3mon'

In what way are you encoding your payload?

Try using this URL instead
https://c2.hak5.org/download/latest

I guess you got your answers on Discord

https://hak5.customerdesk.io/

There might be inhouse plans since the new Mk2 Packet Squirrel comes with a web UI in the same design (more or less) as the WiFi Pineapple. Not sure if it will reach the Bunny though. The idea is good, but there's one "obstacle"; the Bunny doesn't naturally do networking. Arming mode is serial and storage and you have to craft a payload to get networking up and running and that also depends on the target OS (RNDIS or ECM). Most beginners are probably using Windows, so RNDIS would perhaps be the most common. Mac is however also a "beginner option" and that requires ECM (AUTO_ETHERNET can be used though). My guess is that if this is going to be the beginner friendly option there needs to be some changes to how the Bunny operates out of the box to make it really smooth. Networking support is key to get this working. Perhaps a new fw release with new option(s) to the config file where you can set "WEB_UI ENABLED" (or such). Another thing to consider developing some kind of support for is to get the Bunny online via ICS in the simplest way possible (and without making the "proxy machine" being internet-less in the process which happens in a lot of the cases).

Try "moduleName":"evilportal" instead of "name":"evilportal"

Just checked now. Using ICS is possible on the Croc. It uses the same settings as the Bunny (not that surprising), so if following the ICS guides for the Bunny, it should work for the Croc as well. I set ICS up on a Win11 box along with the Croc and it plays ball (of course disabling any WiFi connection/setup first to be sure the Croc actually use the usb0 interface to connect to the outside world).

100 Mbps

This should have been solved by parallel Discord discussions on the same subject

https://github.com/hak5/usbrubberducky-payloads/tree/master/payloads/examples/Exfiltration
https://github.com/hak5/usbrubberducky-payloads/tree/master/payloads/library

Try this (working for me, using another exe though, don't want to wait...)
DELAY 3000 GUI r DELAY 250 STRINGLN powershell DELAY 5000 STRING Invoke-WebRequest -Uri https://github.com/notepad-plus-plus/notepad-plus-plus/releases/download/v8.5.4/npp.8.5.4.Installer.x64.exe -OutFile npp.8.5.4.Installer.x64.exe; Start-Process .\npp.8.5.4.Installer.x64.exe -Wait DELAY 250 ENTER DELAY 10000 LEFTARROW DELAY 500 ENTER  

wlan0