dark_pyrro

Hmmm, ok, so... the content of the post doesn't sync with the topic anymore. Guess the first "issue" was resolved then. In what way are you starting your C2 server? Using the -https parameter I guess, since it's a log message that related to TLS. Are you using a domain name along with the https parameter? From previous posts, it seems as if you do. (You might also try not posting IP addresses that are "live", but that's your choice if you want to display that kind of information or not). Also, you've posted about something very similar recently in another thread. In that thread you posted that you got a solution. Didn't that solution work?

Try asking in the O.MG related sections of the forums.

I'm asking because I need to get an understanding of what you want to happen when running the payload. I can't see that the while loop would work in any way, partly because the payload code is executed on the Bunny. In this case the Bunny would wait for the Bunny (unless there's some storage device on the Android device that is labelled "BASHBUNNY" that is automatically mounted to the Bunny in some way). Another thing stopping such a scenario to even happen is that the Bunny is just running as a HID device based on the ATTACKMODE used. There is no storage functionality involved. But, I can't see that happen despite using the storage mode for the Bunny. To get that idea to work, the device to which the Bunny is connected has to identify itself to the Bunny in some way for the Bunny to know that it's ready for input. Payloads should be named payload.txt specifically, nothing else (as per the documentation). https://docs.hak5.org/bash-bunny/writing-payloads/payload-development-basics

What are you trying to accomplish with the while loop?

Not sure how the app is relevant to it all. Makes me a bit confused. Isn't the goal to be able to use adb to control the phone from another device (in this case the Bunny instead of a laptop)? I would base the use case on "How am I doing all of this using a laptop?" since it's the laptop that you want to replace with the Bunny (I assume that you aren't running such kinds of apps on a laptop and I haven't investigated further into what it might do since the GitHub page wasn't in English and I don't have time to translate, etc.). Regarding the payload code posted, I assume that it's not working since it's not in a format that the Bunny would fully understand and be able to execute. The lines that contains strings that the Bunny should type needs to start with QUACK STRING followed by a line with QUACK ENTER. I would probably add some delays as well.

Where did you try to set it? You shouldn't set it on that line.

When you factory reset, are you using the web interface or the DIP switches to reset it (probably the DIP switches since you can't reach the web UI)?

My previous post is still valid to that question Reading what the docs say about storage on the Mk2 Bunny kind of says it all https://docs.hak5.org/bash-bunny/getting-started/considerations-for-mark-ii#storage "If ATTACKMODE STORAGE is active: - In the case that a MicroSD card is present, the MicroSD Card will be presented to the target - In the case that a MicroSD card is not present, the internal udisk partition will be presented to the target." So, as the quote above from the docs says; if you use ATTACKMODE STORAGE in a payload, the Bunny storage will be mounted to the target device. This will be true either if using the Bunny internal storage (without a Micro SD card inserted), or if using a Micro SD card. In other words, if you have a Micro SD card inserted into the Bunny and you are using ATTACKMODE STORAGE, then the Micro SD card will be mounted to the target as a "USB drive". This also makes it transparent in terms of how to script things in the payloads used (as long as the Micro SD card is labeled with the same name as the internal Bunny storage, i.e. "BashBunny"). Using the previously mentioned simple-usb-extractor payload, it shouldn't matter if you use the Bunny with the internal storage or a Micro SD card. The payload should work in both cases. If using the internal storage only (not any Micro SD card), it will exfiltrate things to the Bunny internal storage. If using a Micro SD card (labeled "BashBunny", or tweaking the payload to use whatever label the Micro SD card has), it will exfiltrate things to the Bunny Micro SD card.

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

Just tried using Freexian ELTS on one of my Bunnies and it works. Sadly, it doesn't contain an install candidate for adb though.

The situation when it comes to apt update or to apt install things on the Bunny will get worse for each day that passes. Jessie is EOL since long, and even if there has been (or perhaps still are) workarounds available, those workarounds will stop working as time goes by. There is a non official ELTS available for Jessie, but that doesn't cover the full scope of what Jessie once was. You could try the Freexian ELTS, but it's at your own risk. It might work to some extent, or it might not... If successful, one thing that you shouldn't do is run apt upgrade (either using official channels or something else). It will risk messing the Bunny up. Just run apt update and then apt install what you need.

exFAT should be possible to use from the target perspective, so that shouldn't be an issue. However, if it is to be accessed by the Bunny itself for some reason, exFAT won't be a possible option at this time.

If you're asking where the "tools" are installed, it's most often in /tools of the Bunny internal file system. But it all depends on what the deb package tells it to be located/unpacked.

From what I can see, there are 3 payloads in the GitHub library that are using gohttp as a tool requirement.

You have to check any payloads that you plan to use to see if GoHttp is required. Since you shouldn't run payloads "blindly", it will be obvious if it's required when you browse and learn the payload code for a specific payload. I haven't used it myself, it's easier to just run alternatives if needed (but it always depends on the use case what's relevant to use or not).

You can use it along with payloads and store things on it from the target perspective (but not store the payloads themselves on it, those needs to be stored on the internal storage of the Bunny).

Just the maintainer of that can answer if it's valid. Since it's based on/inspired by some work I did some years ago, I would say that it probably needs some tweaking to get up and running. However, I wouldn't walk down that path for different reasons. I would use a different Responder setup instead. Installing things via the tools directory of the Bunny (as described in the documentation) should still work as intended.

One way of getting less confused in that specific case is to not use the Micro SD card at all. I can't see that credentials would fill the internal storage of the Bunny. However, if you still want to use the Micro SD card with the Bunny, I guess you have to be more specific about what the confusion is all about. Why would you want to change the location? It's "dynamically" handled by the script, so I wouldn't try (or want) to change that.

Tried running it with sudo?

What USB cable are you using when connecting the Pineapple to the computer? The one that came with the Pineapple or something else? Tried different USB cables? Tried different USB ports on the computer (or other computers)?

Ask Ducky questions in the Ducky section of the forums.

Just to be sure; you mean that you've executed opkg update, nothing else? What's the output if you cat the GPS device? I.e. cat /dev/ttyAMC0 (assuming that is 100% verified to be the GPS device).

Legal cases or not, random device address is still a feature. And, no, I have no interest in scanning for BLE devices.

I would probably use the REST API. And, instead of using the log, I would most likely tell the Pineapple to capture ESSIDs to pool and then read from the pool using the API and display them on the big screen based on that API result. It depends on if you want ESSIDs to go away from the list after a while or not. You could read the log using the REST API as well, but I seem to remember that there is some bug linked to that specifically. Getting the system log is OK, but when following the API spec it just throws back errors when trying to get PineAP events from the log. There's an unofficial Ruby based "API" as well, but I guess it's best to stick with the officially supported way of doing things.

What tool(s)/language(s) are used when creating the payload?