Jump to content

maehko

Active Members
  • Content Count

    11
  • Joined

  • Last visited

About maehko

  • Rank
    Hackling
  1. It seems that the firmware update may not be required for these earliest purchases, since the version for download is 1.0.0, which I wouldn't expect it shipping with anything less. So I think this is nothing more than an indication that there's nothing to do and the slow blinking red light simply is indicating that there was an error running the payload since none was there to load.
  2. I just fought through this too. First make sure you have easy access to the device since you have to see the back of the device to coordinate the button push while at the same time look at the front of the device to determine which of the 5 blinking speeds is occurring - <rant> apparently they ran out of RGB LEDs and thought a light flashing at various speeds on the opposite side of the device than where you're looking/working was the best solution given the lack of RGB hardware. </rant>. This first point of note is that the 3-second mode selection phase is not within 3 seconds of boot, but rather during a 3-second period when the red light blinks the fastest during the boot (2-digit millisecond-off intervals, not 3-digit millisecond-off intervals. or 32nd-note intervals vs eigth-note intervals). This period happens several seconds into the boot process after the OS has loaded and is ready to accept user input. The second point is to not hold the button in, but make sure it a firm, short press, after which you should see the recurring double-blink indicator.
  3. I was running into similar issue and it appears that the new firmware fails on previously valid LED combinations. For instance, any reference to LED R G B now seems to fail on firmware 1.1 since the proper syntax is now LED W. I was able to get this to work by replacing all combination LED commands in install.sh and payload.txt with the new composite LED commands. This seems like an oversight and will probably break all previously created scripts that used combo-LED commands. I would expect a future update that will accept both multi and composite codes so previous payloads using mutli-codes won't continue to fail just because of the syntax change.
  4. I just switched to ECM_ETHERNET and verified the same behavior on MacOS
  5. Thank's @snowc. That matches my experience as well. Does your LED change from purple to white after 2 minutes?
  6. I did see Darren's post before posting this thread and I have been able to duplicate that behavior. The problem described here though is affecting switch 1 as well and is NOT that the RNDIS doesn't automatically install due to it being a composite device. The problem that is occurring in both switch positions is that Windows cannot enumerate the composite devices when all three devices are specified via the ATTACKMODE command. Can someone else run the following payload and report your experience? LED R B ATTACKMODE STORAGE SERIAL RNDIS_ETHERNET LED R G B
  7. I've been trying to setup the bunny to work with RNDIS_ETHERNET STORAGE Serial but without success. The combination of any two of those selections works as expected, but any ordered combination of those 3 fails to mount any one of the three devices on M$ Surface, Win10 10.0.14393 Using the Payload.txt below, after the 7 second boot cycle, the LED turns purple and stays purple for 113 seconds, after which the LED turns white, but no storage, serial, or network device is present. After the LED has turned white however, device manager appears to refresh every so often like it's trying to enumerate new devices, but none show up. I'm not finding any relevant event log entries. Are their any persistent logs available via arming mode serial? #!/bin/bash LED R B ATTACKMODE STORAGE SERIAL RNDIS_ETHERNET LED R G B
  8. maehko

    Install Tools

    Thanks @Cpt.Pickles. That makes sense - I didn't consider reusing the script for subsequent installations. My bash programming is still weak and I'm not sure what would be causing the code <if [ "$(ls -A $TOOLSDIR)" ]; then> to evaluate true and stop installation when manually checking that directory returns no content. Is there a way to evaluate a statement manually in bash? For instance, in PowerShell, if I create an if statement that evaluates (4 -eq 4), I can test that evaluation manually from the PS prompt by simply typing "4 -eq 4" and PS will return True as a result. I was hoping for something similar in bash to help me work through understanding syntax logic.
  9. maehko

    Install Tools

    I've rewritten the install.sh script with the following changes and the tool installation is now completing as expected. Created a new variable for the target directory Replaced directory creation command to reference new variable Inverted the install logic after the tool copy to validate the new directory has content rather than checking that the source directory is now empty. # Check to ensure that the tools_to_install directory isn't empty. # Exit with solid red LED if it is, otherwise note tools in log. TOOLSDIR=$(find /root/udisk/payloads/ -name tools_to_install) TARGETDIR=/pentest/ if [ "$(ls -A $TOOLSDIR)" ]; then cd $TOOLSDIR echo "Available Tools:" > /tmp/tools_installer.log echo "----------------" >> /tmp/tools_installer.log for i in $(ls -d */); do echo ${i%%/} >> /tmp/tools_installer.log; done else LED R exit 1 fi # Set LED to purple blinking and move tools LED R B 100 mkdir -p $TARGETDIR mv $TOOLSDIR/* $TARGETDIR # Set LED to purple solid and check that move completed LED R B if [ "$(ls -A $TARGETDIR)" ]; then # Setup impacket cd /pentest/impacket python ./setup.py install # Additional tool setup goes here # List installed tools in /pentest and save to tools.txt on USB disk cd /pentest/ echo "Installed Tools:" > /root/udisk/installed-tools.txt echo "----------------" >> /root/udisk/installed-tools.txt for i in $(ls -d */); do echo ${i%%/} >> /root/udisk/installed-tools.txt; done sync && sleep 1 && sync # Set LED to white on success LED R G B exit 0 else # Set LED to red on fail and exit LED R exit 1 # Set LED to amber blinking on setup LED G R 100 fi
  10. maehko

    Install Tools

    Ever wish you could retract a post... :/ feel free to ignore the 'observations' in the post above... Will continue digging and provide updates if I find anything valuable..
  11. maehko

    Install Tools

    @Darren KitchenI too am seeing this. During the initial run, the tools_to_install directory content is moved to /pentest but the script immediately fails on line 21 thereafter, setting LED R. Since line 4 and 21 are both if [ "$(ls -A $TOOLSDIR)" ]; then it seems that the logic is inverted for line 21. line 4 - quit if the <payload tools directory> is empty line 17 - empty <payload tools directory> line 21 - install tools if <payload tools directory> is not empty <insert segfault here> - of course it's empty - i just told you to move everything out of it... Should line 21 be looking at the target folder rather than the destination folder? Bonus questions for responder newbie, does it need to be installed or do the files just need to be present?
×
×
  • Create New...