Jump to content

Ouroboros

Active Members
  • Posts

    6
  • Joined

  • Last visited

Everything posted by Ouroboros

  1. The documentation didn't make it all that clear so I am asking here. Is there a firmware limit on the size of the ISO? I realize in the past it wasn't recommended to go beyond the original ISO size or bad things may happen. The reason why I am asking is, I recently had the opportunity to see the SDK application for a noname hardware vendor which does OEM work for bigger companies. The SDK explicitly allowed variation in ISO/RW partition sizes. While the application didn't say U3, I can't imagine it being used for anything else. While that might be a firmware trick of that vendor only, it made me wonder.
  2. the only way to maintain USB functionality and block the switchblade consistently is to use a filter driver and application blocking. The filter driver needs the following properties; 1. Must block moves/copies from a USB storage device into the PC 2. Detect and flag executables that start from the removeable drive 3. Detect and flag files opened from the USB storage device Application blocking must have the following properties 1. Overt blocking of unknown executables from USB devices (blacklist or whitelist) 2. Covert blocking of saving of opened files originating from the USB device onto the PC (save-as blocking from whitelist applications) The above will not protect against the following 1. person hand types batch files and executes 2. javascript in webpage stored on USB device 3. device driver attacks by USB devices masquarading as non-storage devices 4. any file stored on a USB device, accessed by a whitelisted application on the PC, which does not use normal save-as methods, or provides unusual access methods (examples include encrypted containers which mount locally and do not appear to be a removable drive) 5. filter driver attacks For people who want to learn more, microsoft has an IFS kit with USB filter driver examples (currently being rolled into the new windows driver framework, so the toolkit name may have changed some). This is not for the faint of heart, as you start getting deep into kernel stuff and you can mess up badly. Typically, you'd want a guinea pig machine connected by serial to your dev/debug machine. The IFS kit costs some money, but I'm sure it can be acquired. There is some related stuff from sysinternals, but they stopped giving source code at an early version number, the source code isn't even available from their site anymore (gotta use wayback machine on mirror sites), and uses some truely ancient stuff to allow work with win98, so some of the methods may not even work anymore due to deprecation in the API's. But it is good reference materials. Developing file system filter drivers you can install on the fly requires good NTFS knowledge, but you can do some interesting things with it. There's a reason why most of the filter driver work is done by israeli security companies (virtually all of them are staffed by former psyops and comm/info warfare guys who got out after training instead of going career military, so these guys are well trained). Application blocking is a relatively trivial exercise for whitelisiting, by doing quick and dirty hash signatures of every executable that should run, and blocking the rest through filter driver interception.
  3. The AV folks aren't idiots and are watching this thread too. But they rely mostly on static signatures. Is there some way to have a file download server that repacks/pads/encrypts the source files differently on every download to prevent easy signature creation? This won't protect against good heuristics and application behavior detection, but a lot of people turn that functionality off anyways because of the number of false alarms.
  4. U3 sends their love http://devblog.u3.com/?p=35
  5. Not trying to be a distration, but U3 just posted an application packager to make life easier to make an install package for U3. http://devblog.u3.com/?p=34 They sure are making our lives easier.
  6. I asked on Digg, but didn't get an answer so I am asking at the source. Is there a particular reason why the U3 ISO image is being replaced with a custom ISO image? Since the U3 launchpad is a real application (backed by big corporations so antivirus is much less likely to block it), which already has the ability to autolaunch an application registered to it, why not go that route? All it takes is the U3 developer API (available for free), some tweaking to an exe to behave as U3 expects, and packing it up as a U3 install file. To prevent easy tagging by antivirus, randomly pad the exe before creation the U3 install file. Since U3 always had the ability to load up from a local U3 install file, this is relatively easy to test. I realize a lot of batch files are being used, but a simple exe to execute batch files shouldn't be a problem, right? I don't see a clear advantage to using the custom ISO. Am I missing something?
×
×
  • Create New...