Почитал тут статью http://www.wasm.ru/article.php?article=dumping но так как и с Kernel mode и с английским я на ВЫ, синий экран не даёт жить спокойно. Собственно нужно сделать дамп главного треда User Mode приложения Беру PID, получаю hProcess а дальше Код (Text): void CopyProcessMem(HANDLE hProcess, PVOID SrcAddr, PVOID DstAddr, ULONG *Size) { PEPROCESS process = NULL; NTSTATUS st; PUCHAR pMem = NULL; ULONG Addr, Bytes; PUCHAR cPtr, dPtr; KAPC_STATE ApcState; st = ObReferenceObjectByHandle(hProcess, 0, NULL, UserMode, &process, NULL); if (NT_SUCCESS(st)) { Bytes = *Size; pMem = ExAllocatePool(NonPagedPool, Bytes); dPtr = pMem; cPtr = (PUCHAR)SrcAddr; KeStackAttachProcess(process, &ApcState); __try { while (Bytes) { *dPtr = *cPtr; cPtr++; dPtr++; Bytes --; } } __except(EXCEPTION_EXECUTE_HANDLER) { } KeUnstackDetachProcess(&ApcState); Bytes = *Size - Bytes; __try { memcpy(DstAddr, pMem, Bytes); *Size = Bytes; } __except(EXCEPTION_EXECUTE_HANDLER) { } ExFreePool(pMem); ObDereferenceObject(process); } return; } Где собственно и появляется синий экран Что должно быть здесь? Код (Text): PVOID SrcAddr, PVOID DstAddr И как выделять память Просьба ссылками не Бросаться!
ExAllocatePool(NonPagedPool, 1024); Я ж говорю я хз как память выделять то и что это за шляпа? !analyze -v?
Size == 1024? '!analyze -v' -- команда WinDbg, анализирующая minidump. Ну или как вариант можно minidump сюда выложить, кто-нибудь посмотрит.
Код (Text): Microsoft (R) Windows Debugger Version 6.11.0001.404 X86 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\WINDOWS\Minidump\Mini112811-03.dmp] Mini Kernel Dump File: Only registers and stack trace are available Symbol search path is: *** Invalid *** **************************************************************************** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After setting your symbol path, use .reload to refresh symbol locations. * **************************************************************************** Executable search path is: ********************************************************************* * Symbols can not be loaded because symbol path is not initialized. * * * * The Symbol Path can be set by: * * using the _NT_SYMBOL_PATH environment variable. * * using the -y <symbol_path> argument when starting the debugger. * * using .sympath and .sympath+ * ********************************************************************* Unable to load image ntoskrnl.exe, Win32 error 0n2 *** WARNING: Unable to verify timestamp for ntoskrnl.exe *** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Machine Name: Kernel base = 0x804d7000 PsLoadedModuleList = 0x805634c0 Debug session time: Mon Nov 28 00:39:29.343 2011 (GMT+2) System Uptime: 0 days 0:13:26.035 ********************************************************************* * Symbols can not be loaded because symbol path is not initialized. * * * * The Symbol Path can be set by: * * using the _NT_SYMBOL_PATH environment variable. * * using the -y <symbol_path> argument when starting the debugger. * * using .sympath and .sympath+ * ********************************************************************* Unable to load image ntoskrnl.exe, Win32 error 0n2 *** WARNING: Unable to verify timestamp for ntoskrnl.exe *** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe Loading Kernel Symbols ............................................................... ................................................................ . Loading User Symbols Loading unloaded module list .............. Unable to load image TC.sys, Win32 error 0n2 ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 1000007E, {c0000005, f799d4f9, f78e2738, f78e2434} ***** Kernel symbols are WRONG. Please fix symbols to do analysis. ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ********************************************************************* * Symbols can not be loaded because symbol path is not initialized. * * * * The Symbol Path can be set by: * * using the _NT_SYMBOL_PATH environment variable. * * using the -y <symbol_path> argument when starting the debugger. * * using .sympath and .sympath+ * ********************************************************************* ********************************************************************* * Symbols can not be loaded because symbol path is not initialized. * * * * The Symbol Path can be set by: * * using the _NT_SYMBOL_PATH environment variable. * * using the -y <symbol_path> argument when starting the debugger. * * using .sympath and .sympath+ * ********************************************************************* Probably caused by : TC.sys ( TC!CopyProcessMem+69 ) Followup: MachineOwner --------- 1: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e) This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address. Some common problems are exception code 0x80000003. This means a hard coded breakpoint or assertion was hit, but this system was booted /NODEBUG. This is not supposed to happen as developers should never have hardcoded breakpoints in retail code, but ... If this happens, make sure a debugger gets connected, and the system is booted /DEBUG. This will let us see why this breakpoint is happening. Arguments: Arg1: c0000005, The exception code that was not handled Arg2: f799d4f9, The address that the exception occurred at Arg3: f78e2738, Exception Record Address Arg4: f78e2434, Context Record Address Debugging Details: ------------------ ***** Kernel symbols are WRONG. Please fix symbols to do analysis. ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ********************************************************************* * Symbols can not be loaded because symbol path is not initialized. * * * * The Symbol Path can be set by: * * using the _NT_SYMBOL_PATH environment variable. * * using the -y <symbol_path> argument when starting the debugger. * * using .sympath and .sympath+ * ********************************************************************* ********************************************************************* * Symbols can not be loaded because symbol path is not initialized. * * * * The Symbol Path can be set by: * * using the _NT_SYMBOL_PATH environment variable. * * using the -y <symbol_path> argument when starting the debugger. * * using .sympath and .sympath+ * ********************************************************************* ADDITIONAL_DEBUG_TEXT: Use '!findthebuild' command to search for the target build information. If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols. MODULE_NAME: TC FAULTING_MODULE: 804d7000 nt DEBUG_FLR_IMAGE_TIMESTAMP: 4ed2bc1a EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - <Unable to get error code text> FAULTING_IP: TC!CopyProcessMem+69 [c:\tc\tc.c @ 57] f799d4f9 8b02 mov eax,dword ptr [edx] EXCEPTION_RECORD: f78e2738 -- (.exr 0xfffffffff78e2738) ExceptionAddress: f799d4f9 (TC!CopyProcessMem+0x00000069) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 00000400 Attempt to read from address 00000400 CONTEXT: f78e2434 -- (.cxr 0xfffffffff78e2434) eax=00000000 ebx=00000000 ecx=e1003e44 edx=00000400 esi=e334a266 edi=886fa5d8 eip=f799d4f9 esp=f78e2800 ebp=f78e285c iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00210246 TC!CopyProcessMem+0x69: f799d4f9 8b02 mov eax,dword ptr [edx] ds:0023:00000400=???????? Resetting default scope CUSTOMER_CRASH_COUNT: 3 DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0x7E LAST_CONTROL_TRANSFER: from f799e05e to f799d4f9 STACK_TEXT: f78e285c f799e05e 00000850 00400000 f78e2874 TC!CopyProcessMem+0x69 [c:\tc\tc.c @ 57] f78e2c84 805a5303 886fa5d8 8670c000 00000000 TC!DriverEntry+0x14e [c:\tc\tc.c @ 174] WARNING: Stack unwind information not available. Following frames may be wrong. f78e2d54 805aeee7 80000c20 00000001 00000000 nt+0xce303 f78e2d7c 804e23d5 80000c20 00000000 89bb9020 nt+0xd7ee7 f78e2dac 80576316 a971cc6c 00000000 00000000 nt+0xb3d5 f78e2ddc 804ec6f9 804e2311 00000001 00000000 nt+0x9f316 00000000 00000000 00000000 00000000 00000000 nt+0x156f9 FOLLOWUP_IP: TC!CopyProcessMem+69 [c:\tc\tc.c @ 57] f799d4f9 8b02 mov eax,dword ptr [edx] FAULTING_SOURCE_CODE: 53: st = ObReferenceObjectByHandle(hProcess, 0, NULL, UserMode, &process, NULL); 54: 55: if (NT_SUCCESS(st)) 56: { > 57: Bytes = *Size; 58: pMem = ExAllocatePool(NonPagedPool, Bytes); 59: dPtr = pMem; 60: 61: cPtr = (PUCHAR)SrcAddr; 62: SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: TC!CopyProcessMem+69 FOLLOWUP_NAME: MachineOwner IMAGE_NAME: TC.sys STACK_COMMAND: .cxr 0xfffffffff78e2434 ; kb BUCKET_ID: WRONG_SYMBOLS Followup: MachineOwner --------- 1: kd> .exr 0xfffffffff78e2738 ExceptionAddress: f799d4f9 (TC!CopyProcessMem+0x00000069) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 00000400 Attempt to read from address 00000400
Судя по всему, вместо указателя на Size передано значение самого Size. Оно, кстати, равно 1024. И да, неплохо бы настроить символы, чтобы скачались. Без них тяжело будет. File ->Symbol File Path, вводим значение: srv*_full_path_to_symbol_directory_*http://msdl.microsoft.com/download/symbols _full_path_to_symbol_directory_ заменяем на реальный путь в файловой системе.
skyproc Падает на этой строчке: Ты правильно передал параметры ? покажи как передаешь . Упс...опередили)
НЕ правильно!!! исправил, но тут ещё как минимум один косяк который опять же синий экран вызывает. Так всё таки PVOID SrcAddr - это указатель на переменную содержащую адрес с которого будем читать из юзер мода к примеру 0x400000 PVOID DstAddr - это указатель на переменную содержащую адрес буфера в ядре? ???
Назревает драма. Какой !analyze -v теперь? (Желательно с символами) И что вообще требуется сделать? Прочитать память процесса в память ядра? Тогда да, в DstAddr надо положить указатель на ExAllocatePool(...);
Спакойстьвие только спакойстьвие!!! Драмма разрешилась, грабли раскидал всё пашет. Наверное.... В буфере есть какой то мусор после выполнения поставленной задачи А ExAllocatePool(NonPagedPool, 1024); Ваще чистый пул выделяет или? Суде по тому что дампы каждый раз разные пул надо бы мыть перед использованием И всёже мрак над параметром PVOID SrcAddr - это указатель на переменную содержащую адрес с которого будем читать из юзер мода к примеру 0x400000 ??????
Фуффффф С этой задачей справился! Теперь задача посложнее, как её реализовать ума не приложу. Процесс юзер мода продавпил, теперь нужно модифицировать его данные, код, регистры CPU и и продолжить его выполнение с указанной точки.
