Further — more. I ask to do the same procedure my colleague, on its computer. It tries — and everything works for it! But how so? One application version, the same file from the bild-server. Some difference in an environment? I sit down at the colleague's computer, I try once again — does not work! It in it tries time on mine — works! That is it turns out that the file "remembers" who extracted it! We call the third colleague to observe this circus. Consistently, on the same computer, in turn we do the same actions: we download archive with a plug-in, we will extract in the necessary folder, we start the application. When it is done by me — the program does not see a plug-in when it is done by the colleague — everything works. On the third circle of these interesting experiments suddenly we notice a difference in actions: I extracted a plug-in with standard means of Windows, and my colleague — with the help 7-Zip. Both was caused by us from a context menu of archive so in the beginning nobody noticed a difference in click on not that point. Well ok. It turns out, the file retrieved from zip-archive with the help 7-zip differs from the same file from the same archive retrieved by means of the standard Windows archiver?
By the way, until you opened article under a cat, answer for yourself a question whether there can be it that contents of files of valid zip-archive at extraction 7-zip and through the conductor of Windows will be a miscellaneous?
Well, we will not guess and we will compare files by means of WinMerge:
It turns out, files identical and have to be loaded and processed equally? As if not so! WinMerge lies. Files are different. Also they are loaded .netom too differently.
And now there will be a terrible truth
When loading the file from the Internet of Windows puts on it the special "flag" meaning the trust zone corresponding to the website from which it was loaded. I think, many saw in attempt of start of just downloaded performed file of warning that you should not start it, perhaps, it is necessary to think, here look at the certificate and tell what to do. Depending on security policies and an origin of the file the level of a paranoidalnost of these warnings can be a miscellaneous — from their total absence (we work under the administrator, UAC is disconnected, the file is signed) before start blocking (a corporate environment, the unsigned file). There are also several intermediate stages where it is necessary one or to tell several times "yes, it is started". But all this works only for EXE files, huh? Is not present! On the dll-file downloaded from the Internet or archive this flag will be hung up too! From the technical point of view it is an alternative file flow of NTFS at which it is possible to look, for example, through the utility of AlternateStreamView well or through command:
more < Plugin.dll:Zone.Identifier
And here we have confluence of the following circumstances:
- The browser when loading creates an alternative file flow of "Zone.Identifier" for the downloaded archive and writes there ID zones from where the file came.
- The standard archiver of the conductor Windows at extraction reads not only the main file flow, but also alternative, and adds them to each retrieved file. (7-Zip does not do it).
- The utility of WinMerge compares only the main file flows and says that the files created 7-Zip and the conductor are identical.
- In .NET the Assembly.Load method () reads alternative file flows too, finds the zone identifier with the lowered trust — and refuses to load the file! At the same time usual to confirm to the user of the message with a request start of not entrusted application are not shown and we receive our bug.
It is rather simple to deal with the problem — it is necessary to check \delete this file flow. In Windows for this purpose it is possible to cause properties of the file and to click there Unblock (well or to do it programmatically).
If you make it for archive before extraction of files of it — the identifier of a zone will be gone also for all files retrieved in an effect.
Perhaps, I told banal and all here the known things, however that fact that from the same archive different archivers can retrieve different files moreover and so cunning different that WinMerge of this difference does not see, and .NET — sees, personally for me was interesting opening.
This article is a translation of the original post at habrahabr.ru/post/274183/
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here: email@example.com.
We believe that the knowledge, which is available at the most popular Russian IT blog habrahabr.ru, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.