Jump to content

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


Recommended Posts

15 minutes ago, NotHereToPlayGames said:

For my own compare/contrast learning curve, what was the original .dll that you rebased?

I think it was the chrome.dll from the version 360Chrome v13.5 build 2022 rebuild 3. I also downloaded @UCyborg's rebased chrome.dll to compare it to mine. The sizes (of original and rebased chrome.dll) match in any case, and it works.

Edited by AstroSkipper
Update of content
Link to comment
Share on other sites


This rebasing is VERY exciting news!  Can't thank the "team" enough!  :cheerleader:

I can't test until back home, but I'm starting to think that the rebase is why my multi-monitor setup at home crashes first launch and first launch only if I remove the Vulkan .dll's.

Would also prove interesting to compare rebased 1030 with rebased 2022.

Link to comment
Share on other sites

4 minutes ago, NotHereToPlayGames said:

This rebasing is VERY exciting news!  Can't thank the "team" enough!  :cheerleader:

I can't test until back home, but I'm starting to think that the rebase is why my multi-monitor setup at home crashes first launch and first launch only if I remove the Vulkan .dll's.

Would also prove interesting to compare rebased 1030 with rebased 2022.

I already did that. Version 1030 runs more smoothly on my old system than version 2022. Both versions are consuming very little RAM. :cheerleader:

Link to comment
Share on other sites

Hello @UCyborg! I compared your chrome.dll to my rebased one. The sizes are the same but the hashes are different. I thought libase uses the hash from the original dll file for rebasing. So why are the hashes different? Is it also dependent on the system? Or did you perform the rebasing manually with specific addresses? :dubbio:

Edited by AstroSkipper
Update of content
Link to comment
Share on other sites

18 hours ago, AstroSkipper said:

Hello @UCyborg! You are great! :thumbup I have chrome.dll rebased, and now 360Chrome 13.5.2022 consumes much less RAM than before, such as it is the case on many other systems.

17 hours ago, mixit said:

@UCyborg An excellent approach!, works as intended on my XP x64. It's pretty funny that even though I've already personally modded this DLL, it didn't even occur to me to consider such "invasive" methods at this point

17 hours ago, XPerceniol said:

Holy smoke ... !!

@UCyborg gosh .... like night and day difference

15 hours ago, IXOYE said:

UCyborg, Thanks for chrome.dll, it lowered the memory by 3 Mb, and it also solved the problem of the two orange addresses below with their disappearance.
with the new chrome.dll.:thumbup

Thanks, I'm an old cat (MEOW!) who knows some tricks...took me a while to remember though.

17 hours ago, AstroSkipper said:
17 hours ago, mixit said:

typically when people have these kinds of issues, they don't want to start modding as the first thing (breaking file signatures is "bad"! what will anti-virus say?! :ph34r: :P), so you kind of condition yourself to try and find configuration-based methods first and foremost. But since we're modding anyway, this is highly appropriate! :worship:

For those who want to use this method for other applications, it seems that libase.exe doesn't like file signatures (my 1030 chrome.dll still had it while 2022 doesn't), which you can remove for instance with delcert.exe, available from here.

Hello @mixit! You are absolutely right! I also tried to rebase the chrome.dll of 360Chrome 13.5.1030 rebuild 6 and failed. Only after removing the file signature with your recommended tool delcert, I was able to rebase this chrome.dll, too. Thanks for your tip!

Yes, most work is done by ReBaseImage function, which checks for digital signature and bails out if it exists. It's logical when you think about it, when you digitally sign the executable, you seal it for release and don't change it anymore afterwards. It's possible to write own function for rebasing if you like to crunch through the executable manually.

15 hours ago, mixit said:

Seems originate from Dr Dobb's (source code links are dead there, but it's available here).

:thumbup

2 hours ago, AstroSkipper said:
2 hours ago, NotHereToPlayGames said:

For my own compare/contrast learning curve, what was the original .dll that you rebased?

I think it was the chrome.dll from the version 360Chrome v13.5 build 2022 rebuild 3.

@NotHereToPlayGames's rebuild 3, regular build, here's the ungoogled one. I'm sure @NotHereToPlayGames will include the rebased version in next rebuild.

1 hour ago, AstroSkipper said:

Hello @UCyborg! I compared your chrome.dll to my rebased one. The sizes are the same but the hashes are different. I thought libase uses the hash from the original dll file for rebasing. So why are the hashes different? Is it also dependent on the system? :dubbio:

I would assume it should be. Hold on, have to get back home from work, lunch and so on, I'll check it later.

Edited by UCyborg
Forgotten link
Link to comment
Share on other sites

This browser is starting to go from a need to use to want to use. I think, folks, we in this next release - with the help of @UCyborg, and, @mixit - we'll see a FANTASTIC build/release and one that we should promote. If @NHTPG can fix that minor blip in the address bad when the text vanishes away and you need to re type at first launch, people will be fighting to get their hands on this new awesome piece of software! A privacy focused friendly light weight browser. Even better than ungoogled chrome; period! ::cheerleader:

Edited by XPerceniol
Link to comment
Share on other sites

@AstroSkipper
ReBaseImage updates the timestamp inside PE header, which also effects calculated checksum, also written in the header, so only these two fields will differ if everything else is identical.

So, TimeDateStamp field of IMAGE_FILE_HEADER and CheckSum field of IMAGE_OPTIONAL_HEADER (https://0xrick.github.io/win-internals/pe4/).

Hm, LiBase's default config assumes DLL that is not bigger than 1 MB :w00t: (relevant for putting multiple DLLs through the process).

Edit:

Quote

ReBaseImage updates the timestamp inside PE header

Actually, the function takes that timestamp as the parameter. LiBase just uses the result of standard time() function with NULL as the parameter, so current time. But if you pass 0 to ReBaseImage, it will increment the currently stored timestamp in the executable by one second.

Edited by UCyborg
Link to comment
Share on other sites

is there anyway we could use this with edge? it the browser I use the most (with a little tweaking) but would that be possible to keep it working on 7/8.1 using this same method as chrome360?

Edited by legacyfan
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...