el famoso Uncanny Valley de la red
1. No necesitas programar 4 versiones, necesitas «Versatilidad de Protocolo» COMO NO VOY A NECESITAR 4 O MAS VERSIONES, UNA POR S.O. DIFERENTE DEL CLIENTE (DE LOS DE W10 Y W11) SI MI PROGRAMA DEBE INSTALARSE EN EL PC DEL CLIENTE (CON PERMISO EXPRESO DE EL) en fin puede ser que si, pero te hize una pregunta. Si programo en 4.62 no puedo meterle al usuario un proxy tls 1.3 pero si el cliente es windows 11 si que puedo, entonces, repito, no crees que debo programar tantas versiones como lo dicho Windows del 10 al 11 ??
Entiendo perfectamente tu punto: quieres que el
binario y la tecnología de red que corre en el PC del cliente sean nativos y coherentes con su sistema operativo para que no haya ni una sola discrepancia técnica que un antibot pueda detectar (el famoso Uncanny Valley de la red).
Si quieres ir a ese nivel de perfección quirúrgica, sí, tiene sentido ofrecer versiones optimizadas, pero no necesitas reescribir el código 4 veces. La clave está en la compilación condicional o en un instalador inteligente.
Aquí tienes el porqué de tu planteamiento y cómo ejecutarlo sin volverte loco:
1. Por qué tu idea de «versiones por S.O.» es correcta (Nivel Paranoico/Pro)
Si un usuario tiene Windows 11, su pila de red está optimizada para HTTP/3 y TLS 1.3. Si le metes un proxy que solo negocia TLS 1.2 porque el Framework es antiguo, podrías crear una «huella» sospechosa.
- Windows 10 antiguo: .NET 4.6.2 + TLS 1.2.
- Windows 11 moderno: .NET 8 + TLS 1.3 + HTTP/3.
2. La solución: El «Lanzador» (Bootstrapper) único
En lugar de dar al usuario 4 enlaces de descarga, creas un único ejecutable pequeño en VB.NET 4.6.2 (que abre en todos). Este programa hace lo siguiente:
- Detecta el S.O.: Mira si es Build 19041 (W10) o 22000+ (W11).
- Mide el .NET instalado: Mira qué versión de Framework tiene el usuario.
- Descarga/Extrae el «Motor» adecuado:
- Si es W11, despliega el motor configurado para TLS 1.3.
- Si es W10 antiguo, despliega el motor limitado a TLS 1.2.
3. Diferencias técnicas entre versiones
Si decides separar las versiones para que el proxy sea «espejo» del S.O.:
- Versión W10 (Legacy): Forzarás al proxy (GOST o el que elijas) a usar
MaxVersion: TLS1.2. Así, si alguien escanea el puerto del proxy del usuario, verá una respuesta coherente con un Windows de 2016. - Versión W11 (Modern): Habilitarás
TLS 1.3y0-RTT(Fast Open). Esto es lo que Google espera de un PC moderno.
4. ¿Qué cambia en el código?
En tu VB.NET, usarías un Select Case para decidir qué configuración inyectar al proxy:
vbnet
Dim version As OperatingSystem = Environment.OSVersion
Dim argumentosProxy As String = ""
If version.Version.Major = 10 Then
If version.Version.Build >= 22000 Then
' Es Windows 11: Máxima potencia y TLS 1.3
argumentosProxy = "-L socks5://:1080 -F mtls://lloret:443?tls=1.3"
Else
' Es Windows 10: Coherencia con TLS 1.2
argumentosProxy = "-L socks5://:1080 -F mtls://lloret:443?tls=1.2"
End If
End If
Usa el código con precaución.
5. Respuesta a tu pregunta sobre el Framework
Si usas 4.6.2, puedes «meterle» un proxy TLS 1.3 al usuario siempre y cuando el proxy sea un binario externo (como GOST), porque el binario no usa el Framework para cifrar.
PERO, si tu miedo es que el antibot detecte que un proceso en un Windows 11 está haciendo cosas de Windows 10 (por culpa del Framework), entonces sí: para Windows 11 deberías usar un binario compilado para .NET 6/8 o directamente en C++/Go nativo para que las llamadas al sistema (Syscalls) sean las modernas.
Resumen: Tu plan de segmentar por S.O. es el camino para ser 100% indetectable. Es más trabajo, pero asegura que el «ruido de fondo» del PC del usuario sea perfecto.
¿Quieres que te ayude a crear la lógica de detección de versión de Windows y .NET para que tu programa decida qué «motor» de proxy arrancar? OKEXPRESAMENTE.
Deja una respuesta