Windows File Protection Story with happy ending [Archive]

View Full Version : Windows File Protection Story with happy ending

doug

January 21st, 2004, 01:26

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?

Kayaker

January 21st, 2004, 03:24

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

evaluator

January 21st, 2004, 05:13

if you want delete, how about deleting in Dos?

Fake51

January 21st, 2004, 09:25

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

disavowed

January 21st, 2004, 10:17

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

dELTA

January 21st, 2004, 11:11

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

doug

January 21st, 2004, 11:39

@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

Quote:

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) .."..

dELTA

January 21st, 2004, 11:54

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).

disavowed

January 21st, 2004, 17:57

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?

dELTA

January 21st, 2004, 19:14

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?

r4g3

January 21st, 2004, 19:47

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.

dELTA

January 21st, 2004, 20:46

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.

disavowed

January 21st, 2004, 22:28

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

Fake51

January 22nd, 2004, 09:05

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

Woodmann

January 22nd, 2004, 20:19

Hi,

Quote:

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

JMI

January 22nd, 2004, 21:52

Thus sayeth the Wood.

Regards,

disavowed

January 23rd, 2004, 00:13

Quote:

[Originally Posted by Woodmann]Look at that big 5 dollar word---thusly... Disa, I just couldnt resist

"benefits of a classical education"

(+1 rce point to anyone who can name what movie that's from)

Kayaker

January 23rd, 2004, 00:56

Wut's this, Woodmann's search games revisited?

"When Alexander saw the breadth of his domain he wept, for there were no more worlds to conquer. Benefits of a classical education."

The same movie which featured this famous line:
"Yippee-ki-yay, motherf***er!

OK, +2 RCE points for this one

"There's something in the atmosphere that makes it impossible to POP A BONER!"

JMI

January 23rd, 2004, 13:06

As Kayaker noted:

John McClane: Yippee-ki-yay, motherf**ker= Die Hard (the first one.)

Hans Gruber: "When Alexander saw the breadth of his domain he wept, for there were no more worlds to conquer. Benefits of a classical education."
Same Movie.

Hans Gruber Quotes:

"What idiot put you in charge?"

" I wanted this to be professional. Efficient, adroit, cooperative, not a lot to ask. Alas, your Mr. Takagi did not see it that way, so he won't be joining us for the rest of his life."

"You ask for miracles, Theo. I give you the F.B.I."

"Mr. Takagi, I could talk about industrialization and men's fashions all day, but I'm afraid work must intrude."

As to the last quote, I simply offer another line from Hans: "I must have missed that episode of 60 minutes."

Regards,