Hola.
1. Como ya te han comentado, si realizas una conexión será visible, no solo mediante la decompilación del código de tu ensamblado, sino con cualquier monitor de conexiones entrantes/salientes, así que no tiene sentido ocultarla, por que a lo segundo no podrás ocultarle esa información (o al menos estoy casi seguro al 99% de que no, tampoco pongo la mano en el fuego pero creo que no se puede eludir que el S.O intercepte/notifique las conexiones salientes de tu dispositivo de red, vaya xD).
2. En el caso de que aún siendo cosnciente de esta información sigas deseando intentar ocultar la información en el código fuente como una forma de protección adicional para prevenir que lo puedan ver ciertos "intrusos" con un nivel de conocimiento básico/medio, pues a mi personálmente no me parece una mala idea, siempre viene bien cualquier tipo de protección aunque no sea infalible, pero entonces deberías utilizar un software profesional de ofuscación/cifrado para ensamblados .NET, tu mejor opción gratuita es
ConfuserEx, pero yo te recomiendo que optases por la herramienta
SmartAssembly de RedGate, que añade muchos más sofisticados niveles de protección de forma profesional.
estoy empezando en esto asi que si veis algo raro por favor ayudame
El mejor consejo que te puedo dar es el siguiente:
Una persona, ya sea programador de .NET novato o avanzado, debería ser consciente de que está utilizando el framework más completo actualmente en el mundo de la programación, .NET Framework, y por ese motivo en lo respecto a cosas básicas (y no tan básicas) no le va a faltar de nada, no es necesario recurrir a
copy&pastes de códigos
home-made de terceros ni tampoco tratar de implementar nuestros propios algoritmos por que en la mayoría de ocasiones lo que estaremos haciendo es reinventar la rueda sin darnos cuenta, puesto que la librería de classes de .NET ya nos facilita la mayoría de todas esas y otras tareas complejas, así que se debe intentar siempre buscar una solución
built-in y evitar los códigos "caseros"... aunque por otro lado claro está que las librerías de .NET Framework no cubren al 100% todas las necesidades que el programador pueda tener y en muchas ocasiones uno se verá obligado sin más remedio a implementar sus propios algoritmos (criptográficos, o de lo que sean), pero antes de rendirse y optar por esos medios, seguir buscando dentro de las librerías de .NET hasta encontrar lo que nos hace falta...
Por ejemplo, antes que ponerte a implementar algoritmos aleatorios caseros de cifrado básico de strings, tienes a tu disposición las classes criptográficas que forman parte de la librería de classes de .NET Framework en el namespace
System.Security.Cryptography, como por ejemplo la class
RijndaelManaged,
AES,
TripleDES, y una infinidad de proveedores de hashing, no necesitas más.
Aparte de los miembros ya mencionados, también tienes a tu disposición la class
System.Security.SecureString, la cual es tan sencilla de usar como la class
StringBuilder, y esta metodología añade un nivel adicional de seguridad a un string mediante su cifrado en un bloque de memoria no administrada, y el valor real solo puede ser accesible al cracker si uno sabe al 100% lo que hace al inspeccionar el código IL en la descompilación.
Un saludo!
Autor
En línea
