dark_pyrro

No, just enabling adb over network in the developer settings

I added adb shell dumpsys battery > /root/adb_batt.log to my previously posted payload code and it worked as expected.

Using "adb usb" on the Bunny will probably not work since the Bunny isn't acting as a USB host (? - not 100% verified, but likely). The Bunny is just using USB as a hardware interface for the different modes it can emulate (HID, STORAGE, SERIAL, *NETWORK...) So, it might be easy to try to be "logic" and think "hey, the Bunny has a USB port, therefore it's USB in all ways and forms". But that might not be fully true, it's most likely a USB device (with no host capabilities) at best. This is a possible reason to why "adb usb" works on a device that acts as a USB host (for example a computer), but not on the Bunny. Using the network based approach to connecting using adb (like my payload example does) would be the path I would continue on. Especially since "adb usb" doesn't seem to work, and the network alternative does (at least when I try it). How did you execute these commands if your Bunny was connected to the phone? From the phone itself via serial or ssh?

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

I'm rather skeptic when it comes to the use of GET TARGET_IP before issuing ATTACKMODE ECM_ETHERNET. I can't see how the Bunny would be able to get the target IP before the Bunny is in a mode allowing it to act as an Ethernet "device" (and make the target connect and obtain a DHCP lease from the Bunny).

No real need to use any separate Bash script file since it's possible to run Bash in the payload.txt file (it's treated as a Bash file itself by bunny_framework).

yes, when it comes to the Pineapple itself however, not sure what you mean when saying "installation process" of the Pineapple or Cloud C2? Assuming Cloud C2 because of the choice of where to post the question. By starting to read the documentation and make a decision where you want to run it https://docs.hak5.org/cloud-c2/ Most "problems" you may have read about are probably related to "first-week on the job challenges". It's super easy to set up and run if you haven't got any very specific needs.

Despite the messages you get when checking the service status, is the Could C2 server working? I.e. can you access the web UI? (Excluding the fact that your Pineapple might not connect successfully).

Guess you have to provide more information about your computer setup when it comes to networking to be able to troubleshoot. It seems as if it's the use of ip addr add that throws back the error. What's the output of ip a on the computer to which the Pineapple is connected (without running the wp7.sh script or having the Pineapple connected to start with)?

Why not just try to plug the Bunny into a Windows machine in arming mode or some payload containing ATTACKMODE STORAGE (or use a Micro SD card reader) and then change the label using the standard OS features (i.e. right click the drive letter in Explorer and change the label). You shouldn't need to edit any line. The payload should take care of it if everything is set up correctly. This isn't actually about the Bunny, it's more related to understand scripting basics. However... It's the payload.txt file that kicks it all off and it's the PowerShell line that initially identifies which drive letter the Bunny has on the target system RUN WIN powershell ".((gwmi win32_volume -f 'label=''BashBunny''').Name+'payloads\\$SWITCH_POSITION\z.cmd')" more exact (gwmi win32_volume -f 'label=''BashBunny''').Name For the sake of this "discussion"; let us assume that the drive letter of the Bunny is "D:" and $SWITCH_POSITION is "switch1" Apart from identifying the current drive letter of the Bunny, the PowerShell line also starts the z.cmd file (located in the same switch directory as the payload.txt file) The z.cmd file just "obfuscates" and "silently" runs the next command file; x.cmd (also located in the same switch directory as the payload.txt file) An important thing (at least for the understanding of the payload) is the occurrence of "%~dp0" since it's a representation of the path from where the z.cmd file was executed In this case %~dp0 will be the same thing as D:\payloads\switch1 So the line in z.cmd that says cscript %~dp0\i.vbs %~dp0\x.cmd actually says cscript D:\payloads\switch1\i.vbs D:\payloads\switch1\x.cmd So, moving further in the execution flow, x.cmd is started In x.cmd, the following line is vital to understand how the Bunny is "addressed" using "%~dp0" set dst=%~dp0\..\..\loot\USB_Exfiltration\%COMPUTERNAME%_%date:~-4,4%%date:~-10,2%%date:~7,2%_%time:~-11,2%%time:~-8,2%%time:~-5,2% First thing to understand is probably why "\..\.." is used. Again, this is because of the path that "%~dp0" represents. "%~dp0" is still equal to D:\payloads\switch1 in this example The question now is; "Where is the "loot" directory of the Bunny normally located?" Answer: In the root of the udisk, i.e. D:\ in this case So... the script is "positioned" in D:\payloads\switch1 How do you position yourself in D:\loot ? By addressing it using "\..\.." which changes the position in the file system 2 steps up (to D:\) and the down into \loot (and so on) However, dst is just a variable (or more of a constant since it's not changing throughout the script), but it's used further on in the script So, the "dst" constant will be something like; D:\loot\USB_Exfiltration\ (plus the target computer name along with a date/time stamp; note that the date/time handling probably needs some tweaking if you're not using US style formatting of date and time) All in all, you shouldn't need to add any specific drive letter representing the Bunny in the script. As said, the payload should take care of that if the label of the Bunny (internal storage or Micro SD card) is the same as the label defined in the payload file (i.e. "BashBunny" if not actively changed when setting the payload up).

Using ATTACKMODE this way will kill the network on the Bunny straight away and it will just work as a HID device for the rest of the payload. If you want HID (keyboard) and network at the same time, you need to specify it on the same line, such as: ATTACKMODE HID ECM_ETHERNET From the docs: "ATTACKMODE is a DuckyScript command which specifies which devices to emulate. The ATTACKMODE command may be issued multiple times within a given payload. For example, a payload may begin by emulating Ethernet, then switch to emulating a keyboard and serial later based on a number of conditions." https://docs.hak5.org/bash-bunny/writing-payloads/attackmode I would really advise you to read the documentation instead of blindly executing commands. It will save you time. Not sure what you want ENTER to do here. It's not a DuckyScript command and it's not Bash.

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.