Wait for exe to finish

[EclipseXLV]

I am trying to edit the password grabber payload.txt so that the Finish LED will only turn on once laZagne.exe has finished and closed, because right now it turns on after 10 second while laZagne is still running, which if i remove the usb at that point, all of the excavated passwords are lost.

i'd like it to work similar to powershell where if i Start-Process -filepath -wait 

it will wait to move on to the next line until the process has finished.

issue is, WAIT on the bunny script means Wait for switch position change, and for some reason i cant seem to get grep to find the word password in the password.txt file 

Any assistance/suggestions are appreciated, i just want the finish led to actually mean finished. 

 

[MB60893]

I'd append a line to the powershell script that creates a file on the Bash Bunny in a given folder. When LaZagne has finished executing, the powershell command would simply execute that line, creating a file on the Bash Bunny. Now, on the Bunny, you could modify the existing batch script to loop every 200ms or something to see if the file has been created. If it has, you can delete the file, and the LED could blink green.

Voila! A hacked machine. ^_^

Edited July 13, 2018 by MB60893

[EclipseXLV]

thank you, this solution wors but my issue is when i use grep to find the file i created in my passwordgrabber file, it doesn't find it OR my system for looping the if grep lines doesn't work

here's  what i have written   

:loop
if grep DONE /root/udisk/loot/PasswordGrabber/
then
LED FINISH
else
sleep 5 
fi
goto loop

after laZagne finishes powershell creates a DONE file in the password grabber folder so my issue is either with my usage of grep or my loop

[EclipseXLV]

1 minute ago, EclipseXLV said:

thank you, this solution wors but my issue is when i use grep to find the file i created in my passwordgrabber file, it doesn't find it OR my system for looping the if grep lines doesn't work

here's  what i have written   

:loop
if grep DONE /root/udisk/loot/PasswordGrabber/
then
LED FINISH
else
sleep 5 
fi
goto loop

after laZagne finishes powershell creates a DONE file in the password grabber folder so my issue is either with my usage of grep or my loop

works* not wors

 

[PoSHMagiC0de]

So, I think I posted quite a few dozen times about the attack mode some of the payloads do..."Storage".  Think USB storage.  What do you have to do with USB sticks on machines to ensure they are written to before you pull them out?  You eject them.  There you go.  Data will not show up to the bash bunny on its side until you eject it on the victim side.  There are already a few payloads out there that have examples of Powershell doing this.

Second thing is I see lazagne is being ran as a process so you will have to do a wait-process for it so the script waits until lazagne is done running before moving on and then you can add the done file and eject so it is seen by the BB.

 

What needs to be pinned at top of forums....

Bashbunny storage mode requires an eject/sync;umount to ensure files are written to the BB storage.  (ala clean eject)

[MB60893]

Considering the BB syncs the loot folder after ejecting, there must be a way to force it to sync... Similarly to my previous idea of having a file created for the BB to poll, I would suggest refreshing the LOOT directory on the BB side manually in the script (I'm not sure if there is an easy way to do this without unmounting the directory...?) essentially polling it until it finds the file... Hopefully that would work.

[MB60893]

So I tried just using the mount script below to synchronise directories and that worked well. See if you can get away using just that, or if need be use the unmount as well...

function mount_udisk() {
	mkdir -p /root/udisk
	mount -o sync /dev/nandf /root/udisk
}

function unmount_udisk() {
	sync
	umount /dev/nandf
}

* These were in the bunny_framework script on the Bash Bunny. You may be able to call them this way, but just be careful when you do. I don't know the consequences of doing this, especially if you still have it mounted when you pull the USB... Make sure you unmount the disk before flashing the LED.

Edited July 14, 2018 by MB60893

[MB60893]

Actually, upon further testing it appears that the mount_udisk function can simply be run to allow the BashBunny access to the disk. Any changes Windows or another operating system make to the storage part of the BashBunny are instantaneously able to be accessed under the udisk directory on the BashBunny. However, I haven't had success creating files with the BashBunny for the Windows OS to see. Despite this, that should solve your problem of being unable to access it without removing the drive. ? 

[EclipseXLV]

Thanks everyone for the responses and all of the help, i had a feeling that the lines ":loop" and "goto loop" were my issue (as in: the bunny doesnt loop that part of the script). I tested this with a payload that just changes the lights 

:loop
LED G
LED B
goto loop

 and after changing from green to blue the bunny was left on a blue LED 

so it seems my issue now, is finding a loop method that the bunny will recognize.                                                                                                   

[PoSHMagiC0de]

while true; do
    echo "your code indented block here"
    echo "more code continued"
done

there is your infinite loop in bash.

 

[Dave-ee Jones]

On 7/16/2018 at 9:17 AM, PoSHMagiC0de said:

while true; do
    echo "your code indented block here"
    echo "more code continued"
done

there is your infinite loop in bash.

Infinite loops are a bad idea..even an infinite loop based on a variable is better.

bRunning="1"
while [ $bRunning -eq "1" ]; do
	# Do your jazz here
	if [ -f "file" ]; then
		bRunning="0"
	fi
done
# File exists; jazz complete

 

[PoSHMagiC0de]

So I waited to see if anyone discovers the answer....and I bet this is still an issue.  I noticed doing a fix above involve doing stuff on the bunny to mount and dismount drives.  I bet that takes timing since the file will not show up until the OS syncs it which will be anytime it feels like it.  So, like I mentioned, you need to eject Bunny and in the forums here someone posted the code but since I do not see it regurgitating here, here you go.  Try this while your loop on the BB is looking for that file that tells it it is done.

 

#This one be an example of getting the BashBunny USB drive letter which you probably already done.

$BB = (gwmi -class win32_volume -f {label = "BASHBUNNY"}).DriveLetter


#Do all your junk and after you write that done file do this.

$Eject = (new-object -ComObject Shell.Application).Namespace(17)
$Eject.ParseName($BB).InvokeVerb("Eject")

 

I bet after the above your loop on the BashBunny will find the done file and quit.

have you ever wrote something to a USB stick and just pull it out right afterwards to find the file not there?  Have you wondered why people always say to safely eject your USB drive.  There is a reason for all that that should be taken heed to.

I''m going back to scrolling through repeating threads now to see if any new topics are in there.  ?

 

[Brotai]

For anyone reading this and wondering how to finish the while loop, I use the usb exfiltrator. When xcopy has finished copying all documents from the target I put this at the end of the batch file:

set drive=~%dp0%\..\..\loot

Echo > %drive%\done

At the same time, A while loop is running, I put a  powershell script that will run. Sleep 5 seconds, then repeats, until the done file has been created in /root/udisk/loot then eject the bashbunny. This seems to finish the loop, changing the LED indicator letting me know all files have been copied.

This was done without adding mount -o sync /dev/nandf /root/udisk in the script.

Strangely, in the bash bunny terminal I tried a while loop waiting for done file to be added and It looped infinitely even though done file was present.  I mounted nandf then tried again and it worked. Weird. It seems that when files are created by scripts, It ends up in a different partion of the BashBunny.

[Brotai]

To conclude. It seems this While loop is waiting for the done file to appear in a different partion of the Bash bunny. Maybe its where /bin/bash is located?

 

When I execute this command in serial terminal on the bash bunny:

While [ ! -f /root/udisk/loot/done ]

do 

Echo "waiting"

done

It repeats infinitely unless I do mount -o sync /dev/nandf /root/udisk

This is only in serial terminal. On a payload this doesn't work at all, only when BashBunny has been ejected from the target

I don't have the answer but I hope someone can correct me on this.

[Brotai]

This time I actually figured it out. For anyone still trying to figure this out 

This took a while, udisk needs to mount to a specific point every time the BashBunny is powered on, In which the mounting point of the bash bunny changes automatically every time, When you insert an SD card, It mounts to /dev/mmcblk0p1 (Only FAT32, Exfat doesn't mount properly, But Exfat still works for payloads.) When there is no SD card present, It mounts to /dev/nandf, When you eject however, The BashBunny mounts then reads from nand, i.e /root and its entire path.

When you execute the payload.txt, A While loop executes from /root and will only finish if the done file is located in the /root directory tree, However it doesn't read from the mounted filesystem...Causing an infinite loop.

To alleviate the stress, Have your Batch/ps1 script write the done file to /root instead of /root/udisk/loot and the payload.txt will continue to finish.

After 4 years, Problem solved. (hopefully)

[Brotai]

Include this in your payload.txt script:

RUN WIN (run script here)

while [ ! -f /root/done ]

do

sleep 2

done

rm /root/done

LED FINISH

[dark_pyrro]

The USB exfiltrator payload is using ATTACKMODE STORAGE which mounts the udisk to the target (and not to the Bunny itself). To get access to /root/udisk/loot you have to mount the udisk storage to the Bunny as well which isn't optimal really. In that case you have the udisk mounted to two (2) different systems at the same time which may lead to data corruption. Most likely not the case if the Bunny isn't actively writing to the udisk, but.... anyway. Not really "best practice". In any case, the Bunny never mounts the udisk to itself. It has to be done manually.

4 hours ago, Brotai said:

Have your Batch/ps1 script write the done file to /root instead of /root/udisk/loot and the payload.txt will continue to finish

How is the PS script supposed to be able to write to /root so that the Bunny knows when the process is finished on the target (Windows) side?

[Brotai]

On 12/9/2022 at 10:59 PM, dark_pyrro said:

How is the PS script supposed to be able to write to /root so that the Bunny knows when the process is finished on the target (Windows) side?

 

sorry i made an error, Make the script write a done file to /root/udisk/loot first,  then, In payload.txt, Have a while loop execute the cp command repeatedly copying the done file (when script writes to /root/udisk/loot) to /root or /.

When a while loop is executed (for me) it seems to think there's no partition mounted and it couldn't find the done file located in /root/udisk/loot without having a script eject the bb, So I had to do it this way.

This was a test payload.txt. I've also changed the script a little bit.

#!/bin/bash

GET SWITCH_POSITION
LED ATTACK
ATTACKMODE HID STORAGE
mkdir -p /loot/ <---creates dir in /

RUN WIN powershell (PS.1 SCRIPT THAT EXECUTES COMMAND THEN CREATES DONE FILE  TO /ROOT/UDISK/LOOT WHEN COMMANDS ARE FINSHED )

while [ ! -f /loot/exfilcompleted ] <---reads from / 
do
LED B SOLID
cp /root/udisk/loot/exfilcompleted /loot
sleep 2
done

LED CLEANUP
rm -r loot
rm /root/udisk/loot/exfilcompleted
sync 

LED FINISH

This also worked with SD card inserted. After a bit of testing, I've found that SDHC had mounted correctly while SDXC doesn't which I had been using the whole time because its 2x faster than SDHC 

This finished the while loop without ejecting the bash bunny.

[dark_pyrro]

Still can't see how that would be possible if the udisk isn't mounted to the Bunny (the default behavior). I.e. the Bunny can't see the file that the target creates on the udisk (that is mounted to the target since ATTACKMODE STORAGE is used). Also, you mention that the PowerShell creates a "done" file (as said in previous posts) but the script is processing a "exfilcompleted" file. Maybe a typo.

[Brotai]

I had assumed that nandf/mmcblk0p1 mounts automatically everytime the bunny is plugged into target whether in arming mode or in switch position. Because I'm able to access its file contents on either option? Though this isn't the case when plugged into a new PC. I'm unable to access the files and it says "installing drivers", Even though, when in a switch position, exfil payloads execute fine and sends loot to /root/udisk/loot. I haven't tried the done file part on a new PC but I assume it works anyways.

3 hours ago, dark_pyrro said:

 Also, you mention that the PowerShell creates a "done" file (as said in previous posts) but the script is processing a "exfilcompleted" file. Maybe a typo.

That was a typo my bad. Supposed to be exfilcompleted lol. But the script successfully writes to /. Which is the dir before /root

[dark_pyrro]

We have to get some things straight here.

- "Target" means the device that the Bunny is attached to, for example a Windows PC.

- The "host" is the Bunny itself.

- The udisk is referred to as the storage device of the Bunny, either it'd be the internal storage (/dev/nandf) or a Micro SD card if attached (/dev/mmcblk0p1)

It is true that the Bunny is automatically mounted to the target when it's plugged in using the arming mode switch position of the Bunny.

If you want the udisk mounted to the target in one of the two attackmode/payload switch positions (1 or 2) you have to specify ATTACKMODE STORAGE to make the Bunny storage mount to the target. It's not done automatically as in arming mode.

So, exfiltrating loot to /root/udisk/loot is totally possible if the payload uses ATTACKMODE STORAGE since that will mount the udisk to the target.

However, getting the Bunny itself (the host) to look for files on the udisk if the udisk is mounted to the target isn't possible since the udisk isn't mounted to the host by default. If you're not actively mounting the udisk to the Bunny in some way (in the payload), then the Bunny won't be able to see the "done" file (or whatever it's called) on the udisk.

Read (at least) "Payload Modes" and "Mounting Considerations" in the Storage section of the Bunny docs
https://docs.hak5.org/bash-bunny/getting-started/considerations-for-mark-ii#storage