Thread: how to block flash memory

  1. #1
    Registered User
    Join Date
    Feb 2013
    Posts
    11

    how to block flash memory

    Hi friends ,
    I want to block flash memory exactly after connected that to the usb port for all programs and os except for only one specific program for example called "my_program.exe" .
    I want to do some work with "my_program.exe" on that flash memory for example search the files , delete some of them , ... and then unblock flash memory .
    I can't find anything on the web .
    I found some api for working with usb ports but they don't have good documentation .
    Target os is windows (xp or seven , 32 or 64) .
    I must use pure c (not c++) for this work .
    Please help me .
    Thanks a lot , good luck .

  2. #2
    Registered User ledow's Avatar
    Join Date
    Dec 2011
    Posts
    435
    I don't think you're going to be able to lock an entire device exclusively on Windows without running into a tons of problems and hanging programs (while they wait for it to become available so they can do things on it). You could write a filter driver for a particular USB device, but that's a lot of hassle to do and involves some deep-level programming.

    I think you're just looking at things the wrong way. Why do you need to lock the device exclusively?

    If you're thinking about hooking filesystem access to it, like antivirus programs do, then that's a different matter but there you really want to look into filesystem hooks (which, if you mess them up, can take out your filesystem and hang/crash your OS).

    Just what precisely are you trying to achieve and why?

    - Compiler warnings are like "Bridge Out Ahead" warnings. DON'T just ignore them.
    - A compiler error is something SO stupid that the compiler genuinely can't carry on with its job. A compiler warning is the compiler saying "Well, that's bloody stupid but if you WANT to ignore me..." and carrying on.
    - The best debugging tool in the world is a bunch of printf()'s for everything important around the bits you think might be wrong.

  3. #3
    Registered User
    Join Date
    Feb 2013
    Posts
    11
    Quote Originally Posted by ledow View Post
    I don't think you're going to be able to lock an entire device exclusively on Windows without running into a tons of problems and hanging programs (while they wait for it to become available so they can do things on it). You could write a filter driver for a particular USB device, but that's a lot of hassle to do and involves some deep-level programming.

    I think you're just looking at things the wrong way. Why do you need to lock the device exclusively?

    If you're thinking about hooking filesystem access to it, like antivirus programs do, then that's a different matter but there you really want to look into filesystem hooks (which, if you mess them up, can take out your filesystem and hang/crash your OS).

    Just what precisely are you trying to achieve and why?
    Thanks a lot for your help .
    I want to write very simple antivirus for flash memory .
    It's my project for university and we must block the flash memory at first and then scan it and after all of this work enable flash memory for communicate with os and other programs .
    Thanks a lot .

  4. #4
    Registered User ledow's Avatar
    Join Date
    Dec 2011
    Posts
    435
    Then I would suggest a filesystem hook instead. Basically you insert a routine in between every read/write access to the drive and THAT decides what to do. The programs say "Open this file", your hooks get told to do that (instead of Windows just doing it automatically), they can then scan the drive or whatever is necessary, and then - when they are happy - they can return the data to the program opening the file.

    But, really, that's the only really sensible way to do things and how almost all antivirus programs that I've ever seen work. Your terminology of "locking" the drive is wrong here. You're just after a filesystem hook.

    File System Filter Drivers

    But, honestly, good luck. That API is horrendously complicated and is likely to just crash the machine if you go a step wrong at any point. I highly recommend that you only program on a virtualised environment for that.

    P.S. Most of the Windows API is pure C.

    - Compiler warnings are like "Bridge Out Ahead" warnings. DON'T just ignore them.
    - A compiler error is something SO stupid that the compiler genuinely can't carry on with its job. A compiler warning is the compiler saying "Well, that's bloody stupid but if you WANT to ignore me..." and carrying on.
    - The best debugging tool in the world is a bunch of printf()'s for everything important around the bits you think might be wrong.

  5. #5
    Registered User
    Join Date
    Feb 2013
    Posts
    11
    Quote Originally Posted by ledow View Post
    Then I would suggest a filesystem hook instead. Basically you insert a routine in between every read/write access to the drive and THAT decides what to do. The programs say "Open this file", your hooks get told to do that (instead of Windows just doing it automatically), they can then scan the drive or whatever is necessary, and then - when they are happy - they can return the data to the program opening the file.

    But, really, that's the only really sensible way to do things and how almost all antivirus programs that I've ever seen work. Your terminology of "locking" the drive is wrong here. You're just after a filesystem hook.

    File System Filter Drivers

    But, honestly, good luck. That API is horrendously complicated and is likely to just crash the machine if you go a step wrong at any point. I highly recommend that you only program on a virtualised environment for that.

    P.S. Most of the Windows API is pure C.
    Thanks a lot .
    I try to understand them .
    If anyone else can find an easier approach , any further help appreciated .
    Thanks a lot .

  6. #6
    Registered User
    Join Date
    Feb 2013
    Posts
    11
    up ...

  7. #7
    Registered User
    Join Date
    Feb 2013
    Posts
    11
    up again ...

  8. #8
    Registered User
    Join Date
    Jun 2011
    Posts
    4,513
    Do not bump threads. (Bumping: Posting messages on threads to move them up the list or to post on a thread that has been inactive for two weeks or longer).
    Forum Guidelines

  9. #9
    Registered User ledow's Avatar
    Join Date
    Dec 2011
    Posts
    435
    Threads on here tend to stay unbumped because people still read the old threads to catch up anyway, and they either have something to add to the conversation, or they don't and the thread dies.

    It's been a week. How many other suggestions have you had? How much progress have you made on the filesystem hook front? Have you found some example code? Have you knocked anything up yourself?

    - Compiler warnings are like "Bridge Out Ahead" warnings. DON'T just ignore them.
    - A compiler error is something SO stupid that the compiler genuinely can't carry on with its job. A compiler warning is the compiler saying "Well, that's bloody stupid but if you WANT to ignore me..." and carrying on.
    - The best debugging tool in the world is a bunch of printf()'s for everything important around the bits you think might be wrong.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Process Memory block
    By ssharish2005 in forum Tech Board
    Replies: 6
    Last Post: 06-29-2011, 04:02 PM
  2. Allocate memory inside allocated memory block?
    By Heidi_Nayak in forum C Programming
    Replies: 14
    Last Post: 04-15-2009, 04:19 PM
  3. Determining size of block of memory
    By ExxNuker in forum C Programming
    Replies: 9
    Last Post: 01-12-2006, 11:54 PM
  4. Problem with usb Flash memory
    By khpuce in forum Tech Board
    Replies: 6
    Last Post: 02-26-2004, 08:54 AM
  5. working with flash memory
    By wazilian in forum C Programming
    Replies: 3
    Last Post: 10-09-2001, 12:15 PM