How undetected-chromedriver works
The library drives Chrome through the standard Selenium stack - it speaks the Selenium WebDriver protocol to a ChromeDriver binary, which controls the browser. Its distinguishing behaviour is that it patches that binary and adjusts how the browser launches so common automation markers are not exposed. Two are frequently cited: the cdc_-prefixed properties that ChromeDriver injects into the page, and the navigator.webdriver flag. Rather than renaming those internals after the fact, the project's approach is to keep them but prevent them from being injected in the first place. It remains tied to Selenium and the WebDriver protocol, which is the layer its successors drop.
Lineage and where it fits
undetected-chromedriver sits at the root of a family tree: undetected-chromedriver gave rise to nodriver, which in turn was forked as zendriver. The newer tools abandon Selenium entirely and drive Chrome directly over the Chrome DevTools Protocol, because the WebDriver layer is part of what introduces the artifacts undetected-chromedriver has to patch out. As the most-starred and longest-lived tool in the group it has the widest community and documentation, but its release cadence has slowed and the author has publicly positioned nodriver as the official successor.
What it does not do
The project is explicit that it does not mask your network identity. A patched driver changes what the browser exposes in JavaScript, but the request still comes from whatever IP you connect with, and a datacenter or low-reputation address remains an independent signal a detection system can weigh regardless of how clean the browser looks. It also operates above the network layer, so it does not change the TLS fingerprint or other server-side signals. Patching automation markers is one layer of many, not a complete answer.