Че это за инструкция такая??

Вот весь код:

8B D4 0F 05 C3

Это SYSCALL. Вот что пишет AMD по этому поводу:

AMD 64-Bit Technology 24594 Rev. 3.02 August 2002

Mnemonic Opcode Description
SYSCALL 0F 05 Call operating system.
Action
// See “Pseudocode Definitions” on page 48.
SYSCALL_START:
IF (MSR_EFER.SCE = 0) // Check if syscall/sysret are enabled.
EXCEPTION [#UD]
IF (LONG_MODE)
SYSCALL_LONG_MODE
ELSE // (LEGACY_MODE)
SYSCALL_LEGACY_MODE
SYSCALL_LONG_MODE:
RCX.q = next_RIP
R11.q = RFLAGS // with rf cleared
IF (64BIT_MODE)
temp_RIP.q = MSR_LSTAR
ELSE // (COMPATIBILITY_MODE)
temp_RIP.q = MSR_CSTAR
CS.sel = MSR_STAR.SYSCALL_CS AND 0xFFFC
CS.attr = 64-bit code,dpl0 // Always switch to 64-bit mode in long mode.
CS.base = 0x00000000
CS.limit = 0xFFFFFFFF
SS.sel = MSR_STAR.SYSCALL_CS + 8
SS.attr = 64-bit stack,dpl0
SS.base = 0x00000000
SS.limit = 0xFFFFFFFF
RFLAGS = RFLAGS AND ~MSR_SFMASK
RFLAGS.RF = 0
CPL = 0
RIP = temp_RIP
EXIT
SYSCALL_LEGACY_MODE:
RCX.d = next_RIP
temp_RIP.d = MSR_STAR.EIP
CS.sel = MSR_STAR.SYSCALL_CS AND 0xFFFC
CS.attr = 32-bit code,dpl0 // Always switch to 32-bit mode in legacy mode.
CS.base = 0x00000000
CS.limit = 0xFFFFFFFF
SS.sel = MSR_STAR.SYSCALL_CS + 8
SS.attr = 32-bit stack,dpl0
SS.base = 0x00000000
SS.limit = 0xFFFFFFFF
RFLAGS.VM,IF,RF=0
CPL = 0
RIP = temp_RIP
EXIT

Вобщем смысл такой, что адрес возврата сохраняется в RCX, а RIP,SS,CS загружаются из машинно-специфичных регистров.

Есть ли такая команда на 32х битных процессорах, сказать не могу.

Вспомнил, на 286 процессоре это вроде был loadall. Может кто расскажет как он работал?

Короче, я протрассировал одну прогу, вылетел на какую-то функцию (код 8B D4 0F 05 C3). Полсе вызова SYSCALL (или LOADALL), че-то пишется в реестр. Вот те данные, которые пишутся в реестр мне надо исследовать, т.е. узнать как они генерятся. Но до и после вызова я просмотрел память процесса, и там таких данных (которые записались в ресстр) не было. ПОЧЕМУ??

А перед этим кодом есть mov eax,func_num?
Или это начало процедуры, а eax устанавливает вызывающая процедура?
Возможно что функции записи в реестр были вызванны задолго до этого, но данные пока находятся в оперативной памяти какой-нибудь службы доступа к реестру, а эта функция сообщает ей что пора их сохранить на диске?

Где-то в ntdll:

mov eax, 54
mov edx, 7FFE0300
call edx
retn 28
nop

А по адресу 7FFE0300:

mov edx, esp
loadall // в OllyDbg написано sysenter
ret


Нет, я трассировал и одновременно смотрел в regmon. И только после вызова SYSCALL (или LOADALL), там че-то засветилось.

В какой службе могут находиться данные??

Под ХР и 2003 SYSCALL это переход в режим ядра, под NT4 и 2000 это было int 2E.

В eax помещается индекс функции ядра которую надо вызвать.
Указатель на массив адресов этих функций находится в первом DWORD KeServiceDescriptorTable.

У меня под ХР получилось, что за номером 54 значится NtFsControlFile.

Как получить ункцию по индексу см. тут: Загрузка в дебагеры

Про сам переход в режим ядра много где написано, например тут: Inside the Native API


А IDA вот, что говорит:

.text:77F7E8F3 ZwFsControlFile proc near
.text:77F7E8F3
.text:77F7E8F3                 mov     eax, 54h        ; NtFsControlFile
.text:77F7E8F8                 mov     edx, 7FFE0300h
.text:77F7E8FD                 call    edx
.text:77F7E8FF                 retn    28h
.text:77F7E8FF ZwFsControlFile endp

Я нашел документацию по NtFsControlFile.

NTSYSAPI
NTSTATUS
NTAPI
NtFsControlFile(

IN HANDLE FileHandle,
IN HANDLE Event OPTIONAL,
IN PIO_APC_ROUTINE ApcRoutine OPTIONAL,
IN PVOID ApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN ULONG FsControlCode,
IN PVOID InputBuffer OPTIONAL,
IN ULONG InputBufferLength,
OUT PVOID OutputBuffer OPTIONAL,
IN ULONG OutputBufferLength );

Если она так вызывается (никаких push'ок), то где все эти параметры (и данные, которые сохраняются в реестр)?

.text:77F7E8F3 ZwFsControlFile proc near
.text:77F7E8F3
.text:77F7E8F3 mov eax, 54h ; NtFsControlFile
.text:77F7E8F8 mov edx, 7FFE0300h
.text:77F7E8FD call edx
.text:77F7E8FF retn 28h
.text:77F7E8FF ZwFsControlFile endp

А Ctrl+X нажать, да ссылки посмотреть, лень?

.text:77F68BA1                 mov     eax, ds:7FFE02DCh
.text:77F68BA6                 push    edi
.text:77F68BA7                 push    edi
.text:77F68BA8                 push    edi
.text:77F68BA9                 push    edi
.text:77F68BAA                 push    90028h
.text:77F68BAF                 mov     dword_77FC5088, eax
.text:77F68BB4                 lea     eax, [ebp-18h]
.text:77F68BB7                 push    eax
.text:77F68BB8                 push    edi
.text:77F68BB9                 push    edi
.text:77F68BBA                 push    edi
.text:77F68BBB                 push    dword ptr [esi+8]
.text:77F68BBE                 call    ZwFsControlFile

NtFsControlFile это функция файловой системы и к реетру никакого отношения не имеет, ну если только она напрямую в куст реестра на диске не пишет.

Ты зря так глубоко полез - заблудишься. Если у тя что-то в реестр пишется попробуй начать со стандартных функций работы с реестром. Только не залезай внутрь - это не имеет смысла. Запусти RegMon и посмотри что и куда в реестр кладется и потом ищи где это.

Запустил RegMon, запустил OllyDbg. Начинаю трассировать, одновременно смотря в RegMon. Дохожу до какого-то места, вызываю sysenter, в RegMon'е появляется запись, причем от LSASS.EXE.

Может быть эта функция никакого хрена не относится к реетру, но тогда какого хрена она пишет мне в реестр? И почему от LSASS? И где эти данные, что туда пишутся (мне надо знать как они генерятся)?

PS Ось у меня тоже XP.

А может, это нормально, lsass проверяла какой-ниб дескриптор? Проверь, не в hklm\security ли она совалась - она всегда туда лезет при всех манипуляциях с секьюрити в гуях. Может, sysenter с кодом данной функции под хрюшей указывает на какую-нибудь заглушку и управление передается lsass? Тогда ты на ложном пути и зря застрял в ntdll. lsass как я понимаю юзерская (win32)и что-то дежурное написала в реестр а ты решил что это отлаживаемый апп.
Кстати, а что он написала? Ты не сравнивал последовательность ее действий с тем, например, что бывает, когда lsass читает, когда ты делешь ctrl alt del lock?

Валера, так все и есть! :)) Только че мне с lsass делать?

я протрассировал одну прогу

А, доперло до меня, тебя как раз ядровая секьюрити и интересует! И прога - ntdll... Ну тогда тебе поможет только Four-F. Или сам поищи что у Руссиновича в книжке про winlogon и lsass (это гуевая приблуда над ним)

[ antonyo: вызываю sysenter, в RegMon'е появляется запись... ]

Ты прочитал статью на sysinternals по ссылке вверху? sysenter осуществляет переход в режим ядра.
ntdll!NtFsControlFile это просто юзерная заглушка. Она ничего не делает, кроме как вызывает одноименную ntoskrnl!NtFsControlFile.
Т.е. когда ты на sysenter нажал F10, то выполнил целую функцию в ядре, а она может быть охриненных размеров.

Набери в айсе exp NtFsC и увидишь ее адрес.

Я не знаю каким боком NtFsControlFile относится к реестру. Возможно она вызывает какую-то реестровую функцию - хрен его знает.
А возможно пишет что-то прямо в куст реестра. Куст - это кусок реестра в виде файла на диске. В общем - хз.

Судя по твоей фразе "...я протрассировал одну прогу..." ты не саму ось мучаешь. Тогда не имеет смысла так глубоко залезать в ядро.
Когда прога стартует к реестру туча обращений идет. Ты уверен что это именно то, что те нужно. В любом случае, не залезай так глубоко. Это ничего не даст, только время потеряешь. Даже в ntdll не лезь. Постарайся понять на более высоком уровне что происходит.

ЗЫ: А Соломона почитай.

Нее... Я прогу запускаю, нажимаю в ней пару кнопочек, а дальше у меня сразу же идет брейк. После этого прога записывает эти данные в реестр. Ну короче я уверен, что это именно то, че мне нужно. :) И мне пофигу какой функцией они пишутся, мне надо знать где в памяти эти данные хранятся, чтобы реверснуть их потом. Может в lsass.exe их поискать??