
w2k4eva
MemberAbout w2k4eva

Profile Information
-
OS
none specified
Recent Profile Visitors
2,783 profile views
w2k4eva's Achievements
20
Reputation
-
That's the problem... it only works for a very few file types, and those only to/from a very few locations. It does NOT work at all for non-media type files, and that is BY DESIGN. Try to copy a PDF file from your computer to your phone, it WON'T just drag & drop. Same issue with Word docs, emails, map placemarks, or a zillion other file types. As for location... I have some navigation apps that use large data files (some can be >16GB) for their maps. It might have been nice to use my desktop to generate the needed data, then drag&drop them onto my phone into the app's folder. But MTP mode not only won't handle that file type, it also won't let me reach the correct location to drop it into. Even if I use the file renaming trick, the best I could do is to drop it somewhere like Downloads, and then try to use Ghost Commander on the phone to move it where it needs to go. But that doesn't work either since Downloads is in internal storage, and it would be too large for the amount of free space there, so I end up needing ADB to put it on the SD card directly. There's also the issue that j7n hasn't yet found suitable device drivers to make it work.
-
Definitely. ADB can be used to make or restore backups, and has access to some places that normal apps would not, so these backups can be more complete than those made by other methods. It can grant or deny various permissions. It can install or uninstall apps. It can explore directory stuctures, copy, move, rename or delete files within device storage or to/from your windows computer, change file permissions or ownership, or generally do most shell commands. It can remount read-only partitions as read/write (though you still need to consider how to deal with dm-verity on some of them like /system). It can reboot the phone into recovery mode or bootloader mode, useful if you want to change ROMs. It may be able to change itself to root mode, depending if Xiaomi left some config settings on that would allow this. It also has a "sync" function in addition to the backup/restore functions. I find myself using ADB at least once a month or so, mostly because that crippleware MTP mode does not always preserve file timestamps correctly, where using ADB does. I have not looked into Xiaomi in particular, but that arrangement sounds typical for getting a bootloader unlocked. While it is not directly rooting, it is typically the first step in either rooting or in installing a custom ROM. One thing to get clear about before you do that, is for some vendors, requesting that unlock will void whatever manufacturer warranty the phone had, so best to check the rules before asking. My guess here would be that their web site is coded to want Chrome, and the needed functions are missing in whatever older browser you tried. If you don't like Google Chrome (I sure don't!) there are other chromium based browsers that are more privacy friendly. Brave ver 1.47.186, while not the most current, does run on W7 and is my go-to browser when my preferred SeaMonkey can't cope. Others might include Chromite, Vivaldi, etc; you can probably find a thread elsewhere on these boards about browsers still running in W7 for more ideas. Yeah, that is part of what I meant about the hassle factor. The card itself is usually pretty sturdy and not likely to break. But if your phone has one of those little pop-out trays that hold both cards, that thing is a lot more delicate and definitely prone to breakage, assuming it doesn't just get lost. I usually just install the card once and leave it in permanently, since ADB is simple enough for me to copy stuff out with. Yep. Even worse, for my FroYo device, doing this has about 50% odds of causing the phone to reboot, so I have to unplug everything, wait for it to finish, and start over. There's no real reason why the procedure to unmount and remount a partition should fail so often for androids when it is very reliable on Linux desktops, but apparently Google preferred to do away with it entirely rather than debug the actual problem here. Somehow desktop Linux systems solved this problem a long time ago and routinely stop trying to access a partition that is unmounted. I don't know why the same solution never made it into the android kernels. Oh, I just thought of another... if you have a USB-OTG adapter that fits your phone's USB port, you can plug in a standard USB thumb drive and use something like Ghost Commander to copy files in and out.
-
With each new version of Android it seems Google takes away previously useful features and makes others harder to use. USB Mass Storage is one that went away a long time ago. Sadly there is no way to bring it back. Some more detail is at https://www.howtogeek.com/192732/android-usb-connections-explained-mtp-ptp-and-usb-mass-storage/ Some ideas are mentioned at https://android.stackexchange.com/questions/91900/is-there-a-viable-alternative-to-mtp-for-file-transfer but I'm not convinced they are any easier than just using ADB, especially since you still need the same USB drivers to do some of those ways too. If you add an SD card, it can be inserted/removed and connected to a laptop or desktop that has a suitable adapter to read it. Just make sure it is not set up as "adopted storage" or it will be encrytped so Windows would not be able to read it. (Modern Linuxes can work with this once you extract the encryption key from your phone but it is something of a hassle to do.) But moving the SD card around all the time is something of a hassle, and you probably want to use MTP and/or ADB depending on the content to be moved. In particular, the MTP protocol can only handle media. Meaning pictures, videos, soundclips, songs, etc. It will NOT want to let you move other content like PDFs, APKs, browser bookmarks, encryption keys, etc. It may sometimes be possible to rename something to be one of the allowed file types, transfer it with MTP, then use a file manager on your phone to rename it back, but that gets cumbersome after a while and in some locations may not even be allowed. So these other types of content are best handled with ADB. Depends on your definition of "bloated", and of course assuming you are moving only suitable file types. You will need to install some device drivers (typically under 25MB). Probably best to get these from Xiaomi if possible, or there are some generics that can be used even with Windows XP. Oh, and you might need the Kernel-Mode Driver Framework (KB2685811 ?) if you don't already have it. If you want to use ADB you will need to add the platform tools package (the latest version 34.0.5 still runs on W7, possibly even Vista, and is 12.2MB unpacked). Just unzip it somewhere, open a CMD window, make sure the unzipped folder is in that window's PATH variable, and you should be good to go. In case you have not used this before, there is a bit of explanation at https://developer.android.com/tools/adb and a command reference at https://adbshell.com/
-
YouTube just doesn't work this way, in fact it is exactly backwards from what you want. I have never had a google account of any kind, including YouTube, and have never been blocked from watching any video I wanted to see. And trying to put restrictions on her account (if it is even possible) isn't likely to work for very long - at age 11, she is old enough to figure out that she can just go view them without logging in. You might be better off having a conversation with her about why some content is not suitable and convincing her to avoid it on her own. Especially since a channel blacklist is about as useless as an AV that tries to work by listing known malware - there will always be a new item that is not on the list yet. You might still be able to set screen time limits, or per-app time limits, with whatever parental controls are in Windows or Android, though. Just not channel-specific blocks.
-
Dang, wish I had seen this reply before I started putzing with this again... this might have been an interesting thing to try. The problem seemingly affected roughly a third of the entire internet, not just those sites. Anyway, the problem was clearly something about my XP system, since my W7 laptop running SeaMonkey 2.53.19 connected to the same router could view those pages. Your reply above plus AstroSkipper's confirmed that it was not IceApe (and your second reply also rules out old SeaMonkey 2.49). So, thanks to both of you for confirming that. SeaMonkey (and thus IceApe based on it) does not use any of the settings from IE/Internet Options, none of its trusted or blocked zones, etc. I had already updated the system root certs. I know SeaMonkey (and thus IceApe as well) uses its own internal cert store rather than the system one; just for jollies I looked there to verify the relevant certs were in place (they were, for both browsers). I was not using a proxy either, and had already disabled AV scanning of web pages for other reasons, so that left Comodo. None of the Comodo firewall rules where I could mark the checkbox for "log this" produced any log outputs (for either browser). This narrowed it down to the only place without such a checkbox, namely the "Blocked Network Zones" list (which had only 6 obscure sites listed, so should not have been doing this much blocking). I tried deleting the one rule that uses this list, and replacing it with another rule that lists each of these entries separately, rather than as a reference to the first list. That did let me browse those sites, with both browsers. Next I tried going back to using that list in the rule again, which broke those sites (again for both browsers). This list, like all Comodo rules, is stored as part of a private registry hive, and thus subject to the same bitrot issues as the rest of the windows registry. I ended up having to delete the reference to the list, then delete the contents of the list as well. Retried some of those pages, they worked again. Finally re-entered the contents of the list, then used the list in the block rule, thus putting everything back like it was before this mess started. And after re-entering all this stuff, that seems to have cleared out the bitrot, and everything works again, for both browsers. So, long story short, having such a paranoid set of firewall rules sort of qualifies as a "loose nut behind the wheel" type problem!
-
You're right, I never saw the forum software do that before... link is fixed. Here are screenshots for the linked sites. Lest you assume it is some sort of network blockage or firewall issue - no, it is able to visit the Qualys site, it seems to report TLS1.3 being available as expected. While these screenshots are being made with iceape default profile that has no addons, I get the same results in my seamonkey install with its usual addons, which in time past used to be able to visit github until fairly recently. I even tried installing JustOff's polyfill addon (since I use it on my W7 system running 2.53.19) but that makes no difference on the XP system, not sure if it can really work in Seamonkey 2.49 even after installing, but it does not help either seamonkey 2.49 nor iceape. What I find odd is that iceape supposedly has TLS1.3 available where seamonkey 2.49 does not, yet that seems to make no difference in what sites the browsers can connect to.
-
I recently installed IceApe on my old XP system (it has SP3 and the PosReady2009 updates) hoping that some of the web sites that old SeaMonkey can no longer connect to might be workable, but found no difference. The same list of websites get the Connection refused error in both browsers. Ironically, this very site is among the ones SeaMonkey can no longer load. So are https://o.rthost.win/ https://github.com/roytam1/iceape-uxp/tree/winbuild https://rtfreesoft.blogspot.com/ In other words, Ice Ape cannot visit its own sources, nor download itself, even after being installed. Is this expected? Do other people see the same issue? edit: Whoops, I meant to put this in the "Browsers working on Older NT-Family OSes" subforum, could moderators please move it?
-
Root Certificates and Revoked Certificates for Windows XP
w2k4eva replied to heinoganda's topic in Windows XP
Not directly, the web server decides which cert chain to present. At some sites it depends on what device, OS or browser it thinks you are using, or what location it thinks your IP is at. You can try experimenting with different user agent strings, but some web sites use additional javascript libraries or other fingerprinting methods to get past a simple UA string spoof. Or you can try different VPNs to get IP addresses from different locations. -
ProxHTTPSProxy and HTTPSProxy in Windows XP for future use
w2k4eva replied to AstroSkipper's topic in Windows XP
Yes, this is my conclusion as well:- 922 replies
-
1
-
- TLS protocols
- HTTPSProxy
-
(and 3 more)
Tagged with:
-
ProxHTTPSProxy and HTTPSProxy in Windows XP for future use
w2k4eva replied to AstroSkipper's topic in Windows XP
Okay... it looks like that should have covered it in terms of having the certs. So what is left is whether chrome360 can handle the certs it has. Which is a different question than whether they are missing. For the two X1 root certs, are they indeed the same? Or does one use ECC type encryption while the other uses RSA? You would need to examine both of those certs in detail to see that. Could you look at which certs that site is actually using, and check each one in the chain to see if they are using the possibly problematic ECC versions? For some versions of some browsers, if a given website had multiple possible paths to chain to a trusted root cert, they would try the first path encountered and if that failed they would not try any of the other paths even if that would have worked if the first path tried had not been there. For that situation one would have to figure out the failing path and eliminate some certs so that path would not be possible, forcing the browser to use another path that would work. I do not know whether your version of chrome360 has this issue, or if eliminating such a duplicate path might help for your case. Some other users are posting screenshots of such ECC certs working in XP with MyPal, is trying that an option for you? Otherwise you are back to making the proxy handle it for chrome360, which does indeed belong in this thread.- 922 replies
-
- TLS protocols
- HTTPSProxy
-
(and 3 more)
Tagged with:
-
ProxHTTPSProxy and HTTPSProxy in Windows XP for future use
w2k4eva replied to AstroSkipper's topic in Windows XP
Seems this question could fit in any of 3 threads. Since the screenshots are already in this thread, I'll try here, though if forum admins ask and/or move the posts with screenshots I'll be happy to move there. But looking more at your previous screen shot, leaves me more confused too, it gives conflicting information. On the heading "Insecure connection" it says "Your connection to web1.carparts-cat.com is not encrypted" but 2 sentences later says the connection is encrypted, plus the "security overview" thing has the 2 items of green text saying ""the connection to the site is encrypted" and "All resources on this page are served securely" ... rather contradictory. Does anyone have access to source code for chrome360 who can tell us what this combination of messages might actually mean? Also from the previous screen shot, it says "Certificate - missing". Your second screen shot shows the ISRG Root X2 cert, but not as a root cert - that looks like the cross signed version (actually an intermediate cert, not a root cert), which depends on also having the X2 cert signed by the X1 cert. So, does your chrome360 have a root cert for ISRG Root X1 (probably listed on a different tab in the certificate manager, I don't really read German so can't suggest the tab title)? Part of the confusion is that there are multiple versions of these certs, having the same names. That's why I mentioned "Certificate details (self-signed)", it seems you have the cross signed version. If you need the X1 root cert, it can be downloaded from the same page I linked before (again, look for the "self signed" variant). So if that is present (as a root cert, it too has a cross signed intermediate form that would require yet another root cert that signed it), it might come down to whether chrome360 can handle the ECC type encryption, or if not, whether you can get the proxy to do that for you.- 922 replies
-
- TLS protocols
- HTTPSProxy
-
(and 3 more)
Tagged with:
-
ProxHTTPSProxy and HTTPSProxy in Windows XP for future use
w2k4eva replied to AstroSkipper's topic in Windows XP
Does your chrome360 include the root cert ISRG Root X2 ??? This could be as a root cert, or in the older case it used to be an intermediate cert cross signed by ISRG Root X1, which in turn could have been either a root itself, or cross signed by DST Root CA X3. If that/those is missing you might have a problem... it DOES appear to be properly encrypted, just to a root cert that itself is not trusted. edit: you can download the cert from https://letsencrypt.org/certificates/ scroll down to "Root CAs", then "ISRG Root X2", then "Certificate details (self-signed)" choose your format, since I do not use chrome360 I'm not sure whether it prefers *.der or *.pem, someone on here who uses it can give better instructions on how to add it for your browser, or if it uses the system store- 922 replies
-
- TLS protocols
- HTTPSProxy
-
(and 3 more)
Tagged with:
-
Root Certificates and Revoked Certificates for Windows XP
w2k4eva replied to heinoganda's topic in Windows XP
One thing that still puzzles me is about the *.sst files themselves. What is the function of each file, and does updroots.exe do anything different based on the filename it is called for? I mean, the use of something called "delroots.sst" or "disallowedcert.sst" seems self explanatory, but what about the other 3? I see from the contents that roots.sst has Microsoft-related stuff that could be needed to check the cert lists themselves, so it makes some sense to have it in a separate file for the convenience of those folks who want to manage their own lists. But for authroots.sst vs updroots.sst, the difference is less clear. There must be some reason Microsoft used 2 files instead of combining them all into 1 file, so how are these different? -
I've been seeing this Wayback problem for at least 4 years now. It seems to affect many (most/all?) MS KB pages that were crawled from 2016 onward. I never had much luck with this method, since for me the page load takes several seconds after clicking Stop to take effect. So I must stop it before the page is shown and it was very hard to get the timing right on something I can't see yet and am not sure exactly how long it will take on any given attempt. What I did notice is that over the years MS has changed the format of URLs for their KB pages, and usually the older version of the URLs was from a time before this wayback problem. So fortunately for this particular update there is actually an older crawl with the different format of URL that works, even from SeaMonkey 2.49.2 on XP: http://web.archive.org/web/20150602151315/https://support.microsoft.com/en-us/kb/898461 (notice the /en-us/kb/ part, these are usually the better formatted crawls) Sadly for other updates there isn't always an older crawl that will work, and sometimes I am stuck with having to view page source and poke through the HTML tags to find the unformatted content (which is generally still present although not rendered correctly/at all).
-
There are a few lists, depending on whether you do/don't use MS Office, .NET, WMP11, IE8 etc. Some posts: https://msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/?do=findComment&comment=1156088 https://msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/?do=findComment&comment=1162280 (and next post too) https://msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/?do=findComment&comment=1167061 Perhaps you want the opposite list, of updates that are SSE2-free? https://msfn.org/board/topic/178377-on-decommissioning-of-update-servers-for-2000-xp-and-vista-as-of-july-2019/?do=findComment&comment=1162417