pappyN4

You've been busy I tried couple of different setting changes with CFFexplorer to see if it lets duser work with patch at end of file if you'd like to test https://ufile.io/iom6e25x

@DietmarOk. I thought try to leave original function call intact, but I guess still not good. Interesting that adding TEXT fail for some, but work for other...

Ok, here is EN duser.dll, with 5 patch and checksum. Hopefully no mistakes. Interesting learning https://ufile.io/96dvpojw

@DietmarI will try a EN duser.dll But I will do a little differently and maybe you can test later if it still does the password problem you had.

@Dietmar Looking over. In ntoskrnl, KeInterlockedSwapPte emulation not needed? I see its all zero out. For ExpInterlockedPopEntrySList. You have F0, should be EF?

Weird. In duser.dll EN for cmpxchg8b I see ExInterlockedFlushSList, ExpInterlockedPopEntrySListEnd, InterlockedPushEntrySList, InterlockedPushListSList, RTLInterlockedCompareExchange64 If you replace duser.dll on computer that is not 486 computer, same password issue?

Ah, I see what you did now. You patched other functions in ntdll that call 5 old functions to codecave location. I think cleaner would be just patch only the 5 old function + codecave and leaving all other functions as original. @DietmarConsider. I have program/driver/etc... Driver imports ntdll or ntoskrnl. Driver then tries to use one of old function from file, since old function all NOP, driver now error/BSOD. Maybe all old functions Private and not used by anything else and no problem. But what if not?

@Dietmar Did you not make patch in .TEXT? I do not have file open, but from other two, do search for "align 80h" . Other two had a little spot between TEXT and DATA. Just enough for one patch i would think. Or maybe just patch all files with same style and add 512byte TEXT at end of all?

Fresh XP, on regular (not486) computer, with only duser.dll modifed and see if works as normal?

@Dietmar Hmm, original function location all NOPs. So how does it know where to go when the original function called be OS? I would assume in old location you would need jump to new like so [adjust 90 35 as needed] So that, OS calls function like ExInterlockedFlushSList, then in there it jumps to code cave with your updated code Edit: I would also use C3 to 'retn' from codecave new function, and leave the original 'retn *' from the old function so that it will return whatever value is expected from the original function after success. Most are just C3, but some are different.

Is ntoskrnl also done with 512 byte code cave or still on to do list? Sleep should also be on todo list

no 'retn' C3 ? Edit: Nevermind, I see C2 08 00 is 'retn'

If more change is needed for original function to work properly and simple replacement of cmpxchg8b with cmpxchg_486 is not enough. Then I guess you are stuck moving entire function and NOP old location. A lot more byte change compared to simple replacement. I do not follow assembly code logic for cmpxchg_486, so trust up to you if simple change is good, or if need to change more and need total replacement to work properly. I do not trust any code in .DATA. From quick research, executable code is supposed to be in TEXT

ExInterlockedPopEntrySList does not load properly for me in IDA, I cant see graphic view, so this comment is using your ExInterlockedFlushSList as example: goal is to replace 0F C7 4D 00 "cmpxchg8b qword ptr [ebp+0]" with your "cmpxcng_486 ptr [ebp+0]" assuming that 4 bytes not enough space for jump, so needs to steal space from previous code "mov cx,bx" 66 8B CB so existing code replaced to jump new location, and NOP for rest. 66 8B CB 0F C7 4D 00 -> E8 xx xx xx xx 90 90 then in new location add the stolen code, then whatever your code is for cmpxcng_486 then return. 66 8B CB xx xx xx xx xx xx xx xx C3 Or working example for a different DLL if makes more clear https://postlmg.cc/Lq8XdxSf

@DietmarI do not know. I think it would change position of all code below, make things messy maybe if file expects things to be in specific location. I think simplest would be to replace cmpxchg8b with jump to new code cave then jump back. https://ufile.io/hubab5t2

@DietmarI think i found instructions on how to add code cave at end of file using CFF explorer. If correct, should have nice clean 512 bytes of .TEXT to add patches. File becomes a little bit bigger than original. https://ufile.io/d8v54m36

Take look at 7A3B8. I think there should be enough space to test one relocate function. Try unmodified relocate and see if BSOD. If good, then try modifed and check.

Interesting... and yet scary that it misleads you into thinking it will work.

I'm assuming when you formatted it with XP it was an incorrect 1.6TB size? I was never able to get XP to format to it's correct 4TB, so it always ended up being corrupted one way or another.

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

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 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..

Years ago, I had XP64sp1 on a old computer in IDE mode. I added a 4TB drive that i formatted with parted gparted. It showed as 4TB in XP64 disk managment, but as I copied over past the 2TB mark, files started getting corrupted. Trying to format the drive in Disk Management only showed as 1.something TB. XP64 should have been able to handle large GPT data drives, but I guess maybe it needed to have a newer service pack version or AHCI to do it properly. I didn't bother to investigate. Recently I tested 4TB on XP64 updated to 2019, and it was able to format it and show the correct size. Did the overwrite testing and worked fine with the win7 amd sata and the win8 ahci drivers backported. Same test with server 2003x86 R2. I didn't test overwrite, but it was able to format and see correct size just like XP64 (aka server2003x64) so I assumed it was fine. With XP32 updated to 2019, using the disk.sys and partmgr.sys from 2003, along with same win7 amd sata and win8 ahci drivers. When trying to format it with Disk Management it would do the same 1.something TB size, so not able to handle 2TB+ drives. When I plugged in the 4TB drive formatted with gparted, either internally or with a USB3 capable external enclosure, it did not show up as a readable disk in Disk Managment. I didn't test, but I would think it would be safe from corruption since it wasn't seen. But would need to confirm with hash of files before trusting it. When I tried a very old enclosure, it did show up as 4TB, but that is misleading and I knew it would start corrupting since the USB-SATA chipset itself was limited to 2TB. Over at mdl I made a small post with other files I tried to copy over from 2003 to see if I could get past the 2TB limit, but I guess it's probably more involved than just simply copying over two files needed to get GPT <2TB to work on XP. I also tried paragonGPT, but didnt work for me. From comments on the paragon patch posts over on hardwarefetish it seems that it's meant to work with IDE and not with AHCI drivers.

Are you guys formatting the 2TB+ drive in XP? or somewhere else and then using it in XP? The only way I would begin to trust the drive is if you can format it in XP's Disk Management and it shows as the correct size. Then copy one large file over, hash check, then copy 2TB+ and see if it first file gets corrupted. If Disk Managment can't format the proper size, then I would assume it will not work correctly even if you are able to see "correct" size when formatted with something else.

I dont know if it matters, but in this version there is one left in RtlInterlockedCompareExchange64() , position b158