Jump to content

win32

Member
  • Posts

    1,262
  • Joined

  • Last visited

  • Days Won

    79
  • Donations

    0.00 USD 
  • Country

    Canada

Everything posted by win32

  1. This, as well as all newer releases support the Intel 7 series. I'd like to post a direct link but BWC's sites are not hotlink friendly.
  2. So it appears that all of the files that are modified to accommodate SHA-2 support are not part of the extended kernel, except for winload.exe (which is just a minor patch to allow for the patched ntoskrnl to work). So the extended kernel should not interfere with SHA-2. I believe that some extended kernel users are installing new SHA-2 signed updates.
  3. Wouldn't the OS-level SHA-2 support be sufficient? And which Rust are you talking about? The programming language upon which newer Firefoxes are built, or the game? I'm trying. I'd really love to have Vista running stable on my Kaby Lake laptop as well. 2012R2 looks like Windows 1, and having Vista's UI would be a major improvement (I'm also going to work on getting graphics drivers like my Intel HD 620 ones working too). I had previously narrowed it down to the function LoadLibraryExW, and I recently installed Windows 7 build 6519 which has a very similar version of the function, and also doesn't have those bugs. But simply transplanting the function failed, as it resulted in a BSOD where "the system couldn't find the file specified (@98w9asoise590dj.dll [or similar nonsense file name])". But after trying a few more things, I think I've narrowed down the problems to one particular part of the function. But making a good patch will be very challenging. What also doesn't help is that this laptop has broken hinges, so I can't bring it to where I am half of the time.
  4. If it works with XP x64 (which it does), then it should work with Windows 2000. But you must make sure that the AHCI drivers are present on that machine as well.
  5. Intel Rapid Storage Manager 8.9, the one @jaclaz linked, does need extended core, but version 7.6 which is also on win2k.org, doesn't.
  6. So you have two problems: non-functioning AHCI drivers and a crappy ACPI-BIOS implementation. The "iastor.sys is corrupt" error can be bypassed by slipstreaming SP4 UR1 or USP 5.1 (though the latter has issues with USB 1.1 drivers and KB888111 if that is not slipstreamed at the same time). And there may be another issue coming into play with Windows 2000 USB installs and non-ACPI HALs, where it may fail to load AHCI drivers totally (I've experienced it on a Kaby Lake laptop and a Xeon X5670 machine where Windows 2000 successfully installed from USB using AHCI and the ACPI MP HAL). The second one will have to with disabling devices like serial ports, which may not be possible with your BIOS.
  7. The freezing on "Setup is starting Windows 2000" is likely not related to the installation media or to AHCI drivers. It happens with many newer BIOSes, especially InsydeH20 as well as all revisions of Apple BIOS emulation. It happens because Windows 2000 has problems detecting certain extraneous hardware like serial ports with these newer boards. Perhaps ntdetect.com can be modified to not detect serial ports/floppy drives by default on newer machines? What happens when you press F5 and select "Standard PC" when Windows 2000 setup starts loading?
  8. That's the right string, but you will have to look at the three green colours, 01 65 53, 00 92 89 and 04 DC 8E. In RGB colour values, those are 083 101 001, 137 146 000 and 142 220 004 respectively. So look for the RGB values for the shades of pink you want to use, reverse them and convert to hex. Then replace those three values in the string. You should probably copy your ntoskrnl and give it a different name like ntkrnlmp.exe. And then bcdedit /copy {current} /d "Windows Vista Custom Boot Screen" And then remember the long number/ GUID value that you get from this message: "The entry was successfully copied to {01234567-89ab-cdef-00ff-fff000ffffff}" (for example) so you can do this: bcdedit /set {01234567-89ab-cdef-00ff-fff000ffffff} kernel ntkrnlmp.exe And then there is the code signing enforcement that Vista and up introduces. I made a cracked ntoskrnl for that purpose, but you may also want to do this: bcdedit /set {01234567-89ab-cdef-00ff-fff000ffffff} nointegritychecks 1
  9. Is it me, or lots of people think that WiFi == Internet?

    1. Show previous comments  2 more
    2. xpclient

      xpclient

      Yes they think wifi=internet and have no concept of LAN 😂 I know some id*** who recharge their mobile data when their monthly broadband expires, then when it doesn't work, they charge their broadband 😂😂

    3. Mr.Scienceman2000

      Mr.Scienceman2000

      Wifi=Internet, Computer=windows and internet=Chrome to most lol

    4. XP-x64-Lover

      XP-x64-Lover

      Yes, I've noticed this myself. && vinifera I could not agree more...

  10. That's because of those user32 functions I added. But I haven't touched powerprof.dll, which apparently caused problems as well. 15.7.1 misses ntoskrnl function sprintf_s. And the 16.x series adds RtlDowncaseUnicodeChar. That may be because I put my new code and export table below the rsrc/reloc sections, which doesn't correspond to MS convention, yet seems to the easiest way to do it on x64. I'm gonna have to check out whatever reshack does to these files myself.
  11. He fixed this problem a long time ago: And I also found that WindowBlinds 3.1a is the last version to work properly on Windows 2000 extended kernel with PrintWindow enabled. While PrintWindow can be disabled, Serpent 52 uses PrintWindow and thus has problems rendering its borders with WindowBlinds 3.3+/4.x even if the main user32 has PrintWindow disabled.
  12. Maybe it was something like this: But yeah, I just noticed that spam link in that guy's quote.
  13. And now, in the U.S., most commercials for services promote them as mobile-only (we're on Google Play and the Apple Honourable Supreme Ruler Tim Cook App Store, but if you just have a PC, get lost). Even those where proper URLs are given, they are often typed in on smartphones. Sometimes laptops. Desktop computers are no longer acknowledged in North American marketing, even for computers themselves.
  14. After winload and ntoskrnl were successfully cracked, I decided to try loading custom ntdlls, with new sections added to their ends. It failed to load them. So if even a modified winload/ntoskrnl couldn't load them, perhaps some signature checking routine exists in ntdll as well? And much like in the kernelmode files, it may have been something that could only be picked up on with the debugging symbols. You can get the full debug symbol packages for Windows 2000 to 7 SP1 from here: http://web.archive.org/web/20110903004616/http://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx They took down the offline packages because of Windows 10's frequent updates making its symbols outdated rapidly. Since there has always been a desire to experiment with drivers and kernelmode code, no one has had the same drive to manipulate ntdll in such a way (exploits notwithstanding). So there isn't much information on the subject. First I see a function named LdrpCheckCorImage. It seems to be linked to .NET Framework 2.0. Not very interesting. But I do see RtlCreateUserStack which calls RtlImageNtHeader. The latter is also called by LdrpSetProtection. But most interesting of all may be RtlpCheckHeapSignature and RtlpGetColdpatchDebugSignature. And now I wonder about how other usermode files have their signatures checked in NT 6.2 and up. UPDATE: it appears that the ntdll failure was not directly related to digital signatures, but to the way the file was modified. After testing with 2012R2's explorer.exe, I found that you must use another tool to remove the digital certificate before modifying the file, or else it will be broken. Once the signature was removed with this tool, and a miniature section was added to the explorer.exe, Windows complained about the lack of a digital signature. Booting with DSE disabled allowed the modified explorer.exe to run. Now I need to replicate these results with Vista's ntdlls, but it will be six days before I can return to an appropriate testing environment.
  15. Strange. I typed the full hex string into HxD's search and got a match. And you can find that page here: http://web.archive.org/web/20030605104342/http://www.geocities.com/thejjoelc/XPbootcolors.html But I'm not sure if it would work well with x64 executables or Vista itself (for one thing, boot.ini has been deprecated). If you only need to change the colour of the progress bar, you only really need to change the appropriate hex values. As for my winload/ntoskrnl combo, it appears that all a user will have to do is bcdedit /set nointegritychecks 1, then copy over my versions outside of the OS, or set up an alternative boot menu entry with my files renamed while the OS is running. My patched files are stable, but I need to test modified ntdlls.
  16. Sure. But you will have to change the colour palette in ntoskrnl by changing some of the applicable hex values. On the page I mentioned above, you will find the ones that are green. You will have to find the RGB colour values for the two (or three?) shades of pink you want to use, and then put them where the green shades were, in hex format and reversed. So, for example, RGB colour value 32 26 21 will become 15 1A 20.
  17. Yes, but like XP, it uses a custom palette which means that it will appear as completely black in Resource Hacker (it's in ntoskrnl.exe). The palette data is stored in ntoskrnl as well. In fact, the palette is the same as XP so everything (except for maybe the progress bar parameters) in this guide applies: http://www.virtualplastic.net/html/logo_scr.html#winxp
  18. This has been a longstanding problem on Windows 2000 and Server 2003 x86, since the beginning of 2019. And the error message given when running the installer on an unsupported OS states that 2003 is a supported platform!! XP x64 was working last I checked (so sometime last year), but there have been various complaints about this issue on XP x86. I didn't know assembly back in them dark days, but I do now. So in PotPlayer x86 1.7.21280.0 (as identified by the DLL's version number), there is the following code in PotPlayerMiniXP.exe (which may be renamed to PotPlayerMini.exe in the program folder): 00401734 loc_401734: ; CODE XREF: wWinMain(x,x,x,x)+116�j .text:00401734 lea ecx, [ebp+var_5] .text:00401737 call unknown_libname_3 ; Microsoft VisualC 2-11/net runtime .text:0040173C lea edx, [ebp+var_230] .text:00401742 push edx ; wchar_t * .text:00401743 lea ecx, [ebp+var_5] .text:00401746 call sub_402450 .text:0040174B movzx eax, al .text:0040174E test eax, eax .text:00401750 jz loc_4019FF <--------------------------------------- The problem. It calls the error code .text:00401756 push 8 ; size_t .text:00401758 call ??2@YAPAXI@Z ; operator new(uint) .text:0040175D add esp, 4 .text:00401760 mov [ebp+var_24C], eax .text:00401766 cmp [ebp+var_24C], 0 .text:0040176D jz short loc_401789 .text:0040176F lea ecx, [ebp+var_230] .text:00401775 push ecx .text:00401776 mov ecx, [ebp+var_24C] .text:0040177C call sub_401A90 .text:00401781 mov [ebp+var_288], eax .text:00401787 jmp short loc_401793 .text:00401789 ; --------------------------------------- So change that jz loc_4018FF to jmp 401756h (for those with IDA). If you just have a hex editor, search for the following sequence of bytes: 0F 84 A9 02 00 00 6A 08 E8 3F 1D 00 00 83 C4 04 change it to: EB 04 A9 02 00 00 6A 08 E8 3F 1D 00 00 83 C4 04 And then, for the first time in 19 months: It will work on all other platforms. For the regular PotPlayerXP.exe, change: 0F 84 4D 02 00 00 6A 08 E8 35 1D 00 00 83 C4 04 to EB 04 4D 02 00 00 6A 08 E8 35 1D 00 00 83 C4 04 For PotPlayerMiniXP64.exe, change: 0F 84 39 03 00 00 B9 10 00 00 00 E8 4D 20 00 00 to: EB 04 39 03 00 00 B9 10 00 00 00 E8 4D 20 00 00 PotPlayerXP64.exe, change: 0F 84 33 03 00 00 B9 10 00 00 00 E8 4D 20 00 00 to: EB 04 33 03 00 00 B9 10 00 00 00 E8 4D 20 00 00
  19. I think they mean that they could patch the files on-demand at boot as opposed to modifying the files themselves. I think there are ACPI patchers for XP that do that. And winload.exe, which is explicitly mentioned as such in the tutorial, is not used on UEFI. winload.efi is used instead.
  20. I will supply the modified winload/ntoskrnl. Perhaps even make a script to make/modify the boot manager entry. The second guide is intended for BIOS/MBR.
  21. It seems like this could help achieve my newest goal: https://github.com/Mattiwatti/EfiGuard This disables PatchGuard and Driver Signing Enforcement, but only with UEFI. And apparently W7 can run with Secure Boot on with this applied (possibly Vista as well?). But, what about us Tandy 1000 users with our obsolete BIOS and MBR (oh, and don't forget Tandy graphics. Aero looks exceptionally awesome with those)? This guide to patching should suffice: http://web.archive.org/web/20170812173323/fyyre.ru/vault/bootloader.txt Well, I think I saved myself a lot of time searching through ntoskrnl in IDA and seriously advanced the cause of Windows Vista. Great thanks to those who also want to control the OS, as opposed to having the OS control you.
  22. The installer will not be able to run until I open up ntdll as mentioned above or I am successful in using offsets to a ntext.dll for the new kernel32 functions. Your only option right now is to install it on a newer OS, then copy over all files (not just in Office folder, but also in Program Files\Common Files\Microsoft (may be Microsoft Shared or Microsoft Office, not sure) as well as all reg entries created including those for services.
  23. oh, I haven't finished it yet (about ~95% done - and when I had access to the test machine I had many other things to deal with, which is why progress has been slow lately). And I'm first doing it with a base SP2 file because my test machine has serious problems with Windows Update that cause updates to fail most of the time. If it works there, then I'll adapt it to the extended kernel's kernel32. I only have a few select files. @burd has the entire patch though.
  24. Well, I think that once the version numbers exposed in ntoskrnl.exe and HKLM\Software\Microsoft\Windows NT\CurrentVersion (including the one under Wow6432Node) are changed to 6.1, it will probably do so, at the risk of breaking other stuff. For Haswell+, that is the intention of the LoadLibraryExW replacement in kernel32 (the patch for a similar Windows 7 issue dealt mostly with modifying that function, so I do believe that would be the culprit). Signtool from the Windows 7 DDK won't sign dlls in my experience, but no doubt it will sign an executable like ntoskrnl, which would allow it to boot with driver signature enforcement disabled. But again, I may as well "crack" ntoskrnl to disable signing enforcement completely (and then fix Ryzen), which would open up ntdll and make things much easier for everyone. I just need to figure out how to do that.
  25. Many things were tried today. Attempts to expand the import table to accommodate ntext.dll would require all import calls to be refactored. In almost all 1250 functions. Tried implementing BWC's version of one K32* function (which doesn't directly refer to any import calls). That tripped ntdll in part of a function (LdrLoadAlternateResourceModule) responsible for MUI support. I even tried forwarding some K32* functions to their predecessors in psapi.dll, which is what ExtendedXP/One-Core-API do. Result: same as above. The overly simplified Windows 8.1 version of the function? BEX. There is one thing left, which is to call ntext and its functions as offsets with the W7 versions of the functions. If it doesn't work, then this part of the project is on hold until I can think of another way to workaround these difficult limitations. Or I'll just hang around other OSes that aren't crippled to the casual modder like Windows 2000 or XP x64.
×
×
  • Create New...