bsod

Тема в разделе "WASM.X64", создана пользователем Ahimov, 7 мар 2025.

Страница 4 из 4
  1. Ahimov

    Ahimov Active Member

    Публикаций:
    0
    Регистрация:
    14 окт 2024
    Сообщения:
    174
    А как тогда обьяснить тот крэш со свапконтект, где стектрейс не портится ?

    Нужно вернуться и еще раз внимательно разобрать. В остальных дампах по мойму какой то треш, цепочки #pf.

    > DbgkpQueueMessage

    Хорошая мысль, это может обьяснить откуда они dbg* берутся, когда вроде быть не должно их.

    Как думаете, почему только при загрузке флагов падает и только под дебагпортом?

    Ну и что дальше сделать ?

    ps извините за правку текста, эта вирт клава на телефоне меня добивает :)
    --- Сообщение объединено, 23 мар 2025 в 02:01 ---
    HoShiMin,

    > посмотри на предыдущую инструкцию там call KeAbPostRelease

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

    Код (Text):
    1. .text:000000014021DFB0 ; Exported entry 1275. KeReleaseGuardedMutex
    2. .text:000000014021DFB0
    3. .text:000000014021DFB0 ; =============== S U B R O U T I N E =======================================
    4. .text:000000014021DFB0
    5. .text:000000014021DFB0
    6. .text:000000014021DFB0 ; void __stdcall KeReleaseGuardedMutex(PKGUARDED_MUTEX Mutex)
    7. .text:000000014021DFB0                 public KeReleaseGuardedMutex
    8. .text:000000014021DFB0 KeReleaseGuardedMutex proc near         ; CODE XREF: CcWriteBehindInternal+1A5↓p
    9. .text:000000014021DFB0                                         ; CcWriteBehindInternal+294↓p ...
    10. .text:000000014021DFB0
    11. .text:000000014021DFB0 arg_0           = qword ptr  8
    12. .text:000000014021DFB0
    13. .text:000000014021DFB0 ; FUNCTION CHUNK AT .text:0000000140427778 SIZE 00000067 BYTES
    14. .text:000000014021DFB0
    15. .text:000000014021DFB0                 mov     [rsp+arg_0], rbx ; ExReleaseFastMutex
    16. .text:000000014021DFB5                 push    rdi
    17. .text:000000014021DFB6                 sub     rsp, 20h
    18. .text:000000014021DFBA                 movzx   edi, byte ptr [rcx+30h]
    19. .text:000000014021DFBE                 mov     rbx, rcx
    20. .text:000000014021DFC1                 mov     qword ptr [rcx+8], 0
    21. .text:000000014021DFC9                 xor     eax, eax
    22. .text:000000014021DFCB                 mov     ecx, 1
    23. .text:000000014021DFD0                 lock cmpxchg [rbx], ecx
    24. .text:000000014021DFD4                 jnz     short loc_14021DFFC
    25. .text:000000014021DFD6
    26. .text:000000014021DFD6 loc_14021DFD6:                          ; CODE XREF: KeReleaseGuardedMutex+56↓j
    27. .text:000000014021DFD6                 mov     eax, cs:KiIrqlFlags
    28. .text:000000014021DFDC                 test    eax, eax
    29. .text:000000014021DFDE                 jnz     loc_140427778
    30. .text:000000014021DFE4
    31. .text:000000014021DFE4 loc_14021DFE4:                          ; CODE XREF: KeReleaseGuardedMutex+2097CA↓j
    32. .text:000000014021DFE4                                         ; KeReleaseGuardedMutex+2097D6↓j ...
    33. .text:000000014021DFE4                 mov     cr8, rdi
    34. .text:000000014021DFE8                 mov     rcx, rbx        ; BugCheckParameter2
    35. .text:000000014021DFEB                 call    KeAbPostRelease
    Есть еще нюанс, это ведь статик диз, а что на самом деле там в ядре не известно. В принципе если бы были внесены изменения, то в дампах были левые адреса.
    --- Сообщение объединено, 23 мар 2025 в 02:12 ---
    Ладно не охота, надоели крэши :)

    x32dbg: push 0/popf. Посмотрим что в дампе.
    --- Сообщение объединено, 23 мар 2025 в 02:18 ---
    DRIVER_OVERRAN_STACK_BUFFER


    Не знаю почему так, раньше иначе падало. После крэша испортился гуи.
    --- Сообщение объединено, 23 мар 2025 в 02:26 ---
    ida синь с тем же дампом.
    --- Сообщение объединено, 23 мар 2025 в 02:26 ---
    Код (Text):
    1. ffff9606`18931a98 fffff807`3a2b63c5     : 00000000`000000f7 ffff9606`18932cf0 00008203`28e2892b ffff7dfc`d71d76d4 : nt!KeBugCheckEx
    2. ffff9606`18931aa0 fffff807`3a1d5a8e     : ffff9606`189320b0 fffff807`3a0ca5df fffff807`39f1bf38 00000000`00000000 : nt!_report_gsfailure+0x25
    3. ffff9606`18931ae0 fffff807`3a1d5a23     : ffff9606`18931bb0 00000000`00000000 ffff9606`189320e8 ffff9606`189320c0 : nt!_GSHandlerCheckCommon+0x5a
    4. ffff9606`18931b10 fffff807`3a207d2f     : fffff807`3a1d5a10 00000000`00000000 00000000`00000000 00000000`00000000 : nt!_GSHandlerCheck+0x13
    5. ffff9606`18931b40 fffff807`3a0ca3c7     : ffff9606`189320b0 00000000`00000000 ffff9606`18932cf0 fffff807`3a688daa : nt!RtlpExecuteHandlerForException+0xf
    6. ffff9606`18931b70 fffff807`3a0c94e6     : ffff9606`18932a88 ffff9606`189327c0 ffff9606`18932a88 00000000`00000000 : nt!RtlDispatchException+0x297
    7. ffff9606`18932290 fffff807`3a21186c     : 00000000`00001000 ffff9606`18932b30 ffff8000`00000000 00000000`00000000 : nt!KiDispatchException+0x186
    8. ffff9606`18932950 fffff807`3a20d2bd     : ffff9781`05a22080 00000000`00000002 00000000`00000000 fffff807`3aa47960 : nt!KiExceptionDispatch+0x12c
    9. ffff9606`18932b30 fffff807`3a01dfba     : ffff9781`05a22080 fffff807`3a688da5 00000000`00000010 00000000`00000246 : nt!KiPageFault+0x43d
    10. ffff9606`18932cc0 fffff807`3a688daa     : fffff807`3aa47960 ffff9781`00000000 00000000`00000000 ffff9606`18932fa0 : nt!ExReleaseFastMutex+0xa
    11. ffff9606`18932cf0 00000000`00000001     : 00000000`0009fda0 ffff9606`18933a58 ffff9781`06bf2080 ffff9781`06bf2080 : nt!DbgkpQueueMessage+0x222
    12. ffff9606`18932ef0 00000000`0009fda0     : ffff9606`18933a58 ffff9781`06bf2080 ffff9781`06bf2080 00000000`00000001 : 0x1
    13. ffff9606`18932ef8 ffff9606`18933a58     : ffff9781`06bf2080 ffff9781`06bf2080 00000000`00000001 fffff807`3a68a868 : 0x9fda0
    14. ffff9606`18932f00 ffff9781`06bf2080     : ffff9781`06bf2080 00000000`00000001 fffff807`3a68a868 00000000`00000000 : 0xffff9606`18933a58
    15. ffff9606`18932f08 ffff9781`06bf2080     : 00000000`00000001 fffff807`3a68a868 00000000`00000000 00000000`00000000 : 0xffff9781`06bf2080
    16. ffff9606`18932f10 00000000`00000001     : fffff807`3a68a868 00000000`00000000 00000000`00000000 00000000`00000000 : 0xffff9781`06bf2080
    17. ffff9606`18932f18 fffff807`3a68a868     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x1
    18. ffff9606`18932f20 fffff807`3a629b31     : ffff9781`04b4fdf0 ffff9606`18933070 ffff9781`06bf2080 00000000`00000000 : nt!DbgkpSendApiMessage+0xa4
    19. ffff9606`18932f70 fffff807`3a0c9694     : ffff9606`18933a58 ffff9606`18933a58 ffff9606`18933120 00000000`00401003 : nt!DbgkForwardException+0xfa161
    20. ffff9606`189330f0 fffff807`3a21186c     : 00000000`00001000 ffff9606`18933b00 ffff8000`00000000 00000000`00000000 : nt!KiDispatchException+0x334
    21. ffff9606`18933920 fffff807`3a20d2bd     : ffff9781`05a22080 00000000`00000000 00000000`00000000 ffff9781`00000000 : nt!KiExceptionDispatch+0x12c
    22. ffff9606`18933b00 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x43d
     

    Вложения:

    Последнее редактирование: 23 мар 2025 в 02:02
    Ahimov, 23 мар 2025 в 01:32
    #61
  2. HoShiMin

    HoShiMin Well-Known Member

    Публикаций:
    5
    Регистрация:
    17 дек 2016
    Сообщения:
    1.493
    Адрес:
    Россия, Нижний Новгород
    Теперь постоянно одна и та же причина - испорчен стек.
    nt!RtlpExecuteHandlerForException+0xf
    Вот тут мы вызываем обработчик, и на выходе ломается stack cookie, не дав нормально обработать PF.
    Непонятна и сама причина PF в ExReleaseFastMutex'е, и почему ломается стек в обработчике.

    Залей ещё свой ntoskrnl.exe: думаю, у нас отличаются билды.
     
    HoShiMin, 23 мар 2025 в 14:05
    #62
  3. Ahimov

    Ahimov Active Member

    Публикаций:
    0
    Регистрация:
    14 окт 2024
    Сообщения:
    174
    HoShiMin,

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

    upd А нет, в последнем дампе шед:
    Код (Text):
    1. fffff883`fb474730 fffff807`5f01b1cf     : ffffaa8f`341c9080 fffff807`5fb27a00 fffff883`fb4748f0 00000000`00000000 : nt!KiSwapThread+0x6db
    2. fffff883`fb4747e0 fffff807`5f01aa73     : 00000000`00000033 fffff807`00000000 00000000`00000001 ffffaa8f`341c91c0 : nt!KiCommitThreadWait+0x14f
    3. fffff883`fb474880 fffff807`5f689d21     : ffffaa8f`35a63b30 00000000`00000000 fffff883`fb474b01 fffff807`5b244101 : nt!KeWaitForSingleObject+0x233
    4. fffff883`fb474970 fffff807`5f210ef5     : ffffaa8f`341c9080 00000225`2638f400 00000000`00000000 ffffaa8f`35a63b01 : nt!NtWaitForDebugEvent+0x261
    5. fffff883`fb474b00 00007ffe`7ee70a34     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25
    6. 000000f2`053ff288 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffe`7ee70a34
    7.  
    8.  
    9. SYMBOL_NAME:  nt!KiSwapThread+6db
    10.  
    --- Сообщение объединено, 23 мар 2025 в 15:58 ---
    Интересно если поток крутить как при racecond атаке(suspend/resume) будет ли падать :scratch_one-s_head:
    --- Сообщение объединено, 23 мар 2025 в 16:08 ---
    Не падает без отладчика, под отладчиком пока не буду проверять.

    Код (Text):
    1. Thread proc p1:DWORD
    2. Local Ctx:CONTEXT
    3. @@:
    4.     mov Ctx.ContextFlags,CONTEXT_ALL
    5.     invoke GetThreadContext, Thd, addr Ctx
    6.     jmp @b
    7. Thread endp
    8.  
    9.  
    10. EP proc
    11. Local Ctx:CONTEXT
    12.       invoke CreateThread, 0, 0, addr Thread, 0, 0, addr Tid
    13.     mov Thd,eax
    14. Iter:
    15.     .repeat
    16.         invoke ZwSuspendThread, Thd, addr Scount
    17.         mov Ctx.ContextFlags,CONTEXT_ALL
    18.         invoke GetThreadContext, Thd, addr Ctx
    19.         invoke ZwResumeThread, Thd, addr Scount
    20.     .until Etrap
    --- Сообщение объединено, 23 мар 2025 в 16:30 ---
    Можно видимо пофиксить отладчики, убрать NtResumeThread, отфильтровав целевой тред, затем будет вызов NtDebugContinue, который запустит поток. Но это наверно не нужно)
     
    Последнее редактирование: 23 мар 2025 в 15:54
    Ahimov, 23 мар 2025 в 15:43
    #63
Страница 4 из 4