Jump to content


Active Members
  • Content Count

  • Joined

  • Last visited

About Cerolobo

  • Rank

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender

Recent Profile Visitors

860 profile views
  1. 20KB in Hex ~40KB 20KB in Base64 ~26.6KB Of course, you don't actually have to store them in this format. You can actually store them in binary and do the conversion on the fly. I've actually been playing with the concept of executable uploading with base64 in the thread Fun With Base64, with a functional example. I'm thinking about paring this up with RawHID. IE, you transfer over a small background app that uses RawHID which will enable you to silently transfer binary in the background at a much faster transfer rate.
  2. Ok, I did some more work on the executable uploading. It should be fairly easy to actually use at this point. See my initial post for a list of the changes and such. Other then that, any feedback or requested would be appreciated.
  3. You might want to add "&& sc config ShellHWDetection start= auto && sc start ShellHWDetection" Enabling the autorun regkey will do nothing if Shell Hardware Detection is disabled.
  4. As H@L0_F00 stated, it would be a 1-1 mapping when compiled into the Teensy. The main issue with this method it that you'll still need to convert the binary file into something that can be compiled. I don't know of any method to pull in a binary file, and load it at a specific address. If there is a method, I'd love to know. Currently, the only way I can see to do this would be to convert the binary into a byte array, which would require a fairly trivial program to perform the conversion in a sane manner (output a c source file). Generally, my initial post was just a proof of concept. I h
  5. Simply stated, size constraints. Hex would double the size of the encoded program. IE, you won't be able to do nearly as much and it'll take longer to transfer to the computer.
  6. The main issue is the actual character set. Since you are limited to keyboard input, you can only use visible keys. As such, traditional compression algorithms won't work correctly without modification. With that being said, it would potentially be possible to run LZW or similar on a binary file, and then convert the overall output to Base64 for the transfer. The main caveat with this will be the actual script size. I wanted to rely on common built in functionality. Once you move over to a custom compression scheme, the script file will become a lot larger. A alternative to doing this would
  7. Definitely; however, that's kind of a roundabout method. You can actually convert any executable to base64 (assuming it will fit on the chip), so you don't actually have to do the intermediate step. I did include the script I used to convert the executable to base64 in the zip at the bottom of my original post. Simply just drag and drop a executable over it (Fun_With_Base64/Scripts/Encode.vbs), and it'll produce a text file. Once you have that, you'll have to convert it into something that the ducky can use. I just ran a bunch of key macros over the text file to stringify the file. I
  8. Edit (04-27-10): Lots of changes from the proof of concept http://www.craigwill.com/Downloads/Fun_With_Base64_v2.zip Summary: - Apply LZW compression (~30% size reduction) - LZW decompression done via VBScript - Automatic Teensy source file generation (IE, it should be easy to use) - Program and script the script code is now stored in the Flash memory Current Goals: - Port Base64 Library to Teensy, so the compressed binary can be stored - Optimized/Tweak the LZW library - Linux Build - Flat binary file, rather then a ton of global variables Know Issues
  • Create New...