FILE_BOTH_DIRECTORY_INFORMATION

Не могли бы вы мне подсказать размерность элементов этой структуры, а то я не врублюсь...

Code (Text):

1. type
2.  FILE_BOTH_DIRECTORY_INFORMATION = packed record
3.    NextEntryOffset: ULONG;
4.    Unknown: ULONG;
5.    CreationTime,
6.    LastAccessTime,
7.    LastWriteTime,
8.    ChangeTime,
9.    EndOfFile,
10.    AllocationSize: int64;
11.    FileAttributes: ULONG;
12.    FileNameLength: ULONG;
13.    EaInformationLength: ULONG;
14.    AlternateNameLength: ULONG;
15.    AlternateName[0..11]: array of WideChar;
16.    FileName: PWideChar;
17.  end;

Особенно интересует последний элемент. Это указатель на строку или что это? Пытаюсь Ms-Rem'a учить, пока, затык в этом.
При вызове ZwQueryDirectoryFile в параметре FileInformationLength находиться 0х268.
В общем, пока сплошные непонятки. Помогите разобраться, плиз.

 

pWideChar - это указатель на юникодовую строку (2 байта на символ)
Сам указатель размером в дворд

 

MagnumGT
Спасибо!

Я не нашел заголовочного файла, где определена эта структура.

 

MagnumGT
Странно. Почему тогда ZwQueryDirectoryFile в параметр FileInformationLength возвращает 0х268?
Вот, что я вижу в олли. Тут первые 75 байт.

Code (Text):

1. 0006CF7C  00 00 00 00 01 00 00 00 A0 77 EF 16 D1 97 C7 01  ....
   ... wпС—З
   
2. 0006CF8C  00 88 6B 2D 5C 13 C8 01 00 03 68 17 D1 97 C7 01  .?k-\И
   .hС—З
   
3. 0006CF9C  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
4. 0006CFAC  00 00 00 00 00 00 00 00 10 00 00 00 2C 00 00 00  ...........,...
5. 0006CFBC  00 00 00 00 10 00 44 00 4F 00 43               .....D.O.C
6.                                            00 55 00 4D 00           .U.M.
7. 0006CFCC  45 00 7E 00 31 00 00 00 00 00 00 00 00 00 44 00  E.~.1.........D.
8. 0006CFDC  6F 00 63 00 75 00 6D 00 65 00 6E 00 74 00 73 00  o.c.u.m.e.n.t.s.
9. 0006CFEC  20 00 61 00 6E 00 64 00 20 00 53 00 65 00 74 00   .a.n.d. .S.e.t.
10. 0006CFFC  74 00 69 00 6E 00 67 00 73 00 00 00 00 00 00 00  t.i.n.g.s.......
11. 0006D00C  00 00 00 00 20 D0 06 00 00 00 00 00 3D FB 90 7C  .... Р.....=ыђ|
12. 0006D01C  D4 D0 06 00 00 00 00 00 54 D0 06 00 6C FB 90 7C  ФР.....TР.lыђ|

Совсем не похоже на то, что нужно =\

 

Aspire
Почему тогда ... возвращает 0х268
Если за основу взять структуру Gary Nebbett'а

Code (Text):

1. typedef struct _FILE_BOTH_DIRECTORY_INFORMATION {
2.   ULONG NextEntryOffset;            // 4
3.   ULONG Unknown;                    // 4
4.   LARGE_INTEGER CreationTime;       // 8
5.   LARGE_INTEGER LastAccessTime;     // 8
6.   LARGE_INTEGER LastWriteTime;      // 8
7.   LARGE_INTEGER ChangeTime;         // 8
8.   LARGE_INTEGER EndOfFile;          // 8
9.   LARGE_INTEGER AllocationSize;     // 8
10.   ULONG FileAttributes;             // 4
11.   ULONG FileNameLength;             // 4
12.   ULONG EaInformationLength;        // 4
13.   UCHAR AlternateNameLength;        // 1
14.                                     // + 1 для выравнивания
15.                                     //     следующего
16.   WCHAR AlternateName[12];          // 24
17.   WCHAR FileName[1];                // 2
18.                                     // == 96 (0x60)
19. } FILE_BOTH_DIRECTORY_INFORMATION, *PFILE_BOTH_DIRECTORY_INFORMATION;

С параметра FileName полное начинается имя файла, если предположить, что оно 256 символов, т.е. 512 байт, то 96 + 510 = 606 (0x25E) останется найти еще 10 байтов.

 

Aspire
Сколько в FileNameLength?

 

Данные наверху, если я все правильно посчитал, то там 0х2С, т.е. 44 байта ("Documents and Senning" в юникоде)
Тогда что означает последний элемент FileName ? Если он два байта? Кстати, после юникодовой строки, где кончаются нули, мы там видим дворд 0х0060D020. ???

Хорошо. Я вот тут подумал, может, я вообще не туда смотрю, в смысле неправильно получаю эту структуру.
Поэтому приведу код, посмотрите, плиз.

Code (Text):

1. ;Перехватываю вызов ZwQueryDirectoryFile в том месте, где в стеке лежат параметры и сверху адрес возврата
2. LOCAL RAZMER   ;создаю локальную переменную
3. ------------;Здесь вызываю оригинальную функцию
4. .if (FileInformationClass==1|| FileInformationClass==2 || FileInformationClass==3 || FileInformationClass==12)
5.     mov edi,FileInformation
6.             .if FileInformationClass==3
7.         assume edi: ptr FILE_BOTH_DIRECTORY_INFORMATION
8.         mov RAZMER, sizeof FILE_BOTH_DIRECTORY_INFORMATION

Ну и дальше предполагается изменение этой структуры для скрытия файла...
В edi - указатель на структуру. Сами данные я приводил выше. Вроде все правильно...Остается со структурой разобраться.

 

UCHAR - 1 байт
ULONG - 4 байта
WCHAR - колво байт в скобках * 2
LARGE_INTEGER - 8 байт

 

Aspire
что означает последний элемент FileName ? Если он два байта?
С этого места начинается _длинное_имя_. Это поле используется совместно с FileNameLength. Т.е. прежде чем делать что-либо с FileName настоятельно рекомендую прочитать из FileNameLength со сколькими байтами можно работать.

При вызове ZwQueryDirectoryFile в параметре FileInformationLength находиться 0х268.
Кажется, я понял вопрос.
Фактически FILE_BOTH_DIRECTORY_INFORMATION имеет переменную длину. 94 байта постоянных, плюс к ним добавляются байты, в которых хранится _длинное_имя_. Вызывающая ZwQueryDirectoryFile программа _обязана_ позаботиться, чтобы буфер (шестой параметр) был достаточного размера, т.е. не меньше чем sizeof(FILE_BOTH_DIRECTORY_INFORMATION) + ожидаемый размер имени файла.

MagnumGT

твое #8 противоречит твоему #2, ты тему читаешь или только пишешь?

 

Следующий трабл. Ставлю бряк после вызова ф-ции, смотрю на структуру, в поле NextEntryOffset имеем ноль, что говорит, что это последняя структура в массиве. Жму F9, останавливаюсь еще раз, структура уже другая, имя файла другое, а в поле NextEntryOffset все равно ноль. Так она у меня и фигачит по кругу, пока в параметре FileInformation не появиться -1. И каждый раз NextEntryOffset==0. Почему такая фигня? Может для разных файловых систем поразному (у меня фат32) ? Как в моем случае мне скрыть свой файл при совпадении имен?

 

Aspire
Прежде чем смотреть на NextEntryOffset необходимо убедиться, что оригинальная ZwQueryDirectoryFile завершилась успешно. Ноль в NextEntryOffset означает, что в буфере содержится информация об одном (очередном) файле, информация о следующем, например, не помещается.

фигачит по кругу, пока в параметре FileInformation не появиться -1
Как в FileInformation может быть -1? Это же адрес.

Как в моем случае мне скрыть свой файл при совпадении имен?
Т.е. когда информация поступает по одному файлу?
Например, определив, что пришла информация по твоему файлу еще раз вызвать оригинальную ZwQueryDirectoryFile, чтобы она заполнила буфер информацией о следующем(щих) файле(ах).

 

q_q

Мое 2 - я просто посчитал число байтов из топика Аспайра
А мое 8 - это я выдернул из своей программы. Мое 2 можно удалять, ибо неактуально

 

[off]
MagnumGT
Мое 2 - я просто посчитал число байтов из топика Аспайра
Я не зря спросил "читаешь ли ты", например, в #1 поля CreationTime, LastAccessTime, LastWriteTime, ChangeTime, EndOfFile определены как int64, а ты указал их размер 4.

Мое 2 можно удалять, ибо неактуально
Тогда вопрос: "Можно ли считать хоть одно твое сообщение в этой теме актуальным (т.е. не содержащим очевидные ошибки, не дублирующим другие сообщения и относящимся к теме)?"
[/off]

 

q_q
[/off]
Я ошибся. Я это признал.
Мне уйти с ВАСМА?
[/off]

 

[off]
MagnumGT
Не горячись. Думай прежде чем постить.
[/off]

 

q_q
Ага, оригинальная ф-ция возвращает ноль.

Все просто оказывается. Спасибо. Просто меня ввело в ступор, то, что ZwQueryDirectoryFile "возвращает информацию об одном (очередном) файле"...
Еще раз, сенкс!