XP running on a 486 cpu

[pappyN4]

@Dietmar Someone else on osdev forums had same idea as roytam1.  For 'lock cmpxchg8b', CLI, then emulated cmpxchg, then STI.  Cheat for single core CPU anyways..

[user57]

there might be there would be would be the REP command

https://www.felixcloutier.com/x86/rep:repe:repz:repne:repnz

it can have a lock prefix 

 

it is actually used for buffers not for smallers moves 

[roytam1]

1 hour ago, user57 said:

there might be there would be would be the REP command

https://www.felixcloutier.com/x86/rep:repe:repz:repne:repnz

it can have a lock prefix 

 

it is actually used for buffers not for smallers moves 

it may not work and cause #UD on new processors.

https://jeffpar.github.io/kbarchive/kb/076/Q76727/

[user57]

well honestly i actually do not want to study the entire thing behind that 
  
if its a PCB control(what i dont know - nor think) you have to study the entire function chain for this - the entirety of windows in relation to this
at least the entire reaction related to that SLIST_HEADER/PKSPIN_LOCK strucuture is needed 
that raise a big question why that 2 strucutes would actually be that - sounds at least very odd to me
so i want to say im out of this for now

i remember intel removed the lock prefix as a virus once used it to hide its activity/itself(if i remember correct
it execute the lock prefix - but it no longer has any effect - that lets normal activity continue)

that description from masm archiv tells us that lock rep where removed already on a 286 cpu, so a 486 is affected (wanna go back to a 186 ? (joke))

a different cpu however needs some time to react, if a interference should happen, to be honest i dont think so

and i changed up the entire IDT table and even made it invalid, not even execution 10 commands caused a problem - if there would be a fault in the 10 command then maybe but
this is not the case 

this mov commands are however in nanosecond´s area, i dont think it actually can that it can interrupt this so fast
a thread/cpu switch takes time
rather 10 milliseconds would be something here (for others nano are a lot faster then 1 ms 1000 ns = 1 ms)

if the thinking was about some kind of high language problem like "java atom" 
java and programming languages dont have atom based relations that rather comes from the programming language itself
and is not CPU based

only assembly actually do a such thing, assembly dont work like a high language 

IRQL,SIT/CLI and lock 

2 locks then 2 command then locks dont make a "atomic move" either
again i dont think that is the problem

the REP command without lock it still would be done with 1 command executed - this goes as fast the cpu can handle this 
whatever exactly cycles that caused on the CPU itself

i think if there is a problem the problem is not with the emulation, the problem is elsewhere, without make a big code to try around and looking the WRK
dietmar could look that 5 functions in the win2k kernel too, maybe that helps or maybe not if the structure reaction/s changed up
if somebody has a proof or the right knowlegue - let me know

actually maybe the cmpxchange8b command where not entire used, only a part of its doing/reaction 
some changes actually also can be skipped - some are bad like bsod - while others continue without full functionality - while others work correct
- and while others work but not that well - while others made some code but that code just didnt change anything and function too

very certain what controls SLIST_HEADER, PKSPIN_LOCK would be a next step to look if the functions did the right things

but also a next fault could be a problem, it would not be uncommon if 1 problem is solved, that just a next problem apears - what actually then has nothing to do anymore with the first problem (just in case i wanted to say that - for now hopefully not the problem)

lets just say very likely those 2 structures (if correctly changed with the emulation) will be processed with some next code (why a atomic move would be needed?)

https://www.nirsoft.net/kernel_struct/vista/SLIST_HEADER.html

[roytam1]

13 hours ago, Dietmar said:

But I have another BIG problem in NTDLL.DLL.

2000 RTM's ntdll.dll has same thing, maybe there is another way in 2000 to not using them?

EDIT: yes, it checks processor features in shared data first, it processor has no CX8 support, kernel will just skip this part.

Edited April 5 by roytam1

[Dietmar]

I notice, that with CLi and Sti I get the same error message of violating memory with my Emulator as with the original relocated code. The instruction at 7C98BAAC tried to write to an invalid address, 00007C98.

7C98BAAC is the entry point of my relocated function.

But this here is for the original, but relocated code with cmpxchg8b, for RtlInterlockedPopEntrySList.

The problem seems to be, that in ntdll.dll you cant choose any free place. But I have no idea, if another free place in ntdll.dll would work.

THE EMULATOR SEEMS TO WORK!

Relocations works in ntdll.dll for the function RtlInterlockedFlushSList with Emulator

Relocation works not in ntdll.dll, even not with original code! RtlInterlockedPopEntrySList

*** An Access Violation occurred in winlogon.exe:

The instruction at 7C98BAAC tried to write to an invalid address, 00007C98

Access violation - code c0000005 (!!! second chance !!!)
win32k!_GetDCEx+0x2a:
bf803ea8 8b4004          mov     eax,dword ptr [eax+4]
kd> g
Access violation - code c0000005 (!!! second chance !!!)
win32k!_GetDCEx+0x2a:
bf803ea8 8b4004          mov     eax,dword ptr [eax+4]
kd> !analyze
Connected to Windows XP 2600 x86 compatible target at (Fri Apr  5 16:04:39.000 2024 (UTC + 2:00)), ptr64 FALSE
Loading Kernel Symbols
...............................................................
.................
Loading User Symbols
........................
Loading unloaded module list
......
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 0, {0, 0, 0, 0}

Probably caused by : win32k.sys ( win32k!_GetDCEx+2a )

Followup: MachineOwner
---------

kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------


PROCESS_NAME:  drwtsn32.exe

FAULTING_IP: 
win32k!_GetDCEx+2a
bf803ea8 8b4004          mov     eax,dword ptr [eax+4]

ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung "0x%08lx" verweist auf Speicher bei "0x%08lx". Die Daten wurden wegen eines E/A-Fehlers in "0x%081x" nicht in den Arbeitsspeicher  bertragen.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung "0x%08lx" verweist auf Speicher bei "0x%08lx". Die Daten wurden wegen eines E/A-Fehlers in "0x%081x" nicht in den Arbeitsspeicher  bertragen.

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  00000004

READ_ADDRESS:  00000004 

FOLLOWUP_IP: 
win32k!_GetDCEx+2a
bf803ea8 8b4004          mov     eax,dword ptr [eax+4]

BUGCHECK_STR:  ACCESS_VIOLATION

DEFAULT_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) x86fre

LAST_CONTROL_TRANSFER:  from bf8037b5 to bf803ea8

STACK_TEXT:  
f7555d34 bf8037b5 00000000 00000000 00010001 win32k!_GetDCEx+0x2a
f7555d48 bf8037e5 00000000 0007f9a4 f7555d64 win32k!_GetWindowDC+0x14
f7555d58 804de7ec 00000000 0007f9b8 7c91e4f4 win32k!NtUserGetWindowDC+0x27
f7555d58 7c91e4f4 00000000 0007f9b8 7c91e4f4 nt!KiFastCallEntry+0xf8
0007f994 7e36902d 5b10c013 00000000 5b0f0000 ntdll!KiFastSystemCallRet
0007f9b8 5b10bdab 00000000 0007f9d0 5b10bd74 USER32!NtUserGetWindowDC+0xc
0007f9c4 5b10bd74 5b0f0000 0007f9f0 5b0f166e UxTheme!ProcessStartUp+0x2d
0007f9d0 5b0f166e 5b0f0000 00000001 0007fd30 UxTheme!DllMain+0x30
0007f9f0 7c91118a 5b0f0000 00000001 0007fd30 UxTheme!_DllMainCRTStartup+0x52
0007fa10 7c92c4da 5b0f1626 5b0f0000 00000001 ntdll!LdrpCallInitRoutine+0x14
0007fb18 7c931194 0007fd30 7ffdd000 7ffde000 ntdll!LdrpRunInitializeRoutines+0x344
0007fc94 7c93108f 0007fd30 7c910000 0007fce0 ntdll!LdrpInitializeProcess+0x1131
0007fd1c 7c91e437 0007fd30 7c910000 00000000 ntdll!_LdrpInitialize+0x183
00000000 00000000 00000000 00000000 00000000 ntdll!KiUserApcDispatcher+0x7


STACK_COMMAND:  kb

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  win32k!_GetDCEx+2a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: win32k

IMAGE_NAME:  win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  48025f2a

IMAGE_VERSION:  5.1.2600.5512

FAILURE_BUCKET_ID:  ACCESS_VIOLATION_win32k!_GetDCEx+2a

BUCKET_ID:  ACCESS_VIOLATION_win32k!_GetDCEx+2a

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:access_violation_win32k!_getdcex+2a

FAILURE_ID_HASH:  {ab1bddfb-8c7a-d233-cca1-748f5fec6a1d}

Followup: MachineOwner
---------

 

Edited April 5 by Dietmar

[Dietmar]

1 hour ago, roytam1 said:

2000 RTM's ntdll.dll has same thing, maybe there is another way in 2000 to not using them?

EDIT: yes, it checks processor features in shared data first, it processor has no CX8 support, kernel will just skip this part.

@roytam1

Does it jump to those functions and return at once or how is this skip done,

thanks a lot

Dietmar

Edited April 5 by Dietmar

[roytam1]

35 minutes ago, Dietmar said:

@roytam1

Does it jump to those functions and return at once or how is this skip done,

thanks a lot

Dietmar

it is guarded by a condition variable:

.text:77F89846 sub_77F89846    proc near               ; CODE XREF: RtlFreeHeap+A6p
.text:77F89846
.text:77F89846 ms_exc          = CPPEH_RECORD ptr -18h
.text:77F89846 arg_0           = dword ptr  8
.text:77F89846 arg_4           = dword ptr  0Ch
.text:77F89846
.text:77F89846 ; FUNCTION CHUNK AT .text:77F903D1 SIZE 0000000A BYTES
.text:77F89846 ; FUNCTION CHUNK AT .text:77FB5794 SIZE 00000016 BYTES
.text:77F89846
.text:77F89846                 push    ebp
.text:77F89847                 mov     ebp, esp
.text:77F89849                 push    0FFFFFFFFh
.text:77F8984B                 push    offset stru_77F898D0
.text:77F89850                 push    offset sub_77FB80DB
.text:77F89855                 mov     eax, large fs:0
.text:77F8985B                 push    eax
.text:77F8985C                 mov     large fs:0, esp
.text:77F89863                 push    ecx
.text:77F89864                 push    ecx
.text:77F89865                 push    ebx
.text:77F89866                 push    esi
.text:77F89867                 push    edi
.text:77F89868                 mov     [ebp+ms_exc.old_esp], esp
.text:77F8986B                 mov     ecx, [ebp+arg_0]
.text:77F8986E                 inc     dword ptr [ecx+14h]
.text:77F89871                 cmp     byte ptr ds:7FFE0276h, 0 ;<-- here checks shared user data of CX8 flag
.text:77F89878                 jz      loc_77F903D1 ;<-- jumps out if CX8 flag is unset
.text:77F8987E                 mov     ax, [ecx+4]
.text:77F89882                 cmp     ax, [ecx+8]
.text:77F89886                 jnb     loc_77F903D1 ;<-- another jump-out check
.text:77F8988C                 and     [ebp+ms_exc.registration.TryLevel], 0 ;<-- SEH __try{}
.text:77F89890                 mov     edx, [ebp+arg_4]
.text:77F89893                 call    sub_77F898AF ;<-- calls cmpxchg8b function below
.text:77F89898                 or      [ebp+ms_exc.registration.TryLevel], 0FFFFFFFFh ;<-- SEH __except
.text:77F8989C                 mov     al, 1
.text:77F8989E
.text:77F8989E loc_77F8989E:                           ; CODE XREF: sub_77F89846+6B90j
.text:77F8989E                 mov     ecx, [ebp+ms_exc.registration.Next]
.text:77F898A1                 mov     large fs:0, ecx
.text:77F898A8                 pop     edi
.text:77F898A9                 pop     esi
.text:77F898AA                 pop     ebx
.text:77F898AB                 leave
.text:77F898AC                 retn    8
.text:77F898AC sub_77F89846    endp
.text:77F898AC
.text:77F898AF
.text:77F898AF ; =============== S U B R O U T I N E =======================================
.text:77F898AF
.text:77F898AF ;v-- cmpxchg8b function belows
.text:77F898AF sub_77F898AF    proc near               ; CODE XREF: sub_77F89846+4Dp
.text:77F898AF                 push    ebx
.text:77F898B0                 push    ebp
.text:77F898B1                 mov     ebp, ecx
.text:77F898B3                 mov     ebx, edx
.text:77F898B5                 mov     edx, [ebp+4]
.text:77F898B8                 mov     eax, [ebp+0]
.text:77F898BB
.text:77F898BB loc_77F898BB:                           ; CODE XREF: sub_77F898AF+1Bj
.text:77F898BB                 mov     [ebx], eax
.text:77F898BD                 mov     ecx, edx
.text:77F898BF                 add     ecx, 10001h
.text:77F898C5                 lock cmpxchg8b qword ptr [ebp+0]
.text:77F898CA                 jnz     short loc_77F898BB
.text:77F898CC                 pop     ebp
.text:77F898CD                 pop     ebx
.text:77F898CE                 retn
.text:77F898CE sub_77F898AF    endp

 

[Dietmar]

I do not find a place in ntdll.dll, where I can relocate this (original) function.

I check all, the relocation is done correct.

Always I get this Bsod from above after relocation, even it is the identic function, just on other place.

With all the other functions, relocation was no problem.

Even no problem after relocation of RtlInterlockedFlushSList  in ntdll.dll itself.

But RtlInterlockedPopEntrySList is crazy. Bsod stays the same, when I replace to the original ntoskrnl.exe.

Dietmar

This is the original function before relocation. At this original place, it works.

.text:7C912A8C
.text:7C912A8C ; =============== S U B R O U T I N E =======================================
.text:7C912A8C
.text:7C912A8C
.text:7C912A8C sub_7C912A8C    proc near               ; CODE XREF: sub_7C9201D1+18p
.text:7C912A8C                                         ; RtlInterlockedPopEntrySList+17p ...
.text:7C912A8C                 push    ebx
.text:7C912A8D                 push    ebp
.text:7C912A8E                 mov     ebp, ecx
.text:7C912A90                 mov     edx, [ebp+4]
.text:7C912A93                 mov     eax, [ebp+0]
.text:7C912A96
.text:7C912A96 loc_7C912A96:                           ; CODE XREF: sub_7C912A8C+18j
.text:7C912A96                 or      eax, eax
.text:7C912A98                 jz      short loc_7C912AA6
.text:7C912A9A                 lea     ecx, [edx-1]
.text:7C912A9D                 mov     ebx, [eax]
.text:7C912A9F                 lock cmpxchg8b qword ptr [ebp+0]
.text:7C912AA4                 jnz     short loc_7C912A96
.text:7C912AA6
.text:7C912AA6 loc_7C912AA6:                           ; CODE XREF: sub_7C912A8C+Cj
.text:7C912AA6                 pop     ebp
.text:7C912AA7                 pop     ebx
.text:7C912AA8                 retn
.text:7C912AA8 sub_7C912A8C    endp
.text:7C912AA8
.text:7C912AA8 ; ---------------------------------------------------------------------------

 

Edited April 5 by Dietmar

[pappyN4]

Hmm EN vs DE ntdll.dll has different location.  For both I get sp-analysis failed in IDA at ExInterlockedPopEntrySList 7C912A8C DE or 7C902A8C EN

Is .DATA safe space to add? I thought it needs to be added to .TEXT

https://msfn.org/board/topic/183489-windows-xp2003-x32-on-modern-hardware-faq/?do=findComment&comment=1217623

[Dietmar]

@pappyN4

With all the other functions it was no problem to use .DATA space. Only not for this crazy function.

The problem is, that there is no free place in .TEXT or I just do not find

Dietmar

[pappyN4]

No, I do not see either.  Biggest free space in .TEXT is too small.

Since you tried relocation with identical function just in new place and still BSOD, then I do not know.  My only experience was when I got weird BSOD when i relocated patch to wrong location in DLL.

If reallocated only part of function, maybe try entire function?  I do not think this will make difference.

But first maybe try increase .TEXT size with a PE editor and put into .TEXT and see if that helps

 

[Dietmar]

8 hours ago, pappyN4 said:

@pappyN4

 

But first maybe try increase .TEXT size with a PE editor and put into .TEXT and see if that helps

 

How can I increase .TEXT size for a PE file

Dietmar

[Dietmar]

I put the function all by hand to another place in .DATA section.

Now I get this, @Mov AX, 0xDEAD can you help

Dietmar

 *** An Access Violation occurred in winlogon.exe:

The instruction at 7C98CAA8 tried to write to a NULL pointer

 *** enter .exr 0006F428 for the exception record
 ***  enter .cxr 0006F444 for the context
 *** then kb to get the faulting stack

Break instruction exception - code 80000003 (first chance)
NTDLL!DbgBreakPoint:
001b:7c91120e cc              int     3
kd> .exr 0006F428
ExceptionAddress: 7c98caa8 (NTDLL!RtlpUnloadEventTrace+0x000000a8)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000001
   Parameter[1]: 00000000
Attempt to write to address 00000000
kd> .cxr 0006F444
eax=00000000 ebx=00000000 ecx=7c98c950 edx=00010000 esi=00000000 edi=00000000
eip=7c98caa8 esp=0006f710 ebp=0006f73c iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
NTDLL!RtlpUnloadEventTrace+0xa8:
001b:7c98caa8 0000            add     byte ptr [eax],al     ds:0023:00000000=??
kd> kb
  *** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr  Args to Child              
0006f73c 7c943c6c 7c98c950 7c98c9a0 00000000 NTDLL!RtlpUnloadEventTrace+0xa8
0006f754 7c93d5cf 7c98c9a0 7c98c980 00000000 NTDLL!RtlpGetWaitEvent+0x12
0006f764 7c93d5a5 0009eda8 0009ed80 0006f79c NTDLL!RtlpStartWaitThread+0x18
0006f774 7c943308 0006f790 0009a7e0 0009ece8 NTDLL!RtlpFindWaitThread+0x2f
0006f79c 01029aec 0009ecf0 00000190 010298a1 NTDLL!RtlRegisterWait+0x16f
WARNING: Frame IP not in any known module. Following frames may be wrong.
0006f81c 01029d91 00000001 01010d74 00000000 0x1029aec
0006fd14 7c92b00a 7c91d04c 7c91e43f 00000000 0x1029d91
0006ff50 0103e75e 01000000 00000000 00072364 NTDLL!_LdrpInitialize+0x246
0006fff4 00000000 7ffd5000 000000c8 000001f6 0x103e75e

 

[Dietmar]

Here is the relocated  original(!)  function from ntdll.dll

.data:7C98CA8C
.data:7C98CA8C ; =============== S U B R O U T I N E =======================================
.data:7C98CA8C
.data:7C98CA8C
.data:7C98CA8C sub_7C98CA8C    proc near               ; CODE XREF: sub_7C9201D1+18p
.data:7C98CA8C                                         ; RtlInterlockedPopEntrySList+17p ...
.data:7C98CA8C                 push    ebx
.data:7C98CA8D                 push    ebp
.data:7C98CA8E                 mov     ebp, ecx
.data:7C98CA90                 mov     edx, [ebp+4]
.data:7C98CA93                 mov     eax, [ebp+0]
.data:7C98CA96
.data:7C98CA96 loc_7C98CA96:                           ; CODE XREF: sub_7C98CA8C+18j
.data:7C98CA96                 or      eax, eax
.data:7C98CA98                 jz      short loc_7C98CAA6
.data:7C98CA9A                 lea     ecx, [edx-1]
.data:7C98CA9D                 mov     ebx, [eax]
.data:7C98CA9F                 lock cmpxchg8b qword ptr [ebp+0]
.data:7C98CAA4                 jnz     short loc_7C98CA96
.data:7C98CAA6
.data:7C98CAA6 loc_7C98CAA6:                           ; CODE XREF: sub_7C98CA8C+Cj
.data:7C98CAA6                 pop     ebp
.data:7C98CAA7                 pop     ebx
.data:7C98CAA8                 nop
.data:7C98CAA9                 nop
.data:7C98CAAA                 nop
.data:7C98CAAB                 nop
.data:7C98CAAC                 nop
.data:7C98CAAD                 nop
.data:7C98CAAE                 nop
.data:7C98CAAF                 retn
.data:7C98CAAF sub_7C98CA8C    endp
.data:7C98CAAF
.data:7C98CAAF ; ---------------------------------------------------------------------------