Piratim Google Chrome for Microsoft Windows 7

Aboard!

So, based on publicly available information, we know that Google officially announced version of your Chrome browser 109 (109.0.5414.75) the latest for the operating system Windows 7 (8, 8, 8.1, 2012, 2019).

Knowing full well that this decision was dictated to the greatest extent by selfish motives (and not by real technical necessity), I downloaded the current (at that time) version of the browser 114.0.5735.134 x64, installed on a virtual machine running Windows 10.

The task is simple and at the same time difficult: to get this product running under Microsoft to start Windows 7 SP1… preferably in one evening.

Reconnaissance in force

We move to the Chrome installation folder on a virtual machine with Windows 10:

C:\Program Files\Google\Chrome\Application

and copy it without changes to a virtual machine running Windows 7 to any free place (even in a folder C:\Windowsbut not necessarily).

First of all, we are interested in the executable PE COFF file format. I mean files with extensions .exe And .dll. Three PE files fall under suspicion:

• chrome.exe – the main executable PE file located in the root installation directory;

• 114.0.5735.134\chrome_elf.dll – it is referenced by the export table in chrome.exe;

• chrome.dll – judging by the impressive size in 210 Megabyte, it can be protected by DENUVO this is the main engine of the browser. As it turned out a little later – which is loaded using the usual call WinAPI LoadLibrary. in the same folder as chrome.dll there was a library d3dcompiler_47.dll, which hinted a bit that the browser engine is based on DirectX rendering. But this is so by the way what I had to remember at the very end of the work – as an answer to the question “why does this balalaika still not start ??”;

Step 1 WinAPI calls

The most dangerous mission of this operation. Is it doable? Despite the difference between the numbers 7 And 10which is equal to just three – the number of missing WinAPIs is clearly an order of magnitude greater! However, if you think about it purely technically, most of the innovations will be related either to security or energy consumption or to unique features that are needed only for Windows 10/11 and did not rattle for the “seven” in principle.

To visually assess the scale of the missing WinAPI for Microsoft Windows 7, the easiest way is to use the free utility Dependency Walker.

Missing WinAPIs in system PE dlls are marked with a red card on the right. Such dlls are also highlighted in red in the utility itself on the left. We visually note that, in addition to individual WinAPIs, entire system libraries of the type API-MS-WIN-POWER-BASE-L1-1-0.DLL (indicated in yellow with an exclamation point). Making sure that API-MS-WIN-POWER-BASE-L1-1-0.DLL is really absent from the beginning in the configuration of the “seven”, we come to a disappointing, at first glance, conclusion: in addition to individual implementations of procedures, you will have to write whole PE dlls for the entire Microsoft company. Those. The mission is divided into two maps:

• implementation of individual WinAPIs in existing system PE dlls;

• implementation of entire system libraries that are simply not originally provided for Windows 7;

Well, okay with chrome.exe or with chrome_elf.dll, which occupy a small size and do not play a major role. The most significant, in every sense, contribution is made by chrome.dll (I understand that its size is over 200 Megabyte, which is naturally a lot for the PE COFF format as a whole).

As a result, we got the following layout for WinAPI:

And the missing system dlls:

The first three dlls “flew off” in Visual Studio right away – due to the lack of AppX (MS Store) in Windows 7, there was simply no need to write any intelligible C / C ++ code. WITH power And shcore I had to add functionality in a few minutes to native code in NTDLL and display scaling (DPI), respectively.

But with WinAPI I had to tinker a little more. Firstly, we are clearly left without a new sandbox (parameter –no-sandbox), because mitigations (GetProcessMitigationPolicy/SetProcessMitigationPolicy) in 7ke (at least Windows 8 is required) there really is no other than DEP and ASLRP policy. With this, you will have to repair chromium workers in mojom.

Secondly, everything else, for the most part, is repaired by a banal NOP without any loss in browser functionality.

Thirdly, for some reason, after all this, Chrome 114 launched on Windows 7 and immediately the browser crashed. In the debugger, it is observed that the “New Tab” window is somehow created, but this is at most the usual upper part of the Windows window, well, perhaps with the added address bar. In the sense of rendering the body of the page, it simply does not happen – at best, the user will type requests in the address bar, which are displayed somewhere in /dev/null:

It would seem … everything is bad? No, of course! Not just wrote for d3dcompiler_47.dll – definitely and obviously, what exactly will have to be corrected in the handling of Chrome with Microsoft DirectX. Omitting a large number of technological implementations, the developed technique for debugging errors in the browser and other technical details, I provide the public with ready-made Chrome 114 under Windows 7 (which must be run with the key -no-sadnbox):

Step 2. Edit Major/Minor OS number

In fact, this is always the first thing done to unlock the ability to run PE COFF on earlier versions of Microsoft Windows. Namely, they lower the value version number V PE Header.Optional Header, otherwise the Windows bootloader simply won’t run the PE file. But I remembered for this already after the successful launch of Chrome 114 on Windows 7, i.e. corny version editing was not required.

Purely logically, the linker in Google should have initially entered the values 0xA And 0x0respectively (Windows 10 is the minimum axis to run Chrome, as it were, according to the official statement).

Instead, open a wonderful utility PeTools and see … what is there at all Windows Server 2003. Having drawn the appropriate conclusions, I simply closed PeTools.

WebGPU for Windows 7

Add parameters in the launch line (flag unsafe WebGPU and select DirectX 11 as render):

--enable-unsafe-webgpu --use-webgpu-adapter=d3d11

In the browser itself after launch, check:

chrome://flags/#enable-webgpu-developer-features

chrome://flags/#ignore-gpu-blocklist

Works unstable or until the first crash of a separate gpu rendering process. There are questions to the very implementation in the browser from the corporation, since all this is sawn in a teaspoon.

PS

It is quite possible that the most popular question will be “why?”. However, I see no reason to give a direct answer to it.

I will limit myself to the following statement: Microsoft Windows 7 is still used by millions of users and it is rightfully considered one of the best operating systems. And at one fine moment, one of the managers of a certain corporation G decided to literally “score” on them, sending an instruction to throw out part of the code to exclude compatibility. Thus, leaving many users without functionality and security updates. Fortunately, not all competitors do this.

And now, after a few months, “pirates” appear, which demonstrate an absolutely working version of the browser. 114.0.5735.134 (114.0.5735.199) for Windows 7 (SP1). Those. The pirates play the role of the Good Samaritans, who care more about the users than the Mystic G Corporation itself.

In addition, if tomorrow the G corporation suddenly stops supporting Windows 10, forcibly driving everyone with brooms to the next incremental number 11 – everyone will also obey (I apologize for the expression) the “herd principle” and say “Oh! Great googol, we obey and obey!?!? While the differences in WinAPI between 10 And eleven many times lessthan between 10 And 7 for the case under consideration.

And then they complain that all technological progress has slipped into a banal increment of numbers in the software version.

Thank you for your attention!