- Jan 29, 2017
- 1,201
The rounded tabs are more aerodynamic ... my page loads are so much better now 
How To Return To Chrome's Old Look (And Fix The Blurry Text On Windows)There is a bug with blurry fonts and windows scaling:
Chrome Stable Channel Update
Google investigating issue with blurry fonts on new Chrome 69 | ZDNet
880513 - Font rendering is broken, antialias messed up, blurry, weird - chromium - Monorail
I'm affected by this, but there is hope...
Thanks
btw, isn't this version that was supposed to block every 3rd party code injection?
Are the blocks purely meant to be against code injection for things like anti-exploit or is it also going to be against how AVs scan encrypted traffic and such?@Windows_Security i don't have issues with HMPA and chrome, it is why i wondered if v69 implemnted the blocks.
no ideas, the announcement was quite vague but i bet it will be any kind of injections.Are the blocks purely meant to be against code injection for things like anti-exploit or is it also going to be against how AVs scan encrypted traffic and such?
@Windows_Security i don't have issues with HMPA and chrome, it is why i wondered if v69 implemnted the blocks.
Probably only user land dll injections, because that is the oldest and most common way to get a grip on medium IL processes in general. Also chrome broker process runs at Medium IL, so it is the maximum they can achieve with their current architecture.It "solved" the Kaspersky ERR_SSL_VERSION_INTERFERENCE error, but I still see Kasperkys root certificate, the geen safe indicators on a Google search and malware sites are still blocked by Kaspersky. So it blocked some injections, but not all?
i didn't say you did, i said i didn't have issues which intrigued meWhere did I post that you had issues with HPMA and Chrome?
Adding the parameter
/high-dpi-support=1 /force-device-scale-factor=1
Great!!Adding the parameterworks.Code:/high-dpi-support=1 /force-device-scale-factor=1
Chrome is as default 100% and then I use Chrome's zooming at 125%.
That way Chrome's interface stays small (100%) but the text on web pages is with 125% readable for me and not blurry.
It's a temporary fix.
@Windows_Security i wondered if v69 implemnted the blocks.
AppInit_DLLs injection is user-mode based - and it only applies to processes which use User32.dll.AppInit Dll is set in regsitry (HKLM) so should bypass Chrome's userland injecttion protection
You can easily make a driver to hook to any process through the kernel... There's actually drivers like that available (as open source).AppInit_DLLs injection is user-mode based - and it only applies to processes which use User32.dll.
When User32.dll is loaded into the context of a process, its main entry-point routine named UserClientDllInitialize is invoked and eventually a routine named ClientThreadSetup will be invoked; depending on a number of checks internally performed, a routine named LoadAppInitDlls which is exported by Kernel32.dll will be called.
View attachment 197269
The above figure shows some of the disassembly for the ClientThreadSetup routine from a 64-bit User32.dll (Windows 10 64-bit, latest version).
The LoadAppInitDlls routine will use the RegOpenKeyExW (Win32 API) routine to get a handle to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows key, and if successful, will pass this key handle to another routine - which we'll call "LoadAppInitDllsInternal" for now but remember that I've just made up that name for the sake of this post.
The "LoadAppInitDllsInternal" routine will do the following in order:
1. Check the key value for RequireSignedAppInit_DLLs
2. Check the key value for AppInit_DLLs
3. Call LoadLibraryExW to load the applicable modules listed under AppInit_DLLs
The RegGetValueW (Win32 API) routine is used to query the data of key values (for RequireSignedAppInit_DLLs and AppInit_DLLs) - which internally relies on the NtQueryValueKey (Native API) routine. If the return value from RegGetValueW is zero (ERROR_SUCCESS) (as well as the queried data being >= 1) when it is being used for the RequireSignedAppInit_DLLs check, then the undocumented flag IMAGE_DLLCHARACTERTISTICS_FORCE_INTEGRITY (0x80) will be passed for the Flags argument on all of the LoadLibraryExW calls for the AppInit_DLLs operation.
View attachment 197271
The above figure shows some pseudo-code from IDA-64 on a routine from a 64-bit User32.dll (Windows 10 64-bit, latest version).
It goes without saying that AppInit_DLLs injection will not work on Secure Boot enabled environments and is apparently preventable through process mitigation policies.
This research was conducted on an up-to-date version of Windows 10 (64-bit environment) with User32.dll and Kernel32.dll (64-bit versions of the modules only) - the information provided within this post is subject to change in the future and the AppInit_DLLs integration is likely going to have implementation detail differences on older major versions of Windows (e.g. Windows Vista and 7).