Jump to content

mjd79

Member
 View Profile  See their activity

  • Posts

    199

  • Joined

  • Last visited

  • Donations

    0.00 USD 

  • Country

    Poland

 Content Type 

Everything posted by mjd79

  1. mjd79
    Despite the backported DWrite and the platform update (which is required by ext kernel), I have not been able to run anything beyond Chromium 111.0.5550 probably.
  2. mjd79
    I tried, in place of VirtualAlloc in the kernel32 import table I can't fit this function (too long name), and redirecting it in the original kernel I use for Chromium on 8.1 causes an error in ntdll, which is very strange... BTW Memory usage alone does not seem to be an issue in 8.1, with the same number of tabs with the same pages the v130 uses a similar amount of memory to Chrome 109 on Win7. The bigger problem is with virtual memory, after some time, such as an hour of using the browser suddenly starts to occupy all the virtual memory.
  3. mjd79
    I have no idea, Chrome 125 failed to run even with the 9th March 2023 extended kernel, so does your version run with or without it? Unfortunately, it is not possible to redirect ntdll locally, so if the extended kernel is required, it is impossible to avoid installing it.
  4. mjd79
    I found a “solution” based on Blaukovitch's crack. It turns out that all it takes is to change a few bytes in chrome.dll (unfortunately, completely different in each Chromium-based browser and in other versions) and the original Chrome 130 works, including the sandbox fixed by my method described above. @D.Draker, could you check this with v127 on Vista? For Chrome (not Chromium, etc) 127.0.6533.73 x64, just replace offset 621D030 in chrome.dll with: B8 10 00 00 00 C3 90 48 8B 05 02 E6 8B 06 48 31. Also need to binary change the import in chrome.dll to API-MS-WIN-CORE-REALTIME-L1-1-0.dll and remove the "precise" addition from the QueryUnbiasedInterruptTimePrecise function. It's still not a complete success as I don't fully understand what I'm changing, hence I'm not able to port it to anything other than an identical version of Chrome.
  5. mjd79
    I finally got to what's messing up the Chromium 110-126 sandbox on Windows 8.1, and it's the UpdateProcThreadAttribute feature. When I redirected it in the original kernel32.dll to the pwrp_k32.dll included in Supermium 132 R2, the sandbox started working. Just find a 100% sure solution to the RAM and virtual memory usage problems, and you will be able to use any Chromium-based browser (except Edge) up to version 126. I still don't know what is causing the problem with Chromium 127 and newer preventing the browser from running. And fixing the sandbox in version 126 is just a milestone. It is 17 versions higher than 109, but it is also 9 versions older than the latest official Google Chrome.... If anyone knows how to debug, I would greatly appreciate your help. All I know is that the problem is definitely in chrome.dll. 126 also worked on 8.0, but the sandbox after the repair still does not work, the browser starts up, but with the error SBOX_FATAL_CLOSEHANDLES, and does not display any page, of course.
  6. mjd79
    The topic is about Win 8.1, but since there is no separate one for 8.0 I am posting the information here, it also works after very similar modifications (even GetSystemTimes is not missing, although this 8.0 is RTM without any updates, and 8.1 I use updated to the end of 2017)
  7. mjd79
    I don't need it, I've already replaced them with empty files, I just posted about it informatively. https://github.com/e3kskoy7wqk/Firefox-for-windows-7 includes a working crashreporter, if anyone want a 100% complete browser (and actually with unnecessary additions).
  8. mjd79
    Affinity, that I just didn't come across it I remembered from the time of porting Chromium 110 to Win7 about the GetProcessAffinityMask function, so I used it, and now both versions 138 and 139 work. I'll test it for stability, codec and extension performance (initially YT and Ublock work) and write a proper tutorial. In general, this means that we will 99% be able to port the upcoming probably in a few months the next version of ESR. I added the 3 missing imports as redirects in the original kernel32.dll, but you can simply swap in CFF Explorer xul.dll GetSystemCpuSetInformation -> GetProcessAffinityMask GetSystemTimes -> GetSystemTime mozglue.dll api-ms-win-core-version-l1-1-1.dll -> version.dll api-ms-win-core-realtime-l1-1-1.dll and function QueryUnbiasedInterruptTimePrecise -> api-ms-win-core-realtime-l1-1-0.dll and QueryUnbiasedInterruptTime The rest of the missing .dll imports in mozglue.dll need to be replaced with kernel32.dll And of course change MajorOperatingSystemVersion and MajorSubsystemVersion from A to 6 in firefox.exe. Edit: Default-browser-agent.exe does not work (problem in ucrtbase.dll) and crashreporter.exe (user32.dll GetDpiForWindow function is missing, it can be replaced, but then the window will be the smallest possible size and any content will be seen only after the window is maximized)
  9. mjd79
    I'm very close to launch Firefox 138 beta and the latest nightly 139.0a1, I'm missing the GetSystemCpuSetInformation function. Without it, FF to 138 launches but does not load any page. From 139 it doesn't work after replacing it with others at all. It supposedly appears in the api-ms-win-core-processthreads-l1-1-3.dll file in Windows 10 10240. And indeed, I checked it, and the kernel32.dll from this compilation imports this function from that file. The problem is that I can't find that file anywhere, I only found the downlevel ones, which are the ones I already have in 8.1. I will immediately point out that version l1-1-2 does not include GetSystemCpuSetInformation, both in 8.1 and 10. https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis In fact, I've already succeeded, except that in the original kernel32 under a different name, I added redirection of the missing function to a wrapper created by a certain cracker from Github. However, I prefer to avoid this and solve it on my own, as this is the only missing dependency I have left.
  10. mjd79
    Ok, you can find information about this in the source code, but there should be mentions with the releases themselves that Supermium 132 is much less secure than 126 with a working sandbox.
  11. mjd79
    In any case, the disabled sandbox, without any information on github or in the browser itself (other than chrome://version or chrome://sandbox, which 99% of users will never look into), is simply a scandal! https://no-sandbox.io/
  12. mjd79
    Then the likelihood is that Supermium 124 and above are based on Chrome 111 or similar, and Supermium 122 and older are based on 110, 109 or even older. Edit: As I see, I am not the only one who discovered this sandbox problem and it has already been reported on github. It will be interesting to see how the author responds to this. https://github.com/win32ss/supermium/issues/1290
  13. mjd79
    I have reviewed Supermium versions 122 through 132 R1, and I believe that even if the theory about the older engine is true, it uses the same as Supermium 124, not 122. The 122 version differs too much in my opinion, if only in the imports and wrappers used (e.g. since version 124 uses APIs such as DiscardVirtualMemory) . Besides, going into chrome://versions on Supermium 122, 124, 126 R7 and 132 R1, I discovered that the latest version of Supermium probably uses the --no-sandbox flag by default under Windows 8.1, and in the version for older systems, as well as the version for Win 10 and 11, which interestingly continues to work after replacing DiscardVirtualMemory with VirtualAlloc.
  14. mjd79
    I checked and it seems to be a problem with Supermium 132 R1. Even my custom 2830.0 doesn't work, which works on all other Chromium browsers under Win7, including Supermium 126 R7. BTW I also discovered that the pwrp_k32.dll included with Supermium 126 R7 allows 2830.0 to run in any reasonably modern (not tested below v109) Chromium browser in Windows 7. Just open widevinecdm.dll in CFF Explorer and rename the import from kernel32.dll to pwrp_k32.dll
  15. mjd79
    If you are using 10/11 it should work fine. Delete this manually copied Widevine and update in chrome://components https://dl.google.com/widevine-cdm/4.10.2830.0-win-x64.zip Alternatively, try version 2830.0.
  16. mjd79
    Currently, the case is as follows: Windows 8.1 and 8.0 - Widevine is running the latest version, 4.10.2891.0, in every Chromium-based browser as well as Firefox (although 115.21.0ESR is likely to download 4.10.2830.0, which also works) Windows 7 - so far I have not been able to run Widevine newer than the aforementioned 4.10.2830.0, even in Supermium 126 after applying the included patch. I didn't respond to inquiring users earlier because the original method of running Widevine from Firefox on browsers like Chrome 109 or Opera 95 required the use of the kernel64 library, which is a wrapper of kernel32 created by a Russian cracker porting closed-source browsers to older systems. I will try to find another option which is legitimate and presentable on MSFN without breaking the rules.
  17. mjd79
    Apropos of .sig files, an interesting fact is that modified Firefox is not blocked, and also has them.
  18. mjd79
    No, @NotHereToPlayGames has captcha on every browser, hence the suspicion that this is what happens when you enter from an IP outside Poland. I live in this country, have internet from a local provider, and the captcha doesn't show up at all, the site normally works unless I use modded Chromium browsers.
  19. mjd79
    Perhaps this is the case with IPs from outside Poland. In any case, on any unmodified browser you don't have to pass the captcha, and even if you do, it succeeds.
  20. mjd79
    Of course, I perform the tests on a completely fresh profile, without changing any flags or settings and without extensions.
  21. mjd79
    The 100% correct solution to the test always ends up blocked, only on modded Chrome. On unmodified versions or on Firefox at the same time the site runs without any verification, so the browser is blocked, not the IP or MAC address.
  22. mjd79
    It doesn't work in both cases...
  23. mjd79
    As for my Chrome 122 (122.0.6261.112), I tested two scenarios. One was changing the kernel32 import DiscardVirtualMemory to VirtualAlloc in chrome.dll and DWrite.dll to one from Windows 10 1511, the browser was then launched with --no-sandbox. The other is to use a custom kernel32 for chrome.dll, to which I can only provide a link on PM, because the author is generally a cracker, it fixes the sandbox, and a custom modified original kernel32.dll using all the virtual memory functions from the wrapper included in Supermium 132 R0 (which fixed the leaks of that memory) for chrome.dll. DWrite also with W10 1511. In my case, the problem is with allegro.pl.
  24. mjd79
    I have a similar problem with ported Chrome 122 on Windows 8.1 with allegro.pl website. I get blocked by by their counterpart of captcha every time. Flags etc don't help. Could you please check what will happen for you? Thanks.
  25. mjd79
    This appears to be a problem with Ublock Origin MV2. I was able to reproduce this problem on Opera versions 95 and 117 with Ublock 1.62, but it works with Adguard MV2 4.4.22.. In any case, it works fine in Firefox with Ublock 1.62, oddly enough.
×
×
  • Create New...