ArcticFoxie/NotHereToPlayGames -- 360Chrome v13.5.2022 rebuild 3

[AstroSkipper]

5 hours ago, UCyborg said:

It has to support rebasing due to Windows executable design, which is not position-independent. ASLR on Vista+ is just implemented in a way that when the DLL is first used (same should apply for EXEs), it will reuse the same random address in subsequent processes. Though looking at my Win10, this doesn't always seem to be the case, choosing two processes for comparison, one native executable and one .NET executable, the .NET one had differing addresses in two instances of the process.

DLLs had to have relocation tables in any case due to possibility of conflicts, old EXEs did not have them, they're always first inside the address, but since ASLR is the thing, EXEs have the relocation table well so they can be relocated freely inside address space by the ASLR feature.

Edit:

Perhaps .NET executables/images are different, but native .NET images might behave the same as normal native images, not sure.

This is a quotation from https://www.mandiant.com/resources/blog/six-facts-about-address-space-layout-randomization-on-windows:

Quote

Windows Vista and Windows Server 2008 were the first releases to feature support for ASLR for compatible executables and libraries. One might assume that prior versions simply didn’t randomize the address space, and instead simply loaded DLLs at whatever location was convenient at the time—perhaps a predictable one, but not necessarily the same between two processes or machines. Unfortunately, these old Windows versions instead went out of their way to achieve what we’ll call “Address Space Layout Consistency”. Table 1 shows the “preferred base address” of some core DLLs of Windows XP Service Pack 3.

DLL Preferred Base Address:

ntdll.           0x7c900000

kernel32.   0x7c800000

user32.      0x7e410000

gdi32.         0x77f10000

Table 1: Windows DLLs contain a preferred base address used whenever possible if ASLR is not in place

When creating a process, pre-Vista Windows loads each of the program’s needed DLLs at its preferred base address if possible. If an attacker finds a useful ROP gadget in ntdll at 0x7c90beef, for example, the attacker can assume that it will always be available at that address until a future service pack or security patch requires the DLLs to be reorganized. This means that attacks on pre-Vista Windows can chain together ROP gadgets from common DLLs to disable DEP, the lone memory corruption defense on those releases.

Why did Windows need to support preferred base addresses? The answer lies in performance and in trade-offs made in the design of Windows DLLs versus other designs like ELF shared libraries. Windows DLLs are not position independent. Especially on 32-bit machines, if Windows DLL code needs to reference a global variable, the runtime address of that variable gets hardcoded into the machine code. If the DLL gets loaded at a different address than was expected, relocation is performed to fix up such hardcoded references. If the DLL instead gets loaded as its preferred base address, no relocation is necessary, and the DLL’s code can be directly mapped into memory from the file system.

Directly mapping the DLL file into memory is a small performance benefit since it avoids reading any of the DLL’s pages into physical memory until they are needed. A better reason for preferred base addresses is to ensure that only one copy of a DLL needs to be in memory. Without them, if three programs run that share a common DLL, but each loads that DLL at a different address, there would be three DLL copies in memory, each relocated to a different base. That would counteract a main benefit of using shared libraries in the first place. Aside from its security benefits, ASLR accomplishes the same thing—ensuring that the address spaces of loaded DLLs won’t overlap and loading only a single copy of a DLL into memory—in a more elegant way. Because ASLR does a better job of avoiding overlap between address spaces than statically-assigned preferred load addresses ever could, manually assigning preferred base addresses provides no optimization on an ASLR-capable OS, and is not needed any longer in the development lifecycle.

Important parts are marked by me in bold type. 

Edited December 30, 2022 by AstroSkipper

[AstroSkipper]

23 hours ago, AstroSkipper said:

@NotHereToPlayGames! As I reported weeks ago, I observed BSODs on my Windows XP system when starting one of the 360Chrome versions, caused by WiseVector StopX. Now, I checked the used memory addresses in my system and found out that WiseVector StopX loads the file WiseVectorHelperOne_X86.dll at the default address 0x10000000 of chrome.dll. I think that was the reason for the BSODs. Therefore, a rebasing of chrome.dll is mandatory for those Windows XP users who use WiseVector StopX.

15 hours ago, UCyborg said:

Are you sure? Mozilla based browsers, which you use as well, have a bunch of DLLs with preferred base address 0x10000000. BSODs come from something going wrong in kernel space, although whether something in user space triggered that something is another question. Kinda doubt runtime rebasing is the main culprit, perhaps it just exposes a bigger problem.

14 hours ago, AstroSkipper said:

I had only BSODs in the past when starting one of the 360Chrome browsers which had a conflict with WiseVector StopX. Only a total exclusion of all 360Chrome installations in WiseVector StopX helped to avoid further BSODs. And I never had any other BSODs before. My system is flawless, so to speak, at least there are no discernible problems. I assume that rebasing chrome.dll might avoid such conflicts. In any case, I will test this again. BTW, I never said that rebasing is a culprit of whatever. Quite the opposite! I think you have misunderstood something.

@UCyborg! I removed all exclusions made for 360Chrome v13.5 build 2022 in WiseVector StopX. Running again this browser with the rebased chrome.dll does not cause a BSOD anymore. Therefore, my assumption that rebasing chrome.dll might avoid such conflicts is presumably correct. q.e.d.

 

Edited December 30, 2022 by AstroSkipper

[NotHereToPlayGames]

@AstroSkipper - I think you kind of missed one of @UCyborg's main points.

There is literally nothing to gain in this community by jumping through your normal hoops to always prove yourself correct and everybody else incorrect.

We can all be "equals" even if we all have very different IQ's.  Masters learn from their students.

 

Here is my suggestion.

Can we post this "issue" on a WiseVector StopX forum and gain some insights from its own user-base?

Even without ASLR, a computer can run twenty different programs that all "default" to the same exact base address and all twenty of those programs will run without any BSOD's despite NONE OF THEM being able to land on their "default" base address.

There is something else amiss with your computer if you are getting BSOD's.

Posting on a WiseVector StopX forum should in the very least IMPROVE the product for future versions.

[NotHereToPlayGames]

Has anyone had any luck with the -e rebase switch?

What I would like to do is to UPX chrome.dll (it UPX's from 114 MB to 44.5 MB).

But I haven't been able to rebase a UPX'd chrome.dll - it is my assumption that it is this -e switch.

 

[AstroSkipper]

2 hours ago, NotHereToPlayGames said:

@AstroSkipper - I think you kind of missed one of @UCyborg's main points.

There is literally nothing to gain in this community by jumping through your normal hoops to always prove yourself correct and everybody else incorrect.

We can all be "equals" even if we all have very different IQ's.  Masters learn from their students.

 

Here is my suggestion.

Can we post this "issue" on a WiseVector StopX forum and gain some insights from its own user-base?

Even without ASLR, a computer can run twenty different programs that all "default" to the same exact base address and all twenty of those programs will run without any BSOD's despite NONE OF THEM being able to land on their "default" base address.

There is something else amiss with your computer if you are getting BSOD's.

Posting on a WiseVector StopX forum should in the very least IMPROVE the product for future versions.

The information I researched was actually intended for @UCyborg relating to the browser and our conversation here. So on-topic, unlike so many other posts here. You are welcome to post the problem on the WiseVector StopX forum, but it is not official and therefore not really helpful. But, as I explained in my last post, for me personally, the problem is already solved after rebasing the chrome.dll file. And BTW, the culprit of my BSOD was not my computer. Maybe, you should read my posts again. I think you missed something.

Edited December 30, 2022 by AstroSkipper

[NotHereToPlayGames]

It appears as though the best I can really do as far as "default" settings for a "public release" is to NOT rebase chrome.dll.  But add a post or two with every rebuild on how the end-user can rebase their own chrome.dll.

The problem that I am finding is that rebasing is not "universal".

I cannot use a rebased chrome.dll that "works" on my x86 and use that same rebased chrome.dll on my x64 (RAM goes from 207 MB without rebase to 388 MB with rebase, I'm better off without rebase on my x64 [or rebase to a different base address]).

I rebase to an incorrect address and it doesn't "work".

0x1d10000 seems to work for both my x86 laptop and my x86 desktop - but I do knot know if this address will work for "everybody".

 

I don't think there is going to be a "one size fits all" approach.

[XPerceniol]

45 minutes ago, NotHereToPlayGames said:

It appears as though the best I can really do as far as "default" settings for a "public release" is to NOT rebase chrome.dll.  But add a post or two with every rebuild on how the end-user can rebase their own chrome.dll.

The problem that I am finding is that rebasing is not "universal".

I cannot use a rebased chrome.dll that "works" on my x86 and use that same rebased chrome.dll on my x64 (RAM goes from 207 MB without rebase to 388 MB with rebase, I'm better off without rebase on my x64 [or rebase to a different base address]).

I rebase to an incorrect address and it doesn't "work".

0x1d10000 seems to work for both my x86 laptop and my x86 desktop - but I do knot know if this address will work for "everybody".

 

I don't think there is going to be a "one size fits all" approach.

This may be a silly question ... are you rebasing for all your XP Builds or just 13.5_2022.

In any case ... already using the rebase from @UCyborg with great results and DCBrowser.

[Dave-H]

Me too!
With the original file, my RAM usage went from 48% to 75% when 360Chrome was run, with no tabs open.
With the rebased file, it goes from 48% to 52%!

[NotHereToPlayGames]

Color me naive, but I was hoping to find the "magic number".

I was hoping to find a rebase address that works on all three of my test-case computers.

[NotHereToPlayGames]

I suppose I could run with a default that work on x86 even though it will not work on x64.

I have a strong hunch that MOST folks here on XP are all on x86.

I think me and @UCyborg are the only two on x64.

[NotHereToPlayGames]

I was originally aiming for "contiguous".  ie, force a "defragged" RAM.

Looks like this is not really the best approach.

Looks like what is working better (and more universal) is to base to an address BELOW all of the SysWOW64 and WinSxS stuff.

But to keep it ABOVE a mouse-gesture app I run on all of my machines (ironically, this mouse-gesture app resides at 0x10000000 - ie, the original default for chrome.dll).

Admittedly, it's all been trial-and-error and just keep trying new base addresses.

0x3e1c0000 seems to be working out just great.  For x86 and for x64.

[Anbima]

2 hours ago, NotHereToPlayGames said:

It appears as though the best I can really do as far as "default" settings for a "public release" is to NOT rebase chrome.dll.  But add a post or two with every rebuild on how the end-user can rebase their own chrome.dll.

You could use the normal chrome.dll standard and also a chrome.dll_rebase in the same folder.
Then everyone can test it themselves which runs better. That would be the best.

[NotHereToPlayGames]

Since 0x3e1c0000 seems to work for everything I've thrown at it (one x86 XP laptop, one x86 XP desktop, one x64 XP desktop, two Win10 x64 laptops), I'm getting ready to repackage everything, upload, and start a new thread dedicated to 13.5 build 1030.

There still could be a "better" base address, not really sure.  I literally just tacked via trial-and-error until I hit one that worked.

[msfntor]

1 hour ago, Dave-H said:

Me too!
With the original file, my RAM usage went from 48% to 75% when 360Chrome was run, with no tabs open.
With the rebased file, it goes from 48% to 52%!

I have:

RAM used after Windows boot (without browsers): 272/3071 MB (8%)

 

RAM with 360Chrome 13.5 regular: 455/3071 MB (14%) (and with my 3 extensions for now....)

455-272=183 MB for 360Chrome...

 

RAM with DCBrowser (ancient v.): 512/3071 MB (16%) (and with my all 11 extensions...)

512-272=240 MB for DCBrowser...

 

I've NOT rebased...

Edited December 30, 2022 by msfntor
NOT rebased

[NotHereToPlayGames]

"Regular" build 1030 will maintain "Translate to English" feature.

"Ungoogled" build 1030 will have "Translate to English" totally removed/disabled.

Edited December 30, 2022 by NotHereToPlayGames