Page 1 of 2 12 LastLast
Results 1 to 15 of 19

Thread: Windows File Protection Story with happy ending

  1. #1

    Windows File Protection Story with happy ending

    Hello, here's something that happened to me today:

    As I was learning on the "Rich"-stuff that ms link.exe adds on exe files (and tips on shrinking exes size), I downloaded a STUB.exe to use with the LINK's /STUB switch.

    I did the following:
    Extract file to desktop, hex edit file.. etc.. Close hex editor
    When I try to delete it, Windows tells me a sharing error ("... In use in some other program?")..

    Buggy hex editor I thought..
    reboot
    try to delete file, still windows file protection problem.. (wtf!)

    The file is locked but I can still edit/save change to it..
    Every monitoring tool I tried from sysinternals failed to tell me which process had an handle to the file (see later)

    Bit annoying to have these files laying around the desktop permanently. To remove the file, I hex edited the file(s) and I pasted the code from a 'normal' PE exe. Rebooted, file can now be deleted!


    Seems like a weird thing to me.. Does windows assume old dos files shouldnt be deleted?
    Since no tool could report an opened handle, I'm guessing there is some kind of check performed on the file before it's given the okay to be deleted?

    Os: Windows XP SP1.

    Is this a documented issue? did anyone else have that problem?

  2. #2
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,154
    Blog Entries
    5
    Hi

    Seems very odd, can you duplicate what occurred? Just curious where you got the stub from, you might know this article, you could try the stub here:

    http://its.mine.nu/html/coding/essays/stub.html

  3. #3
    Musician member evaluator's Avatar
    Join Date
    Sep 2001
    Posts
    1,524
    Blog Entries
    1
    if you want delete, how about deleting in Dos?

  4. #4
    Every once in a while I get similar problems when trying to delete files. It's typically when burning some data to a cd - after the burn is done (using Nero), I try to delete the data and pop, messagebox in my face telling me the file is in use. Funny thing is that loading Nero and deleting it FROM Nero works (loading Nero in itself is not enough, I have to use Nero to delete the file). This behaviour is on XP as well - ticks me off it does. Haven't bothered to see what exactly Nero does when opening files to burn - don't make backup copies that often.

    Fake

  5. #5
    <script>alert(0)</script> disavowed's Avatar
    Join Date
    Apr 2002
    Posts
    1,281
    but with nero it's just a sharing problem afaik (sysinternals tools will show that nero owns a handle to the file)

    doug, i would be very interested if you could post the appropriate info so that we can try to duplicate the problem, as kayaker said

  6. #6
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    Sounds interesting indeed, please keep us updated with any info you find about this.

    Also, doug, did you learn anything interesting about the "Rich" stuff while looking into it? I have always been curious about what that data after the stub code is (most of the time seemingly containing the word "Rich"), but never managed to get any good info about it.

    See for example this old thread of mine in the Win32asm forum:

    http://board.win32asmcommunity.net/showthread.php?s=&threadid=11182

  7. #7
    @kayaker: the stub on that site didn't raise the issue. I included one as attachment.

    Ok, I tested an another computer, same issue. (also windows XP).


    @delta:
    Yes, in fact, I found the information from that board
    http://board.win32asmcommunity.net/showthread.php?threadid=14699&highlight=Rich+Link
    The "garbage" is "encrypted" MS internal codes about the components you used:
    Example:
    the second dword before hard coded "Rich" is "@comp.id" variable i.e.
    MS unique(hard coded) compiler ID number XORed with the key(see bellow)

    MS ML.EXE Ver.6.14.8444 -> comp.id is 1220FC
    (You can search: FC2012)
    MS ML.EXE Ver.7.00.9466 -> comp.id is 4024FA
    (search: FA2440)
    MS ML.EXE Ver.7.10.2179 -> comp.id is 0F0883
    (search: 83080F)
    MS ML.EXE Ver.7.10.3077-> comp.id is 0F0C05
    (search: 050C0F)

    MS C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 ->comp.id is 0B2306
    and on wasm.ru (+ babelfish), there's a small article by someone named S.T.A.S (also attached, as I write this, wasm.ru is down).

    Code:
    Выбираем самое похожее (для Version 5.12.8078 ):
    
    :0044510C E86FABFFFF call 0043FC80 
    :00445111 8B8DE0010000 mov ecx, dword ptr [ebp+000001E0] 
    :00445117 89442410 mov dword ptr [esp+10], eax 
    :0044511B 03C8 add ecx,eax 				<---  
    :0044511D 898DE4010000 mov dword ptr [ebp+000001E4], ecx 
    :00445123 FF1510114000 call _tzset
    I'm using MASM32 for my asm projects, and stas' article points out how to patch your linker so that this "Rich" stuff isn't included. WASM' website pointed out more things in the file description of this document, but the translation was very poor. What I managed to understand was that it was a bunch of unique IDs.. they had a statement like "you write viruses and release it (built with this linker) .."..
    Attached Files Attached Files

  8. #8
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    Cool, thanks! Especially cool is that it actually WAS some encrypted potentially identifying information, just like my conspiratorial imagination initially suspected (and that they referenced my thread in that thread).

  9. #9
    <script>alert(0)</script> disavowed's Avatar
    Join Date
    Apr 2002
    Posts
    1,281
    yep, it's a bug in explorer.exe...
    if you do something with it via the windows shell, explorer.exe never closes the handle as it's supposed to. this can be solved with sysinteral's process explorer (find the handle and close it with process explorer). once all handles are closed thusly, it can be deleted

    don't know the details of why this bug exists. i guess explorer.exe considers it an invalid pe file?

  10. #10
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    Is this really the same issue as doug mentions? He couldn't delete it even after a reboot it seems (without correcting the header first), and also, in his case the sysinternal tools couldn't see which process had the handle?

  11. #11
    r4g3
    Guest
    this is not necesserity with PE files. happened for me with .avi's again rebooting wouldnt work, but FAR manager erased them without any problems. they were first opened with winmedia player 9 ... so it is not pe-only issue.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  12. #12
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    The avi problem is another thing, it is caused by a bug in shmedia.dll, and can be fixed fixed with the attached inf-file (modifies a single registry value to prevent auto-loading this dll in explorer).

    Also, in this case it is not the simple matter that some module always opens a certain file type and forgets to close it, but the peculiar thing is that when certain modifications were done to the executable header, the file was locked, but if the changes were undone, it was unlocked again.
    Attached Files Attached Files

  13. #13
    <script>alert(0)</script> disavowed's Avatar
    Join Date
    Apr 2002
    Posts
    1,281
    Quote Originally Posted by dELTA
    Is this really the same issue as doug mentions? He couldn't delete it even after a reboot it seems (without correcting the header first), and also, in his case the sysinternal tools couldn't see which process had the handle?
    if he was trying to delete it with explorer.exe after rebooting by dragging it to the recycle bin, or clicking on it and pressing delete, or whatever, then chances are that the bug could still arise. so, i think it is the same issue. but, i don't mind getting proven wrong

  14. #14
    Quote Originally Posted by disavowed
    but with nero it's just a sharing problem afaik (sysinternals tools will show that nero owns a handle to the file)
    Just might be - just have a memory of rebooting the machine and still not being able to delete the file, in which case it wouldn't just be a sharing problem (as the file wouldn't be open). Not sure though - been a while since I had the problem last.

    Fake

  15. #15
    Hi,

    once all handles are closed thusly,
    Look at that big 5 dollar word---thusly.

    Henceforth and forthwith, the word "thusly" shall't
    be useth from this point on.

    Disa, I just couldnt resist

    Woodmann

Similar Threads

  1. A Filemaker Story
    By dion in forum Blogs Forum
    Replies: 1
    Last Post: December 5th, 2013, 17:06
  2. FIY: Printable “Windows Kernel Address Protection” paper out
    By j00ru vx tech blog in forum Blogs Forum
    Replies: 10
    Last Post: December 13th, 2011, 00:25
  3. Ever heard of Windows Protection Plus??
    By corus-corvax in forum Advanced Reversing and Programming
    Replies: 10
    Last Post: January 15th, 2008, 18:15
  4. Merry christmas and a happy new year!
    By dELTA in forum Off Topic
    Replies: 20
    Last Post: January 11th, 2007, 06:05
  5. happy birthday OllyDbg !
    By TBD in forum OllyDbg Support Forums
    Replies: 8
    Last Post: December 5th, 2003, 22:56

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •