mixit
-
Posts
222 -
Joined
-
Days Won
10 -
Donations
0.00 USD
Content Type
Profiles
Forums
Events
Posts posted by mixit
-
-
Can't say anything specific as I haven't fiddled with OneCore API, but these browsers have their own integrity/signature check (not based on Authenticode). If you haven't modified the original files in any way, apparently OneCore API lacks (has stubbed?) something this integrity check needs to pass properly. Assuming the integrity check is the only problem and the browser is otherwise workable with OneCore (not guaranteed with such complex software), the check could probably be patched out like it has been with modded 360 v13 browsers.
You could try asking (via Googletrans) here or here on a Russian-language forum also frequented by the people who did the patching, or at least those who know them and can ask them about it. Maybe they've already done it for v14 as well, I don't follow these topics very closely. (I could maybe do the patching myself once I've checked out how they did it, but I don't know when I'd get to it, and I'm not as familiar with x64 as I am with x86. In any case it's much easier/faster for those who've already gone through it.)
Edit: I believe @grey_rat is also a member there, maybe he could ask about it for you. Then again, as a Serbian you may be able to do it pretty easily yourself
(I didn't notice your country at first).
Edit2: Oh, and welcome to the forum! Didn't notice this was your first post, either.
2 -
7 hours ago, mixit said:
Why Cloudflare deems features like site isolation necessary for "connection security" of their customers is anyone's guess. It's not as if the very latest Chromium couldn't be run headless or embedded or puppeteered with automated clicks, with all the feature gimmicks thus available to botters.
I guess I shouldn't have been so categorical, this actually is somewhat of a problem for automated captcha solvers.
QuoteIn addition you might want to disable site isolation, so puppeteer is able to access cross-origin iframes:
puppeteer.launch({ args: [ '--disable-features=IsolateOrigins,site-per-process,SitePerProcess', '--flag-switches-begin --disable-site-isolation-trials --flag-switches-end' ] })
1 -
2 minutes ago, Montana Slim said:
Noticed recently that the PaleMoon 28 build won't download any files from Mega (kim dotcom's site) ... you get "temporary error" and infinite retry failures.
Scroll up on this page.
2 -
Why Cloudflare deems features like site isolation necessary for "connection security" of their customers is anyone's guess. It's not as if the very latest Chromium couldn't be run headless or embedded or puppeteered with automated clicks, with all the feature gimmicks thus available to botters. And if someone is actually going to hack a site, verifying that they're human sure isn't going to keep them out.
I seriously doubt that a significant amount of "bad" traffic to these sites comes from browsers that were commandeered because the user had turned off site isolation... Mostly what this seems to accomplish is gatekeeping against older browsers. 
0 -
12 hours ago, NotHereToPlayGames said:
Everything web-based Google works without allowing the telemetry from the Chrome Web Store setting a Google cookie.
So this cookie is only set by the Store and not by Gmail or their other services? Sorry for asking again, but saying "everything web-based Google works" doesn't really answer this part for me. The reason I'm asking is that it seems a bit unlike Google to only track Store users in a permanent way and not everyone with a Google account. When this tracking feature was first introduced, it seems to have applied to Google accounts in general (I say this based on reading a few articles from the time), but of course 360 may have made any number of changes to what Google had in place.
0 -
2 hours ago, NotHereToPlayGames said:
13.5.1030 does not pass.
But 13.5.2022 does pass.
13.5.1030 should also pass if Disable site isolation in chrome://flags/ is set back to Default. Browser restart is needed for this to take effect. After restarting, double-check in chrome://flags/ that the change actually took - 360 occasionally doesn't save its state properly upon shutdown. If the setting is OK, https://mybrowseraddon.com/webrtc-control.html should work. Tested with a freshly unzipped 360ChromePortable_13.5.1030_rebuild_7_ungoogled profile, YMMV if other settings have been customized.
The reason this works in 13.5.2022 is that the distribution doesn't include a pre-set \User Data\Local State the way 13.5.1030 does, so there are no customized preferences loaded from it.
5 -
1 minute ago, VistaLover said:
Actually, that suite (0x9c) is natively supported by Serpent 52.9.0 and it's controlled by pref:
security.ssl3.rsa_aes_128_gcm_sha256
I had it set to "false", because, as posted, that suite is "WEAK"; enabling it and restarting the browser:
made MEGA downloads initialise and complete successfully!
Many thanks @mixit
Glad to be of service.
I should have checked if this was already included before tagging @roytam1 ... In my feeble defense, I don't actually use Serpent - I'm still on self-built pre-drama Centaury (in combination with 360 and occasional VM browsing with the officially "in" browsers) but it turns out it actually has it too, disabled by default. 
At least it's nice to occasionally have a browser problem we can solve on our own without endlessly waiting for "upstream".
I have to say, I almost missed the SSL problem because we've been totally conditioned to always look at the JS console as of late 
I wonder what's up with Mega and this single-cipher thing, though...
3 -
6 minutes ago, VistaLover said:
FWIW, both cypher suites are considered "WEAK" by SSL Labs, because they lack "Forward Secrecy":
Well, in cases when there's weak secrecy vs "complete secrecy" in the form of "no connection possible", the former might be handier.
As with other ciphers, these could be disabled in about:config settings when not needed, couldn't they?
2 -
@AstroSkipper, you wouldn't by any chance have *.mega.co.nz in your [SSL Pass-Thru] section in config.ini, would you?
I just downloaded ProxHTTPSProxy 1.5.220717 and it was there in the default .ini file. After removing it, I was able to download from Mega without problems.
Edit: Correction, on another try there were "temporary errors", but they really were temporary this time and the download still completed fine.
1 -
1 minute ago, AstroSkipper said:
The cipher suite TLS_RSA_WITH_AES_128_GCM_SHA256 was already implemented in ProxHTTPSProxy 1.5.220717. I tried to connect to Mega using Serpent 55 via ProxHTTPSProxy 1.5.220717, and the download of files didn't work, either. Same issue as without using the proxy. Therefore, I think the problem is presumably not only a cipher incompatibility.
Ah, that's unfortunate then... I just saw cipher mismatch failures with this (IMHO pretty unusual) single-cipher host and assumed that was the likely main culprit.
Well, even if there's a proxying workaround, I think it'd still be a good idea to enable these ciphers in Serpent itself for compatibility reasons, especially considering how trivial the patch looks.
0 -
On 1/1/2023 at 12:17 PM, NotHereToPlayGames said:
enables a cookie that you can not delete
Since the launcher can delete anything in the profile, are you talking about just using the "normal" in-browser means? And is this something peculiar to the Google Play Store and not happening if someone signs into their Google account for Gmail or another service?
I know you guys talked about this cookie a while back but I didn't pay very close attention back then and I only use Google for search and translation.
0 -
7 hours ago, VistaLover said:
Since my daily driver is Serpent 52, I loaded that link there and all 3 initial stages (Requesting folder data, Receiving folder data, Decrypting folder data) completed fine, with the page loading as expected; however, when clicking the green "Download all as ZIP" button, the download attempt invariably fails
, claiming a "Temporary error, retrying":
This actually doesn't look like a JS thing but rather a cipher incompatibility, as at least some Mega download servers seem to be for some reason using TLS_RSA_WITH_AES_128_GCM_SHA256 exclusively
and Firefox only enabled it (and TLS_RSA_WITH_AES_256_GCM_SHA384) with bug 1638369 in version 78. Seems trivial for @roytam1 to implement, so probably not a problem for long (if this is all there is to it).
2 -
46 minutes ago, NotHereToPlayGames said:
Because "life is too short" to sweat the small stuff. And it's all small stuff.
0 -
14 hours ago, NotHereToPlayGames said:
What do you have for these options? The "unsafe" URL message tells me you have a third-party being contacted for each and every download!
No need to worry, I most certainly don't "have" that - my notes on this are from April and it's not something seen since. I'm pretty sure it had to do with the podcast server having moved subdomains to where the existing certificate didn't apply, but if there was any real MITM involved, that would have been very much first-party
, i.e. me temporarily intercepting SSL traffic. But the only files that coincide with the timestamp on those notes are some of those podcasts I never got around to listening.
7 hours ago, NotHereToPlayGames said:I think me and @UCyborg are the only two on x64.
How very exclusive!
BTW, not to nag too much, but why post like this when you can edit? I mean when you're not talking on separate subjects or replying to different people, and there are no intervening posts by others.
0 -
@NotHereToPlayGames @Humming Owl
I just remembered I forgot to report a yet another stray Chinese UI string I saw a while back. It shows up when downloading from a "dangerous" site; IIRC there was a certificate problem with a not at all suspicious podcast host when I saw it. I'm too lazy to look for a suitably problematic site right now, but you can simulate it if you search for
85 E4 00 00 00 8D 86 F8 02
in chrome.dll (2022) and temporarily replace that85there at the beginning with 84. Then when you hover over the d/l button, all downloads should be red and have that message attached (if the filename is too long, you can see it in the tooltip).
The string is "（来自危险网址）":
EF BC 88 E6 9D A5 E8 87 AA E5 8D B1 E9 99 A9 E7 BD 91 E5 9D 80 EF BC 89
A fairly literal translation would be " (from unsafe URL) ". In any case, it's UTF-8, and should be padded with spaces to full length of 24. I also recommend starting with a space before the paren, because Chinese parentheses are double-width and have the space "built in".2 -
18 hours ago, NotHereToPlayGames said:
@mixit - how where you able to isolate the QR Code and Translate to English context menu entries? Was there a specific software debugger you used?
I've been able to edit your build 2022 patches to work with build 1030 but I'd like to verify them with the method that you used as a compare/contrast.
Since I still use 1030, I actually used it to develop this patch before applying it to 2022.
So, for 1030:
Drop Share URL QR Code from Chrome mode page context menu:
89 F968 6D 1A 00 00 68 4F 81 00 00
EB 0F 68 6D 1A 00 00 68 4F 81 00 00Drop Share URL QR Code from Chrome mode link context menu:
89 F168 6D 1A 00 00 68 50 81 00 00
EB 0F 68 6D 1A 00 00 68 50 81 00 00Drop Share URL QR Code from IE mode page context menu:
6A 0068 D5 08 00 00 FF 75 08 FF 15 E4 B1 EA 16
EB 5E 68 D5 08 00 00 FF 75 08 FF 15 E4 B1 EA 1668
E4 2500 00 FF 75 08 FF 15 E4 B1 EA 16
68 D5 08 00 00 FF 75 08 FF 15 E4 B1 EA 1668
E4 2500 00 FF 75 08 FF 15 64 B2 EA 16
68 D5 08 00 00 FF 75 08 FF 15 64 B2 EA 16Drop Share URL QR Code from IE mode link context menu:
8D 7D E868 6D 1A 00 00 57 E8 41 58 17 FB
EB 3A 90 68 6D 1A 00 00 57 E8 41 58 17 FBDrop Share URL QR Code from IE mode image link context menu:
8D 45 D868 6D 1A 00 00
EB 43 90 68 6D 1A 00 00Drop Share image location from Chrome mode image context menu:
89 F968 6E 1A 00 00 68 51 81 00 00
EB 0F 68 6E 1A 00 00 68 51 81 00 00Drop Share image location from IE mode image context menu:
6A 006A 0F 53 FF 15 E4 B1 EA 16 83 F8 FF 74 3C
EB 4A 6A 0F 53 FF 15 E4 B1 EA 16 83 F8 FF 74 3CDrop Translate to English from Chrome mode page context menu:
8D 86 F0 02000050 E8 2F 9E 72 FE
E9 E6 00 00 00 90 50 E8 2F 9E 72 FEAs for your questions, I used the obvious suspect for such things.
But its free version or Ghidra 
or OllyDbg should work just as well. Finding the locations isn't too hard with the source code for Chromium available, don't really need to decompile or use the debugger. It takes quite some time to disassemble/analyze a huge DLL like this one, though.
2 -
1 hour ago, UCyborg said:
Oh, the REBASE.EXE I mentioned, it's the tool that was bundled with older Microsoft Visual C++ IDE (Integrated Development Environment), maybe also older Microsoft Visual Studios (individual suites for each language (C++, Visual Basic...) were later combined into one Visual Studio, well, the tools are still separate, there's just one big program from where you open project files and edit code).
It's also included in the Windows 7 SDK (GRMSDK_EN_DVD.iso), still freely available straight from MS. Those who don't want to install the whole thing can use something like lessmsi to extract ReBase.exe from \Setup\WinSDKTools\WinSDKTools_x86.msi and its adjacent cab1.cab. And those who don't want to download the entire 500+ MB SDK from MS can use Archive.org's browsable ISO content to only get these two files.
3 -
1 hour ago, Humming Owl said:
Also, in some browsers (I don't remember which at the moment) modifying the "chrome_elf.dll" file results in the browser not opening (it shows a warning instead that the browser might have a trojan - basically me heh).
IIRC, it was mentioned somewhere in the notes by the Russian crew that 360chrome originally had a custom DLL signature check (i.e. not dependent on Authenticode), which for modding purposes has been patched out for chrome.dll and the rest, but not for chrome_elf.dll for security reasons.
1 -
Been meaning to post these @feodor updates from the Russian-language forum, because sooner or later someone's going to ask again.
December 4:
QuoteThe main thing is that there's even less power now and there's talk everywhere that soon all power stations could be blown up, so like sit and hope and wait...
December 14:
QuoteComputers are starting to break down from sudden power cuts, have to do OS reinstall at the minimum, so I haven't really worked on the browser in December so far. I think maybe I should get more RAM and run builds fully in memory. But there's not much left, maybe I can still make it by New Year's.
I presume he means that heavy parallel disk activity during builds is causing disk corruption when power is suddenly cut, so building on a RAM disk would help with that.
1 -
On 12/22/2022 at 11:13 PM, UCyborg said:
No idea where the tool was originally published and who wrote it, I think it came only in source code form and I wrapped it inside Microsoft Visual C++ 6.0 (another dinosaur) workspace file and compiled it.
Seems to originate from Dr Dobb's (source code links are dead there, but it's available here).
@AstroSkipper might appreciate how period correct this little program is.
1 -
@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 - 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?!
), 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!
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.
5 -
I think this "one empty tab at startup" metric may actually not be all that useful, because if you open up a bunch of of additional tabs to fill out all available memory (for example pile up Youtube videos) and then close them all, the initiall processes' working sets[1] have gone down to the lower bounds reported here and appear to stay there afterwards, even though their private bytes values stay at the upper bounds. YMMV, but that's what I saw just now - even working with settings pages and dev tools it that tab didn't make them go up again.
Edit: I'm pretty sure though that this particular metric isn't the only reason @AstroSkipper says he can't use 360 on a low spec system.
[1]Thanks @msfntor for the reminder. My XP x64 daily driver has 32 GB RAM, so these two values tend to stay pretty close, making me forget about the difference.
0 -
9 minutes ago, msfntor said:
Why you not consider "Working set"? That's memory usage.
Possibly because I have that column set up further back so I'd have to scroll to see it and "out of sight, out of mind".
0 -
For me, Dencorso was the soul of this place from when I first started visting here til he slowly waned from the forum.
He was the first one to reply to my first post/thread here, and to my great surprise pinned it moments later! I remember back during the 2017 crisis situation of the forum possibly disappearing, he'd PM people in charge of projects and pinned threads to make backups of everything important and be ready to regroup elsewhere to keep this community alive. I wish I'd talked to him more, but that's entirely on me...
I'm not going to repeat all the good things that have already been said above about this exceptional person, but I would like to paraphrase Den's next-to-last status update (which I think in itself can be considered the manifesto of current MSFN).
Indeed EoL != EoS (in this case End of Spirit) and the spirit of Dencorso can be kept alive here for as long as we all care to. May he rest in peace.5
Extreme Explorer 360 Chromium 78-86 General Discussion
in Browsers working on Older NT-Family OSes
Posted · Edited by mixit
@djole123
So, I'd already started investigating how I could remove the integrity check so you could try out further compatibility with OneCore API, when it suddenly occurred to me that this would be a waste of time, at least for me.
The thing is, the only reason I'm using a Chinese derivative of Chromium is because it's deliberately compatible with XP as-is, and one of a handful of (also Chinese) still useful versions remaining. AFAIK 360 SE v14 has no provisions for XP x64, so I have no reason to pick it over other brands, because adding Chinese "goodies" to Google's is not something I'm interested in when I have more choice. Since this is really a case of having to use OneCore to run "a" Chromium clone on XP x64, 360 SE v14 has no advantages for me. The extra layers the Chinese have added to it would also probably make it less stable on OneCore.
One more consideration: OneCore API binaries Github page says it's currently compatible with Chrome 102, but this v14 is based on 108, judging by its user agent string, so the chances of it working right now don't seem very high.
I'm not at all opposed to you or anyone else using these Chinese browsers as a choice even if you have other options, but with all things being equal, I myself would choose something else. I'd probably start my trials with plain Chromium - to minimize the number of potentially troublesome features. In any case, best of luck, and don't let what I just said stop you if you want to proceed with getting 360 SE v14 working on XP x64 using OneCore API. And apologies for being so "I-my-me" above
, I just wanted to make clear that I'm not claiming to represent the general sentiment around here.