4 ms·

That's a technique used/required by some software cracking methods - override your general network DNS lookup process (I believe anything you put in the "hosts"

by maicro 4y ago

That's a technique used/required by some software cracking methods - override your general network DNS lookup process (I believe anything you put in the "hosts" file in Linux/Mac, and the similar file in Windows - though obviously don't quote me on this - will be used rather than DNS-queried). So you configure say "google.com" to go directly to 127.0.0.1 (the localhost address, pointing right back at your own computer) and run a server on the port that the program is expecting to authenticate to. The problem is responding to those API requests in a way that the program will accept - if it's just a simple PING, no issue, but if there's any sort of more advanced encryption, handshaking or license checking/exchange going on, you'll need to reverse engineer the algorithm. Some simple versions of that you can just record once and "replay", but most will at least have a timestamp hashed in. (super rough, lay-man's understanding of the issue - sorry for any inaccuracies)

kingds 4y ago
noob question: is there not a way for the client to verify that it is actually talking to google.com in a situation like this? I would think there would be some way to verify based on certs or something like that.
- maicro 4y ago
  Noob answer - yeah, that's what I'm talking about, there's certain levels of faking those responses that you can't really do.
- dec0dedab0de 4y ago
  yes, cert pinning, DNS over https, and encrypted DNS can make it much harder to see what the software on your network is doing. even just verifying ssl certificates client side is enough in most instances. Luckily, proxy servers in corporate environments have forced many vendors into not fully implementing these features.
- deleted 4y ago
  [deleted]
- _V_ 4y ago
  If you want to be sure, you have to pin your TLS certificates. That way someone either has to decompile your executable and replace that pinned cert (hard if you use SW signing), crack your signature (not likely) or steal your private key. There are several other methods that I've seen but they are not bulletproof: - talking directly to hardcoded DNS such as 8.8.8.8 - hardcoding IP addresses into SW - Checking for some obscure header as a part of client/server identification

by maicro 4y ago

kingds 4y ago

noob question: is there not a way for the client to verify that it is actually talking to google.com in a situation like this? I would think there would be some way to verify based on certs or something like that.

maicro 4y ago
Noob answer - yeah, that's what I'm talking about, there's certain levels of faking those responses that you can't really do.
dec0dedab0de 4y ago
yes, cert pinning, DNS over https, and encrypted DNS can make it much harder to see what the software on your network is doing. even just verifying ssl certificates client side is enough in most instances. Luckily, proxy servers in corporate environments have forced many vendors into not fully implementing these features.
deleted 4y ago
[deleted]
_V_ 4y ago
If you want to be sure, you have to pin your TLS certificates. That way someone either has to decompile your executable and replace that pinned cert (hard if you use SW signing), crack your signature (not likely) or steal your private key. There are several other methods that I've seen but they are not bulletproof: - talking directly to hardcoded DNS such as 8.8.8.8 - hardcoding IP addresses into SW - Checking for some obscure header as a part of client/server identification