Конференция "WinAPI" » Хитрые файлы Win7
 
  • Gu (21.03.11 02:12) [0]
    В реестре (например) вижу, что ссылка ссылается на файл %SystemRoot%\system32\aelupsvc.dll. Открываю проводник, захожу в c:\windows\system32, ищу aelupsvc.dll. Есть. Открываю Far, ищу тамже, файл есть. Захожу в дельфи, новый проект, на форме кнопка, в кнопке пишу:

    if fileexixsts('c:\windows\system32\aelupsvc.dll') then showmessage('Yes') else showmessage('No');
    Выполняю, пишет No.

    пробовал через findfirst искать и через прямое открытие файла, оба файл в упор не видят. прогу запускал от имени админа, прова на файл проверял, владельца менял.
    файл для примера, там таких куча, вот еще из папки system32:
    alg.exe
    appidsvc.dll
    appinfo.dll
    audiosrv.dll
    bfe.dll
    certprop.dll
    defragsvc.dll
    ...

    Есть хитрый момент: если их загружать через h:=loadlibraryex(Pchar(<имя>),0,$20); то h<>0.

    Вопрос: Нет ли какого другого способа определить наличие такого файла на диске?

    Проверьте, у кого вин7 (на 2008r2 тоже пробовал), на одном из файлов которые перечислил, все ли так?

    Мысли есть?

    Win7x64sp1, Rad2010
  • Gu (21.03.11 02:19) [1]
    т.е. это получается, что (например создать список файлов в листвиев)

    findfirst('c:\windows\system32\*.*',faanyfile,sr);
    repeat
    it:=ListView1.Items.Add; it.Caption:=sr.Name;
    until findnext(sr)<>0;
    findclose(sr);

    их не показывает, хотя проводник, Far и Total - эти файлы видят.
    что за бяка такая?
  • Gu (21.03.11 02:25) [2]
    а, вру, Total тоже не видит, он вроде как раз на дельфях написан.
    что ето за ущемление такое? :)
  • sniknik © (21.03.11 08:02) [3]
    вместо faanyfile попробуй что то типа $000000FF; не получится, добавь еще F справа и т.д. (что то смутно помню в винде добавляли какой то атрибут файлам ... в старом дельфи его естественно нет. не помню какой, ну и искать неохота)
  • Anatoly Podgoretsky © (21.03.11 08:48) [4]
    > sniknik  (21.03.2011 08:02:03)  [3]

    Пробовать над FFFFFFFF
  • Rouse_ © (21.03.11 10:27) [5]
    У меня семерка, правда 32 битная, все файлы видятся нормально.
  • Игорь Шевченко © (21.03.11 10:50) [6]
    у тебя другой SystemRoot
  • Anatoly Podgoretsky © (21.03.11 11:37) [7]
    Наверно, ведь та же их аж три
  • Юрий Зотов © (21.03.11 12:22) [8]
    Возможно, флаг индексации?

    См. выделение жирным:
    // Extension of Windows.pas (source: Platform SDK (February 2003), WinNT.h).
    {$IFDEF VER150} // Delphi 7 only
     FILE_ATTRIBUTE_DEVICE              = $00000040;
     {$EXTERNALSYM FILE_ATTRIBUTE_DEVICE}
     FILE_ATTRIBUTE_SPARSE_FILE         = $00000200;
     {$EXTERNALSYM FILE_ATTRIBUTE_SPARSE_FILE}
     FILE_ATTRIBUTE_REPARSE_POINT       = $00000400;
     {$EXTERNALSYM FILE_ATTRIBUTE_REPARSE_POINT}
     FILE_ATTRIBUTE_NOT_CONTENT_INDEXED = $00002000;
     {$EXTERNALSYM FILE_ATTRIBUTE_NOT_CONTENT_INDEXED}
     FILE_ATTRIBUTE_ENCRYPTED           = $00004000;
     {$EXTERNALSYM FILE_ATTRIBUTE_ENCRYPTED}
    {$ENDIF}

    // Extension of SysUtils.pas
     faNormal = FILE_ATTRIBUTE_NORMAL;
     faTemporary = FILE_ATTRIBUTE_TEMPORARY;
     faCompressed = FILE_ATTRIBUTE_COMPRESSED;
     faOffline = FILE_ATTRIBUTE_OFFLINE;
    {$IFDEF VER150} // Delphi 7 only
     faDevice = FILE_ATTRIBUTE_DEVICE platform; // equal to SysUtils.faSymLink
     faSparse = FILE_ATTRIBUTE_SPARSE_FILE;
     faReparsePoint = FILE_ATTRIBUTE_REPARSE_POINT;
     faNotIndexed = FILE_ATTRIBUTE_NOT_CONTENT_INDEXED;
     faEncrypted = FILE_ATTRIBUTE_ENCRYPTED;
    {$ENDIF}

  • sniknik © (21.03.11 12:51) [9]
    > Возможно, флаг индексации?
    в семерке анифайл = $0000003F; т.что все, что любой одиночный флаг значением больше этого не увидит (?).
  • DVM © (21.03.11 16:16) [10]

    > Мысли есть?
    >
    > Win7x64sp1, Rad2010
    >
    >

    Есть, работает перенаправление файлового ввода-вывода.
  • DVM © (21.03.11 16:17) [11]
  • Gu (21.03.11 21:02) [12]
    2 DVM спасибо.

    Все равно непонятно пока ничего.

    Папку с system64 получаю так:

    Function GetSystemWow64Directory(lpBuffer:LPTSTR;uSize:Uint):uint; stdcall; external 'Kernel32.dll' name 'GetSystemWow64DirectoryW';

    Function GetSys64Dir:string;
    var Buffer:Array[0..max_path] of Char;
    begin
    Result:='';If GetSystemWow64Directory(Buffer,max_path)=0 Then Exit;Result:=IncludeTrailingBackslash(string(Buffer));
    end;

    на там этих файлов тоже нет. полазил поискал, оказывается они распиханы по куче папок вида:

    C:\Windows\winsxs\amd64_microsoft-windows-<разные ID>\

    Вопросики тогда:
    1. как дельфям сказать, чтобы они внимания не обращали на этот редирект и файлы эти искали там где винда говорит что они есть?
    2. или получать реальные места файла, зная их имя и путь, на который винда ссылается?

    т.е. еще раз: винда говорит, что есть файл c:\windows\system32\alg.exe, и в проводнике его видно по этому пути, дельфи его не находит, т.к. он реально лежит в  C:\Windows\winsxs\amd64_microsoft-windows-alg_31bf3856ad364e35_6.1.7600.16385_none_04de43c774cf8fe3\alg.exe - вот как получить этот путь?

    и не могли бы пояснить, поможет ли функция Wow64DisableWow64FsRedirection и к чему ведет ее применение?
  • Gu (21.03.11 21:24) [13]
    да и игры с атрибутами ничего не дают (там где выше предложения про индексацию) и рут верный, SHGetSpecialFolderPath (The Windows directory or SYSROOT. This corresponds to the %windir% or %SYSTEMROOT% environment variables. A typical path is C:\Windows.) рут возвращает как c:\windows, также как getwindowsdir
  • Gu (21.03.11 22:04) [14]
    еее, заработало.

    Function Wow64DisableWow64FsRedirection(x:Pointer):bool; stdcall; external 'Kernel32.dll' name 'Wow64DisableWow64FsRedirection';
    Function Wow64RevertWow64FsRedirection(x:boolean):boolean; stdcall; external 'Kernel32.dll' name 'Wow64RevertWow64FsRedirection';

    ...
    var p:pointer;
    begin
    Wow64DisableWow64FsRedirection(p);
    if fileexists('c:\windows\system32\alg.exe') then showmessage('Yes');
    Wow64RevertWow64FsRedirection(true);

    в findfirst тоже работаит... правда реальный путь все еще не знаю как получить, зная только редиректорный.
    2 DVM может знаете выход?
  • Gu (21.03.11 22:09) [15]
    упс, не то вставил, вместо

    Function Wow64EnableWow64FsRedirection(x:boolean):boolean; stdcall; external 'Kernel32.dll' name 'Wow64EnableWow64FsRedirection';

    надо

    Function Wow64RevertWow64FsRedirection(x:boolean):boolean; stdcall; external 'Kernel32.dll' name 'Wow64RevertWow64FsRedirection';

    и вместо Wow64RevertWow64FsRedirection(true); соответственно Wow64EnableWow64FsRedirection(true);

    а для реверта правильно будет:
    Function Wow64RevertWow64FsRedirection(x:Pointer):bool; stdcall; external 'Kernel32.dll' name 'Wow64RevertWow64FsRedirection';
  • Игорь Шевченко © (21.03.11 22:25) [16]

    > Function Wow64RevertWow64FsRedirection(x:boolean):boolean;
    >  stdcall; external 'Kernel32.dll' name 'Wow64RevertWow64FsRedirection'


    [6] таки верно
  • DVM © (21.03.11 23:18) [17]

    > Gu   (21.03.11 22:04) [14]
    > еее, заработало.
    >
    > Function Wow64DisableWow64FsRedirection(x:Pointer):bool;
    >  stdcall; external 'Kernel32.dll' name 'Wow64DisableWow64FsRedirection';
    >
    > Function Wow64RevertWow64FsRedirection(x:boolean):boolean;
    >  stdcall; external 'Kernel32.dll' name 'Wow64RevertWow64FsRedirection';
    >
    >

    Использование этих функций очень опасно. Их можно использовать только в том случае, если ты можешь мамой поклясться, что никакой шайтан явно или неявно не решит загрузить какую либо dll из системного каталога между вызовами этих функций. Никто гарантий не даст.
  • DVM © (21.03.11 23:24) [18]

    > Игорь Шевченко ©   (21.03.11 22:25) [16]

    Имхо не совсем. %SystemRoot% всегда один и тот же, это папка типа C:\Windows\ , а вот system32 меняется. Хотя не понятно, что имелось в виду под SystemRoot - без % написано.
  • DVM © (21.03.11 23:29) [19]

    > Gu

    вот, кстати, почитай про эти функции немножко: http://www.gotdotnet.ru/blogs/not-a-kernel-guy/4519/
  • Игорь Шевченко © (22.03.11 00:14) [20]
    DVM ©   (21.03.11 23:24) [18]

    Разумеется, не совсем. Имелось в виду, что разный System32 для 32-х и 64-х битных программ.
  • Gu (22.03.11 00:17) [21]
    Ок. спасибо. И как тогда быть?

    И как на счет этого?
    >> правда реальный путь все еще не знаю как получить, зная только редиректорный. 2 DVM может знаете выход?
  • Германн © (22.03.11 03:41) [22]

    > И как на счет этого?
    > >> правда реальный путь все еще не знаю как получить, зная
    > только редиректорный.

    А на кой вам нужен реальный, позвольте  спросить?
  • Gu (22.03.11 07:16) [23]
    :) зачем тут всем нужно знать зачем ? :)))

    нужно
  • QAZ (22.03.11 11:50) [24]
    очередная супергениальная чистилка реестра от "ненужных" ключей ?
  • Gu (22.03.11 12:45) [25]
    Удалено модератором
    Примечание: Обсуждение модерирования
  • DVM © (22.03.11 14:15) [26]

    > Gu


    > 2 DVM может знаете выход?

    Выходы то есть, но они, понимаешь ли, сильно зависят от контекста использования. Допустим, если мне нужна 64 бит папка system32, из 32 бит программы ее достать и открыть или найти что то в ней можно, но если у тебя в распоряжении есть путь: c:\windows\system32\bla-bla то никак нельзя определить, в какую из двух папок system32 он должен вести. Проблема.

    Когда мне очень было нужно, я все же использовал эти функции, но постарался свести код между их вызовами к минимуму. Долго тестировал и изучал, где могут возникнуть грабли, вроде ПОКА нормально. Но это временное решение.


    > Короче дельфевым 32разрядным Api - 64 винда вертит как хочет

    Делфи тут ни причем.


    >  когда же они компилятор заточат под 64

    в августе-сентябре этого года.


    > QAZ   (22.03.11 11:50) [24]

    Действительно, на мой взгляд - это единственное где может такое понадобится.
    Кстати, если это действительно так, то не стоит и забывать о перенаправлении ключей реестра.
  • DVM © (22.03.11 14:41) [27]

    > Gu

    Если тебе очень надо попасть в папку System32 для 64 бит приложений, используй путь: %windir%\Sysnative вместо %windir%\System32.
  • Gu (23.03.11 10:24) [28]
    ну конкретно папка меня мало интересует. меня интересует получение рального пути вместо редиректорного (даже если его можно использовать с учетом применения Wow64DisableWow64FsRedirection).

    выше писал
    >> т.е. еще раз: винда говорит, что есть файл c:\windows\system32\alg.exe, и в проводнике его видно по этому пути, дельфи его не находит, т.к. он реально лежит в  C:\Windows\winsxs\amd64_microsoft-windows-alg_31bf3856ad364e35_6.1.7600.16385_none_04de43c774cf8fe3\alg.exe - вот как получить этот путь?

    еще раз, пример:
    с использованием редиректа сейчас могу получить "типа настоящий" путь как c:\windows\system32\alg.exe (откликается на поиск и другие операции с использованием функций редиректа). А как реальный путь получить? Если знаю что используется редирект и знаю полное имя и путь, которые мне винда говорит (c:\windows\system32\alg.exe), т.е. нужна какая-нить функция

    типа GetRealPath(RedirectPath:string):string;

    чтобы

    GetRealPath('c:\windows\system32\alg.exe')

    выдало

    C:\Windows\winsxs\amd64_microsoft-windows-alg_31bf3856ad364e35_6.1.7600.16385_none_04de43c774cf8fe3\alg.exe

    Вот это реально сделать?
  • Inovet © (23.03.11 11:03) [29]
    > [28] Gu   (23.03.11 10:24)
    > меня интересует получение рального пути вместо редиректорного

    А это не жёсткая ссылка? Для жёсткой все пути равноправны и нет особого "реального".
  • DVM © (23.03.11 11:28) [30]

    > Gu


    > C:\Windows\winsxs\amd64_microsoft-windows-alg_31bf3856ad364e35_6.
    > 1.7600.16385_none_04de43c774cf8fe3\alg.exe - вот как получить
    > этот путь?

    чем путь c:\windows\system32\alg.exe не устраивает?
  • Gu (23.03.11 13:44) [31]
    тем что он не настоящий
  • DVM © (23.03.11 19:09) [32]

    > Gu   (23.03.11 13:44) [31]

    C:\Windows\winsxs\amd64_microsoft-windows-alg_31bf3856ad364e35_6.
    > 1.7600.16385_none_04de43c774cf8fe3\alg.exe

    тоже не настоящий, есть еще более настоящий, тебе от этого станет легче?

    если по пути файл доступен - значит путь настоящий.
  • DVM © (23.03.11 19:31) [33]

    > Gu   (23.03.11 13:44) [31]

    Тебе уже сказали, что в NTFS на один и тот же файл, может быть создано сколько угодно жестких ссылок в разных каталогах и все эти ссылки РАВНОПРАВНЫ, то есть среди них нет главной и второстепенной. Это не как ярлыки Windows.
  • Gu (24.03.11 19:18) [34]
    >> тоже не настоящий
    это как раз настоящий

    >>эти ссылки РАВНОПРАВНЫ
    мне кажется, что это не так. на такие файлы действуют ограничения, для таких файлов не работают или работают некорректно некоторые файловые функции, например SHObjectProperties для (а5 пример для alg.exe) %SystemRoot%\System32\alg.exe не работает, для c:\windows\system32\alg.exe тоже, при включенном редиректе для c:\windows\system32\alg.exe - диалог показывает но свойства файла, такие как размер и др - нет, а если указать полный путь, то работает нормально.
    где то же в виндах зарыты эти правила редиректа, вот их бы вытащить и функцию написать о которой выше писал в [28].
  • Weei (26.06.11 11:20) [35]
    Может быть 32-х битные приложения "не видят" 64-х битных?
    У 32-х битных приложений них нет выхода в 64-х битное "оружение".
  • Alex Konshin © (01.08.11 02:38) [36]
    Поставь 64-bit Far и посмотри. Думаю, что сразу поймёшь в чём дело.
    В 64-битых Vista/2008/7 есть довольно много виртуальных фолдеров, которые видны по-разному, в зависимости от того, какой процесс (32 или 64 битный), какие права и т.п.. Windows\system32 один из них. Сравни содержимое этого директория в Far 32-bit и 64-bit. Они разные.
 
Конференция "WinAPI" » Хитрые файлы Win7
Есть новые Нет новых   [134431   +10][b:0.001][p:0.002]