Hacker News Reader

Comment by grishka | Hacker News Reader

What surprises me about this stuff is that no one has ever tried to get a definitive answer to this sort of question with the help of reverse engineering. It's always this guesswork for some reason. It does not have to be guesswork when the ground truth is right there inside your C:\Windows folder.

View on HN

you act as if reverse engineering is easy. I guarantee you its not, especially something like edge is a rats nest of packages, assemblies, 3rd party components, config files, all neatly bundled in something unreadable for security reasons.

Browsers are hard to reverse engineer

I specialized in reverse-engineering binaries for a few years (it's shockingly common for companies to lose the source code for their own products), and I second this.

Reverse-engineering is difficult and time-consuming. Reverse-engineering something as large and complex as a browser would be a huge project all by itself.

Currently writing a talk about loss of institutional knowledge.

Can I quote you? Also, if you're comfortable, can you give me more background on yourself so I won't just be quoting a rando on the Internet?

Raymond Chen has some about it, too, on his blog (also search Microsoft pinball).

Ah, thank you!

What about getting ahold of the binary or whatever raw version of Windows you can get (C++, assembly?), and look at the diff from before this change and after. Would that drastically narrow down what you should look at? Moreover, if there is a literal CONSTANT that says "Chrome", is it possible that it's not obfuscated and sitting in the code in plain sight?

I would think it would be the Windows equivalent of `grep -a Chrome -R C:/Windows`, right? Then, when it finds the file, just hexdump and/or disassemble it to learn more. Maybe they're scrambling the executable somehow?

I wonder if there's any stability there given compiler features like LTO and PGO

So the opening of the dialog happens when user association hash verification fails if I recall correctly.

Shell32.dll has the code for it under QueryUserAssocAndVerifyHash I believe. Perhaps they've interfered with the hash interpretation for Chrome or Chrome is hooking into it in a different way - Firefox directly computes and writes a new hash to the registry.

Raw diffs of binaries may or may not help, depending, but it's not likely to help as much as you might think. If you can get the source code (C++, assembly, whatever), then there's no need to reverse engineer anything.

I suspect that it’s worse than that, it’s somewhere in windows. So you’d probably have to start by hunting for a task then find the binaries associated and hope it’s not too high up in the OS mess.

I don't know why it's surprising. Reverse engineering an executable is quite a jump in skill level from guesswork.

That, and Windows is *huge*. The best bet would probably be to reverse engineer the patch in question, but if it’s a typical combo patch then you’re probably looking at changes across a dozen system files. If you’re unlucky, the patch is just flipping a flag or something for a feature that already existed: it wouldn’t surprise me if Windows already had hacks specifically for “chrome.exe” (for compatibility or anti-compatibility reasons). In that case it becomes much more time consuming to isolate the one component that is responsible for the problem.

I’d reverse engineer the API they were calling. Generally this kind of thing yields good results quickly.

"Reverse engineering" is vague and means anywhere from "poke at it randomly to see what it does" to "read the binary".

Isn't the more widely accepted meaning to de-compile it back to source code (of some form), and go from there?

Wow, drive letters in 2023.

Reply on news.ycombinator.com