Proxy about eset-keygen

[AdityaGarg8]

Apologies for my ignorance, but what would be the point of adding a proxy if the emails are already disposable?

Some of my thoughts (I am not the dev) and several reasons that are quite straightforward:

• most obvious - anonymity (masking ip) against tracking by various endpoints related to eset and email providers. Maybe also for google/firefox telemetry, github (?), python telemetry (?)
• internet connections that work only through some proxy (eg. corporate/ school). though obviously, running such code through these networks could have consequences
• protection against isp filtering or state censorship
• protection against having your IP marked as spam/malicious by eset/ email providers

Now, if you run the code instead via github actions, you don't normally need to pass proxy to the keygen since MS IPs will be exposed instead. However, github/MS, ISP and even state actors including security organizations (3rd parties/ state sponsored/ state security) will (theoretically and if really determined) be able to track down that you run this code under your github account and under your specific IP provided by your ISP (with or without proxy in keygen). You'd have to always connect to github via proxy/vpn anonymously if you would really want to preserve your anonymity in this case.

A worthy note is that after applying the generated license in eset, your IP basically will be exposed to ESET with or without using a proxy anyway when generating the license (unless you mask your IP at Windows OS level through VPN/proxy). They could probably know that that particular generated trial license using disposable emails (even identified to be generated by this keygen by the way the eset account creation was performed) is used by your eset installation and will eventually be able to track and leak data to them about you (as an AV it has full admin permission and since it is not open source you cannot guarantee what exactly leaks about you). Theoretically they could also mark your installation as abusing (and maybe illegal or even contact police/ISP) and prevent you to use more trial licenses. I actually wonder why they don't have such mechanism in place, for a reputable AV they claim they are.

Ironically, another key point is that this project itself, will eventually force eset to use a more aggressive way of detecting abuse in the future, especially since they hold the advantage of them having proprietary code while the keygen being opensourced and more easily counterattacked.

The only way GitHub can track your keygen is using your Actions history in your account, cause IP addresses are common for all accounts. GitHub actions runners use dynamic IP addresses. So, VPN on GitHub won't do anything. So for true anonymity, use VPN on a real machine.

[Uj947nXmRqV2nRaWshKtHzTvckUUpD]

Apologies for my ignorance, but what would be the point of adding a proxy if the emails are already disposable?

Some of my thoughts (I am not the dev) and several reasons that are quite straightforward:

• most obvious - anonymity (masking ip) against tracking by various endpoints related to eset and email providers. Maybe also for google/firefox telemetry, github (?), python telemetry (?)
• internet connections that work only through some proxy (eg. corporate/ school). though obviously, running such code through these networks could have consequences
• protection against isp filtering or state censorship
• protection against having your IP marked as spam/malicious by eset/ email providers

Now, if you run the code instead via github actions, you don't normally need to pass proxy to the keygen since MS IPs will be exposed instead. However, github/MS, ISP and even state actors including security organizations (3rd parties/ state sponsored/ state security) will (theoretically and if really determined) be able to track down that you run this code under your github account and under your specific IP provided by your ISP (with or without proxy in keygen). You'd have to always connect to github via proxy/vpn anonymously if you would really want to preserve your anonymity in this case.

A worthy note is that after applying the generated license in eset, your IP basically will be exposed to ESET with or without using a proxy anyway when generating the license (unless you mask your IP at Windows OS level through VPN/proxy). They could probably know that that particular generated trial license using disposable emails (even identified to be generated by this keygen by the way the eset account creation was performed) is used by your eset installation and will eventually be able to track and leak data to them about you (as an AV it has full admin permission and since it is not open source you cannot guarantee what exactly leaks about you). Theoretically they could also mark your installation as abusing (and maybe illegal or even contact police/ISP) and prevent you to use more trial licenses. I actually wonder why they don't have such mechanism in place, for a reputable AV they claim they are.

Ironically, another key point is that this project itself, will eventually force eset to use a more aggressive way of detecting abuse in the future, especially since they hold the advantage of them having proprietary code while the keygen being opensourced and more easily counterattacked.

[rzc0d3r]

Yes, it makes perfect sense. In my view, it would be more sensible for the person executing the code to use a VPN. For instance, I use SoftEther on both my phone and PC, and I have other alternatives like TunnelBear and Proton. My point is, I believe it's the individual who uses the code that should take precautions. If they're already using such means to obtain passwords, it's obvious they engage in other activities. Therefore, it's the individual who should be cautious instead of incorporating it into the code. Does what I'm saying make sense?

ABSOLUTELY!!! And because of people's laziness I have to suffer)))))

[rzc0d3r]

Могу попробовать добавить поддержку прокси без авторизации

[rzc0d3r]

Не получается никак. С авторизацией - не работает, без нее тоже.

[zulicheg]

Хм... я конечно не очень разбираюсь, но может это оно? https://www.zenrows.com/blog/selenium-proxy#proxy-authentication или тут https://pythonturbo.ru/selenium-with-proxy/

[rzc0d3r]

Я это и пробовал делать. Но прокси листы в интернете какие-то странные у меня из всех никто не заработал. Вечно то ошибка туннелирования то сертификаты то ещё что-то

[Uj947nXmRqV2nRaWshKtHzTvckUUpD]

you can use tor as proxy (tor expert bundle), no need to use public shitty proxies. this way you'll get real anonymity
https://www.torproject.org/download/tor/

create torrcProxy config file under TorExpertBundle\Data\

add to the new torrc config the lines:
DataDirectory FULL PATH TO TorExpertBundle\Data\ # should work relatively as well
SocksPort 50000

TorExpertBundle\Tor\tor.exe -f TorExpertBundle\Data\torrcProxy

in firefox set socks proxy localhost:50000 by whatever means (maybe with selenium proxy)

all traffic in firefox will go through tor network

Both eset and mailprovider seem to be allowed on tor

[soujiang]

Apologies for my ignorance, but what would be the point of adding a proxy if the emails are already disposable?

[rzc0d3r]

Apologies for my ignorance, but what would be the point of adding a proxy if the emails are already disposable?

The eset website is blocked in some countries

[rzc0d3r]

Apologies for my ignorance, but what would be the point of adding a proxy if the emails are already disposable?

Some of my thoughts (I am not the dev) and several reasons that are quite straightforward:

• most obvious - anonymity (masking ip) against tracking by various endpoints related to eset and email providers. Maybe also for google/firefox telemetry, github (?), python telemetry (?)
• internet connections that work only through some proxy (eg. corporate/ school). though obviously, running such code through these networks could have consequences
• protection against isp filtering or state censorship
• protection against having your IP marked as spam/malicious by eset/ email providers

Now, if you run the code instead via github actions, you don't normally need to pass proxy to the keygen since MS IPs will be exposed instead. However, github/MS, ISP and even state actors including security organizations (3rd parties/ state sponsored/ state security) will (theoretically and if really determined) be able to track down that you run this code under your github account and under your specific IP provided by your ISP (with or without proxy in keygen). You'd have to always connect to github via proxy/vpn anonymously if you would really want to preserve your anonymity in this case.

A worthy note is that after applying the generated license in eset, your IP basically will be exposed to ESET with or without using a proxy anyway when generating the license (unless you mask your IP at Windows OS level through VPN/proxy). They could probably know that that particular generated trial license using disposable emails (even identified to be generated by this keygen by the way the eset account creation was performed) is used by your eset installation and will eventually be able to track and leak data to them about you (as an AV it has full admin permission and since it is not open source you cannot guarantee what exactly leaks about you). Theoretically they could also mark your installation as abusing (and maybe illegal or even contact police/ISP) and prevent you to use more trial licenses. I actually wonder why they don't have such mechanism in place, for a reputable AV they claim they are.

Ironically, another key point is that this project itself, will eventually force eset to use a more aggressive way of detecting abuse in the future, especially since they hold the advantage of them having proprietary code while the keygen being opensourced and more easily counterattacked.

absolutely correct

[soujiang]

Yes, it makes perfect sense. In my view, it would be more sensible for the person executing the code to use a VPN. For instance, I use SoftEther on both my phone and PC, and I have other alternatives like TunnelBear and Proton. My point is, I believe it's the individual who uses the code that should take precautions. If they're already using such means to obtain passwords, it's obvious they engage in other activities. Therefore, it's the individual who should be cautious instead of incorporating it into the code. Does what I'm saying make sense?