dark_pyrro

Try ssh -oHostKeyAlgorithms=+ssh-rsa root@172.16.84.1

What computer/OS are you attaching the Turtle to? Have you tried other computers? If networking breaks on the computer when you attach the Turtle, that sounds a bit suspicious.

That operation should be no problem. The first of your ssh options should work. To be able to troubleshoot further, more information is needed. Is the Turtle brand new out of the box or have you used it before (and being successful accessing the Turtle using ssh)? If you have done something with it, then what have you done? Any module(s) loaded? Anything installed using opkg? etc.... The last resort is probably to do a factory reset.

Not sure if you're the same one asking about the (kind of) same thing on Discord, but the upgrade procedure is in the documentation. https://docs.hak5.org/cloud-c2/guides/upgrading-cloud-c-editions

I would suggest starting a conversation with Hak5 support about the matter first and see what options that are available before you start trying to do things on your own that might make it worse (does not necessarily needs to get worse, but you never know).

I have never tried MT7612 chipset based adapters with my Nano. Mainly because of the fact that I more or less stopped using my Nano when I go the Mark VII. I always used an RT5370 adapter with my Nano. Just try and see if it works.

You may have a Pineapple that has a bad flash storage device. I guess the flash issues shows when flashing 2.x firmware and 1.x based firmware works. This is because of the fact that 1.x doesn't care about (or check for) flash errors, but 2.x does.

This should be posted in the Bash Bunny section of the forums, not here. The Ducky Script payload you are trying to use are missing things. You need to QUACK the commands. That json file looks like it has a lot of crap in it.

I guess you are about to use it in some other scenario than trying to crack an Android lock screen PIN. It has been years since this was patched (well, if you have a really old Android device with an old OS that hasn't been updated, then it might work). Not really sure what script you are looking for since there are examples available in the posts/threads/videos that are mentioned. Recreate the "one liner" that Darren shows in the video below, it should take care of it in terms of generating the Ducky Script code. But, as said, not sure how it would be helpful since it won't brute force any modern device. https://www.youtube.com/watch?v=yoYiEkk5TyI Even if you can't afford a second computer, you can still run Linux without the need of involving Cygwin. Just install something that allows you to install virtual machines on your already existing computer, like VirtualBox. Then install some Linux based OS as a VM and use Linux as a "full OS". You can probably use Docker as well, but I seldom do that myself.

As said previously in the thread, post Bunny related things in the Bunny section of the forums. And, when you do, provide as much information as possible about your specific scenario to take most guess work out of it all when trying to help to troubleshoot. What Bunny generation are you using? Mk1 or Mk2 or both? What OS is the computer using that you are trying to run bunnyupdater on? What firmware is your Bunny currently on? Any specific error messages or the same that has been posted before? etc...

Well, the flash storage check is implemented in v2.x and that's why you have issues. There's no way around it since your Pineapple most likely has some kind of faulty storage if you can't get 2.x installed without storage issues. The only way is that the check is removed from the firmware, not implemented (and my guess is that it won't be removed). I advised you to contact Hak5 support in the other thread where you mentioned the same kind of issue a while ago and I'd suggest you to still do the same.

You mean that you have the captive portal somewhere outside the Pineapple? Never seen that before using the Evil Portal module specifically. I guess you have to make changes in the extent that it's rather pointless to use the current Evil Portal module as a base for it. Try creating a new module from scratch instead or just simply start digging into the code of the Evil Portal module and make the changes needed. But, as said, my guess is that you have to tear down a perfectly well built "house" to the ground to create a new one. So, better to start off from scratch in that case.

I guess the networks you have tested weren't all hidden networks, or? If you try to connect to hidden network, you have to add a line to the wpa_supplicant.conf file. Also (but that's pretty obvious), you have to connect to a 2.4 GHz network/AP.

There's no SIM card in the Ducky (assuming that's what "sim cart" is referring to).

Just to be sure, previously it seems as if you have the new Rubber Ducky. Using the java encoder isn't possible in that case (well, perhaps if you stick to DuckyScript 1.0 features only). If you, however, actually have the classic Ducky, then use version 2.6.4 instead. In any case, the Java based encorders are more difficult to find since they aren't supposed to be used anymore. It's either payload studio or the JSEncoder (that makes it possible to use a language file).

You really dug deep to find this thread. However..... have you tried to "lock" the channel using airodump-ng before issuing the aireplay-ng command?

second (first loser at least 😁)

I'm not sure how this would benefit the Rubber Ducky. Explain the functionality and scenarios where it's relevant.

Since this thread is over 10 years old and covers BackTrack, more info is needed. What distro are you using? Is the problem showing in the same scenario as for the original thread creator?

If you get a static public IPv4 address with the DigitalOcean droplet (you should, I at least got one when I did a test a while ago setting up a C2 server on DigitalOcean), I'd suggest using that IP address in "clear text" when starting the C2 server as a service and not mess around with variables. To get the variable populated, the use of .bash_profile is probably not the way to go since that won't be "executed" until login of the user. To make it work at boot and "system wide", I would most likely use /etc/profile (however, I would avoid using a variable, as said). If you haven't already, then use the docs that describes setting up a service for C2 (it looks like you have though judging from the paths used in your previous post). https://docs.hak5.org/cloud-c2/guides/enabling-cloud-c-as-a-service-on-boot-and-exfiltration

If doing it that way, I would separate it all to not get faulty inputs to the start of the C2 server. First of all, I would start the C2 server with any of the IP addresses and skip the command that is included. Just to make sure that the C2 server starts as intended. If I would use that way of getting hold of the IP address, I would most likely separate it all and put it in a bash script and first put the IP address into a variable, then use that variable when starting the C2 server, something like: #!/bin/bash IP_ADDR=$(ifconfig eth0 | grep 'inet ' | awk '{print $2}') LISTEN=$(ifconfig eth0 | grep 'inet ' | awk '{print $2}') /path/to/c2/binary/c2-3.2.0_amd64_linux -hostname $IP_ADDR -listenip $LISTEN (Not sure I would use the listenip parameter though if there is no real reason to, I know I'm not for my C2 server).

Can you resolve the hostname of the server on the Croc? Also check the cc-client error log on the Croc. I think it's in /tmp (if I remember it correctly). And, as said, that eth0 entry in the device.config file looks odd. Are you using that as a parameter in some way when starting the C2 server? In addition to the above, you could also execute cc-client and look for errors, or run C2CONNECT (don't remember if it's on the Croc, but pretty sure it's there, I don't have the Croc around at the moment so I can't check).

Not sure what that eth0 is doing there. Your hostname should show. What about the other things I mentioned in the other post? What other thread with 8 pages are you referring to?

You can read some things to try in the other thread where you recently posted about the same thing.

I guess this is the same question/scenario/use case that you have already been posting in other sections of the forums. It's probably a "yes" and "no". You could most likely produce alerts if "someone" passes by ("someone" meaning any non specific individual). But, if you want to pinpoint a specific (identified) person, then it's most likely not possible if modern devices are used. This is because both Android and Apple based devices randomize MAC addresses exactly because of the fact that they shouldn't be possible to be tracked/geotracked.