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

[legacyfan]

ok thanks @XPerceniol I never realized those exist on edge

[mina7601]

Just now, legacyfan said:

ok thanks @XPerceniol I never realized those exist on edge

Edge is a Chromium-based browser, so, of course they exist.

[msfntor]

On 12/23/2022 at 1:23 PM, msfntor said:

I see in Process Hacker (in 360Chrome 13.5.2022r3 regular latest version browser):

In my two 360Chrome.exe and too in 360Loader.exe (is packed process here) - I've Normaliz.dll in orange in Process Hacker...

then in one another 360Chrome.exe I see libegl.dll (360 KB), libglesv2.dll (2.66 MB), and mfplat.dll (124 KB)- in orange ...

- and this same in 360Chrome 13.0.2170 r1ung.

 

In 360Chrome 13.5.1030 r 5 - from five 360Chrome.exe processes only (so 360Loader.exe NOT present), have two only with Normaliz.dll in orange. That's all.

In Process Hacker, 360Chrome.exe in job process (highlighted in brown) is in bad condition, because it's not done, so it takes resources. That's why it's profitable to finish this job. That's how I understand this.

And 360Loader.exe (from latest 13.5 version browser, AND from 13 latest too) 800 KB module is packed here...why, please?..

About packed executables read here: https://resources.infosecinstitute.com/topic/what-are-packed-executables/

Edited December 25, 2022 by msfntor
highlighted, packed...link added

[UCyborg]

On 12/23/2022 at 1:23 PM, msfntor said:

I see in Process Hacker (in 360Chrome 13.5.2022r3 regular latest version browser):

In my two 360Chrome.exe and too in 360Loader.exe (is packed process here) - I've Normaliz.dll in orange in Process Hacker...

then in one another 360Chrome.exe I see libegl.dll (360 KB), libglesv2.dll (2.66 MB), and mfplat.dll (124 KB)- in orange ...

DLLs sometimes have to be relocated anyway due to how things end up in the process address space, it would definitely be a good idea to take care of the rest of Chrome DLLs, at very least those with default 0x10000000 base address, which libegl.dll and libglesv2.dll still use.

16 hours ago, Humming Owl said:

@UCyborg Could that method result in a person not being able to execute the browser by any chance?

I don't see how that could happen except in cases where file was digitally signed and the program checks its own signature.

Edited December 24, 2022 by UCyborg

[msfntor]

In my link above about packed executables, we read:

"packed executables are a great way to save space and secure files" ... "

"Conclusion

In short, packed executables are executable files that have been compressed. While the reasons for needing to compress an executable file vary, “packing” always has a similar end result. A packed file is smaller..." 

[NotHereToPlayGames]

31 minutes ago, UCyborg said:

DLLs sometimes have to relocated anyway due to how things end up in the process address space, it would definitely be a good idea to take care of the rest of Chrome DLLs, at very least those with default 0x10000000 base address, which libegl.dll and libglesv2.dll still use.

Agreed.

I cannot investigate for a few days due to Holiday travels but my hopes is that a rebase of other .dll's will resolve first-run crashes on multi-monitor systems.

I don't recall offhand, but I don't think the libglesv2.dll is "required", nor is the "swiftshader" folder - but again, some multi-monitor systems crash without these.

[NotHereToPlayGames]

3 hours ago, msfntor said:

And 360Loader.exe (from latest 13.5 version browser, AND from 13 latest too) 800 KB module is packed here...why, please?..

I have zero plans to do anything with the loader.

I personally use it and see no issues with it, but I also have my own loader for experimentation (which I do not foresee going public with).

If we screencap'd DNS entries or network traffic being conducted by the loader, that would be one thing.

But to label it "suspicious" for NO DOCUMENTED REASON WHATSOEVER is not really worth "losing sleep over".

[msfntor]

3 minutes ago, NotHereToPlayGames said:

 

But to label it "suspicious" for NO DOCUMENTED REASON WHATSOEVER is not really worth "losing sleep over".

Of course, ArticFoxie, but you've NOT read my next post above, please?.. file is compressed so smaller, that's all. Of course...

[UCyborg]

Packed executables are smaller on disk, but have to be uncompressed at runtime.

[NotHereToPlayGames]

I have not looked into uncompressing it.  Do we know if we can uncompress it?

I personally DO use the loader because I do not want the registry entries "left behind" when I exit.

I run too many different versions here and there and want the registry free of "left behind" entries when I switch between versions.

I do run my own "loader" but it runs the "original" loader and then does certain items after the "original" loader is no longer running.

Edited December 24, 2022 by NotHereToPlayGames

[UCyborg]

It was packed with UPX, which can also unpack.

[Anbima]

34 minutes ago, NotHereToPlayGames said:

I have not looked into uncompressing it.  Do we know if we can uncompress it?

I personally DO use the loader because I do not want the registry entries "left behind" when I exit.

I run too many different versions here and there and want the registry free of "left behind" entries when I switch between versions.

I do run my own "loader" but it runs the "original" loader and then does certain items after the "original" loader is no longer running.

Humming Owl wrote a batch:

@echo off

:: =======================================
:: run "360chrome.exe" file with arguments
:: =======================================

360chrome.exe --disable-component-update

:: =======================================================
:: files and folders to be deleted after browser execution
:: =======================================================

cd ".\User Data"

:: folders

rmdir "ShaderCache" /S /Q
rmdir "Webstore Downloads" /S /Q
rmdir "temp" /S /Q
rmdir "PnaclTranslationCache" /S /Q

:: files

del *.log
del mconfig

:: Set "profile" folder

set profile=Default

:: Inside "profile" folder profile

del "%profile%\*.tmp"
del "%profile%\*.ldb"
del "%profile%\*.log"
del "%profile%\360Bookmarks"
del "%profile%\Google Profile.ico"
del "%profile%\heavy_ad_intervention_opt_out.db"
del "%profile%\*-journal"
del "%profile%\LOCK"
del "%profile%\LOG*"
del "%profile%\MANIFEST*"
del "%profile%\README"
del "%profile%\Secure Preferences"
del "%profile%\Shortcuts"
del "%profile%\Sync360_V8.sqlite3"
del "%profile%\TransportSecurity"
del "%profile%\Visited Links"
del "%profile%\Web Data"
del "%profile%\CURRENT"
del "%profile%\Network Action Predictor"
del "%profile%\Network Persistent State"
del "%profile%\QuotaManager"
del "%profile%\Top Sites"
del "%profile%\previews_opt_out.db"
del "%profile%\History Provider Cache"

rmdir "%profile%\AutofillStrikeDatabase" /S /Q
rmdir "%profile%\blob_storage" /S /Q
rmdir "%profile%\DailyBackup" /S /Q
rmdir "%profile%\data_reduction_proxy_leveldb" /S /Q
rmdir "%profile%\databases" /S /Q
rmdir "%profile%\Extension Rules" /S /Q
rmdir "%profile%\Extension State" /S /Q
rmdir "%profile%\Feature Engagement Tracker" /S /Q
rmdir "%profile%\File System" /S /Q
rmdir "%profile%\GPUCache" /S /Q
rmdir "%profile%\IndexedDB" /S /Q
rmdir "%profile%\Platform Notifications" /S /Q
rmdir "%profile%\Service Worker" /S /Q
rmdir "%profile%\shared_proto_db" /S /Q
rmdir "%profile%\Site Characteristics Database" /S /Q
rmdir "%profile%\VideoDecodeStats" /S /Q
rmdir "%profile%\Extensions\Temp" /S /Q
rmdir "%profile%\Session Storage" /S /Q
rmdir "%profile%\Download Service" /S /Q
rmdir "%profile%\Thumbnails" /S /Q

:: ======================================================
:: Registry entries to be deleted after browser execution
:: ======================================================

reg delete "HKEY_CURRENT_USER\Software\360" /f
reg delete "HKEY_CURRENT_USER\Software\360Chrome" /f

 

[NotHereToPlayGames]

From what I am seeing with limited testing only on the cheap laptop that I travel with, I'm seeing it a less strain on CPU Surge to keep the loader COMPRESSED.

I'll have to revisit when I can test on a couple of different PCs.

[NotHereToPlayGames]

Back home from travels.

Very limited testing thus far, but I cannot seem to be able to isolate any system gain or system degradation with comparing compressed loader to uncompressed loader.

Only tested on x64 tonight, will revisit on another low-end x86 within the next day or two.

Reminder that UPX (and PE) is an "in-place" decompression.  UPX (and PE) is not like .NET assembly compression where the file is decompressed and that decompressed file is used "instead of" the compressed file.

For UPX (and PE), the COMPRESSED file is being used DIRECTLY by the OS.  It isn't decompressed on-the-fly and the decompressed exists side-by-side with the compressed and the OS uses the decompressed instead.

Rather, the OS is using the COMPRESSED file DIRECTLY.

Edited December 26, 2022 by NotHereToPlayGames
typo

[NotHereToPlayGames]

Thus far, I'm kind of "mixed" on rebasing chrome.dll.

I believe that we have to look at the entire picture and not base "everything" off of reducing RAM consumption.

I've seen people jump up-and-down with ecstatic exuberation over saving a mere 3 MB of RAM - I don't understand that, at all, to be honest.

 

Make no mistake, RAM consumption is cut drastically when we "rebase" chrome.dll.

BUT it also comes at a COST.

On my Intel Core2 Quad Q6700, my first launch coming out of hibernate or full-shutdown increased from 4 to 6 seconds (already too high but inline with Mypal, NM, St, and BNav!) to over 14 seconds (simply unacceptable!).