Jump to content

UnixSecLab

Active Members
  • Posts

    33
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

UnixSecLab's Achievements

Newbie

Newbie (1/14)

  1. I just looked at the file that you linked to, and compared to what you wrote, you're @ and " are still backwards. The file has: for /f "tokens=3" ... blah blah where you're quote has: for /f @tokens=3 ... blah blah which is wrong. Your initial share showed " where @ should be, and now you're displaying @ where " should be.
  2. Did you try plugging a network cable into the RJ45 jack with internet access before plugging the turtle into the computer? That seems to be the only way it grabs creds when I test.
  3. The inject.bin is the file you create when you compile your ducky script using the encoder.jar file. You have to compile your own inject.bin every time you want to change what the payload is going to be. Just write yourself a ducky script, and then grab the encoder from the github wiki site and compile your own inject.bin.
  4. The LAN Turtle is a mips based machine running an openwrt based Linux OS. The package manager is opkg, and the package files (should be) .ipk files, I believe. You can always log into it and exit to the command line to issue opkg commands from there. If you're savvy and extra froggy, you can set up the cross compile build environment for OpenWRT on MIPS and compile whatever you're missing, yourself. Just be aware that there's not a lot of space on the device's internal storage, so you'd need to be careful about size, and such.
  5. There are a couple of ways to do this. One involves using a second USB device that acts as a drive, and the other is to use the Composite firmware to present the storage on the ducky as a drive along with the HID it presents. Either way, you need to look through the forums here to get an idea of how to detect the drive, once it's been plugged in, and understand how the different Composite firmwares work. For example, the 4cap composite is supposed to present the SD card as a usb drive, and present a HID device, then manually run the payload by hitting the Caps Lock key 4 times in a row. However, in my testing, the caps lock event did not trigger on the Linux Mint workstation I was testing from. Plugging it into a Windows 10 workstation read the event just fine and delivered the payload. In both cases, the ducky would deliver the payload if the physical button on it was pressed.
  6. The inject.bin is meant to be created by writing a Ducky script and then running the script through an encoder. The default inject.bin that comes with the Ducky is pretty useless for anything other than testing and amusement. The latest encoder is at this link: https://github.com/hak5darren/USB-Rubber-Ducky/tree/master/Encoder
  7. Sweet. Glad you got it working! Sorry I gave muddled instructions the first time around. I'll try to pay more attention in future ;)
  8. Those were the errors I got before I found the fixes I listed when I originally did this. I did this on Linux Mint, which is Ubuntu and thus Debian based. Something might be "off" from all of the troubleshooting you were doing, so the best I can suggest at this point is to do the following: 1) Delete the dfu-programmer-0.5.4 directory. 2) Untar the tarball to get a fully clean slate. 3) Do the "sed" to fix the configure file. 4) Run ./configure. 5) Do the "sed" to fix the src/Makefile file. 6) Run make If it still fails, you might try blowing it away again, and do your ./configure and make without the sed modifications and see if it compiles on your system. If you still have issues, I'll gather more information about the binary I built when I get back to work tomorrow (in case there are other libraries missing.) Sorry this is giving you so much trouble.
  9. Do you have lib-usb-dev and libusb-dev and libusb-1.0.0-dev installed? You might need to install those, then re-run ./configure && make. sudo apt-get install libusb-dev libusb-1.0.0-dev If you have those installed, you may need to paste the errors so we can see what you see.
  10. Yep. I edited my previous comment twice to get my full thought out, and you had already run off before I got the last part out which is to include the src/Makefile on the end so that it knows what file to modify :) Make sure that's an "M" and not an "m" in the Makefile bit, since case matters.
  11. Have you tried just setting the IP manually on the ethernet device that's getting a 169.254.x.x address? You should be able to change it manually to 172.16.84.3 (for example) and that should make it possible to communicate with the LAN Turtle over its USB network so that you can log in with ssh, do your updates from there, and then try again with an updated device. I really should "just work" but if you aren't getting DHCP that's usually related to the host OS not getting a response from the Turtle fast enough for its liking, and assigning the self IP instead of doing DHCP. The turtle is taking too long to initialize after it's recognized as a network device. If you can't log in after setting a manual IP in the 172.16.84.x range (that isn't .1) then there's something up with the device.
  12. It could be a copy/pasta error (where the noodles got overcooked.) What you pasted to show as an example of what you tried looks like it has a back tick ` instead of a single quote ' to open the sed statement (right after the -ne flag.) There should only be single quotes in the example, so try cleaning those up and give it another shot, maybe? I should have vetted my example before pasting it here. I did a raw copy from my blog, and the quotes probably got mangled on my end when I pasted. I should have pasted into something like notepad first, then re-copied to clipboard to paste here. You might want to do similar, maybe. Good luck! Also, you need to put "src/Makefile" at the end of that sed statement on the same line. I meant to include it, but somehow missed it. Sorry.
  13. Did you compile dfu-programmer from the tarball on the github wiki, or did you install it as a package with (for example) apt-get? I compiled mine on Linux Mint 17, but I had to do some modification of the Makefile (required) and configure.ac (not sure if this was required, but I did the modification, anyway) based on some errors I was getting, and google-fu search results around those errors. The steps I took were to download the tarball linked to from the wiki: https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Flashing-ducky Unpack the tarball, then change directory into it. tar xvfz dfu-programmer-0.5.4.tar.gz && cd dfu-programmer-0.5.4 Modify the configure.ac: sed -i.bak -e ā€˜s/LDFLAGS/LIBS/gā€™ ./configure.ac Run configure as normal: ./configure Modify the src/Makefile: sed -i.bak -ne ā€˜/^LDFLAGS =/{h;s/LDFLAGS = \(.*\)/LIBS = \1/;x;s/LDFLAGS =.*/LDFLAGS =/};/^LIBS = .*/{x;};pā€™ Compile: make Everything worked fine after that. I did have to install the missing libusb-dev and libusb-1.0.0-dev packages before doing all of the above. sudo apt-get install libusb-dev libusb-1.0.0-dev
  14. The MAC isn't changed for the USB network side of the turtle, so unless you have the host and the LANTurtle plugged into the same switch infrastructure, it should not matter. If you're on opposite sides of a router, I think you're probably okay. So either use the host OR the LANTurtle, or use them on different network segments so that they aren't seen at the same time. I might be overlooking something, but I'm pretty positive this is sound advice.
  15. My write up on the testing I did: http://unixseclab.com/index.php/2016/09/07/hacker-tool-hump-day/ I never did figure out why Windows and Linux behave differently with the 4Cap firmware, but if I do, I'll post my findings here on the forums. Thanks again for the help!
×
×
  • Create New...