We are apologize for the inconvenience but you need to download
more modern browser in order to be able to browse our page

Download Safari
Download Safari
Download Chrome
Download Chrome
Download Firefox
Download Firefox
Download IE 10+
Download IE 10+

Fuck Google Chrome’s HSTS feature

In Chrome  63, Google claimed that .app and .dev are new gTLDs, and then it claimed that the all websites that uses .app domains must enable HSTS.

I really appreciate many good features Google Chrome has brought to me, however as the Google Chrome continues to evolve, the using experience for developers is becoming more and more tedious.

Last time the Chrome refused to open an webpage which has cert error and HSTS enabled, but luckily there was an option called ignore-certificate-errors, which can makes the Chrome ignore cert error and continue.

However this time Chrome does not have any options to override HSTS policy for .app domains. The rule is defined in a static manner, which is very difficult to modify without recompiling the code.

(picture from http://sadomovalex.blogspot.com/2018/03/avoid-problem-with-redirecting.html)

The full list of predefined rules is described in:

https://raw.githubusercontent.com/chromium/chromium/master/net/http/transport_security_state_static.json

So to break these limits, we need to patch the Chrome. I chose the easiest way, which is patching the whole static part of HSTS.

Using the search functionality we can locate that the main logic in net/http/transport_security_state.cc:

  • it’s loading the rules into g_hsts_source,

  • and then using it in DecodeHSTSPreload:

So as long as we locate the DecodeHSTSPreload  function, we can then patch this function to return 0 so that none of the preloaded HSTS rules will be enforced :)

However that’s a big challenge.

  1. Using transport_security_state  as keyword, we can spot that it only appears in chrome.dll and chrome_child.dll, so the HSTS function should only appear in these DLLs. However the chrome.dll is ~60MB large, and chrome_child.dll is ~90MB large, which makes the initial analysis very, very slow
  2. Although slow, we can still load these huge files into IDA. But there aren’t any symbols. Luckily, there’s some string constants. With the help of string constants I managed to locate the crirital DecodeHSTSPreload  function

The Chrome version in this passage is 75.0.3770.142

You can simply patch at the very begining of the function with xor eax, eax; retn , but I prefer to patch the branch statements. Anyway simply make this function useless.

After we find it in chrome.dll, we can quickly locate the target function by signature

Luckily again the cmp/lea/jz/cmp sequence is unique across the binary, we can simply use “80 7C 17 FF 2E 48 8D 52 FF 74 F0 48 83 FA FF 74 ” to match the function.
Apply your patches to files and then overwrite the original chrome.dll and chrome_child.dll in Chrome’s install directory and then everything is done.

now we check again in chrome://net-internals/#hsts

Testing the foo.app, also working without any problems:

Bingo!

 

PS: Don’t forget to disable Chrome’s auto update functionality.