Re: [OFF] Lenguajes de programación para escritorio
El 14/02/2016 a las 14:12, alparkom . escribió:
>
> En ningún momento dije que solo sirvieran para escritorio. Esa clase
> de distinción solo existe en tu cabeza.
Pues si lo dijiste, y varias veces, por algo pegue tu comentario en el
mensaje anterior.
>
> Bien. Recordemos bien esto. Osea que a cualquier software hecho en
> C/C++ (e imagino que en otros lenguajes) se le podrá hacer ingeniería
> inversa. Recordemos bien esta parte.
>
Estás equivocado. Una cosa es hacer ingeniería inversa para saber como
funciona un binario, y otra cosa es crear una interfaz de conexión a una
base de datos, para que luego el programa te pida una autentificación
(contraseña de usuario) y solo autentificado se pueda acceder a los
datos cifrados o hasheados dentro de un archivo seguro, para poder
levantar la conexión segura entre tu cliente y el servidor. Hazte a la
idea de que un baúl de seguridad como el que usa Seahorse, en el cual
almacenas la información y que solo puedes abrir y leer con la
contraseña correcta.
>
> Si almacenamos la información en un "archivo asegurado", el software
> en sí debe tener un método para poder "recuperar" o "traducir" dichos
> datos.
> Ahora recordemos el comentario anterior... la ingeniería inversa;
> recuerdas? Podemos obtener el método que ocupa el software para
> traducir la información, esto asumiendo tus mismas palabras.
>
Ya arriba lo explique, y nuevamente te digo, no tienes ni la mas mínima
idea, a menos claro, que planees hackear los archivos cifrados o
hasheados, suerte con eso, dependiendo de lo que uses te llevará mucho
tiempo sacar la información.
>
> Claridad, tengo bastante. Solo que mi pensamiento es propio... digo,
> aprendo solo, por lo que no manejo conceptos que te enseñan en
> tutoriales o universidades (entre otros).
>
No amigo, claridad no tiene, lamento decirlo. Usted está tratando de
aprender por usted mismo, eso está bien, le felicito por ello, pero le
recomiendo que comience a leerse libros de programación antes de
consultar a cualquier loco en Internet. Una recomendación que le hago es
que se centre en un lenguaje en un principio, trate de aprender Python o
C, en primer lugar, los verá muy educativos, luego que sepa bastante de
esos lenguajes y pueda crearse una UI, entonces vaya por otros lenguajes.
Aplíquese aquello de: "El que mucha abarca, poco aprieta".
>
> No entiendo bien a que te refieres con "Linuxismos". Por ahora,
> aprendí algo de Java y puedo crear aplicaciones de escritorio bastante
> buenas.
Esta es otra muestra de que no tiene claridad ni tiene la más minima
idea de como hacer las cosas en programación. Cuando hablo de
"Linuxismos" hablo de programar usando funciones, sentencias, variables
de entorno, o lo que sea, que sea única y exclusivamente disponible en
Linux.
Para programar en multi-plataforma, lo mejor es evitar ese tipo de
cosas, puesto que a la hora de compilar en otros SO, simplemente fallará
la compilación, puesto que las librerías difieren mucho en la mayoría de
los casos. Un ejemplo: trate de usar conio.h (una librería para MS) en
GNU/Linux y verá que no podrá compilar un programa en C que use dicha
libreria usando GCC, y tendrá que hacer un parche y portar la aplicación
para que pueda funcionar.
A ese tipo de cosas, es a las que me refiero.
> Después de todo, la lógica en la programación es la misma en todos los
> lenguajes, por lo que solo aprendiendo la sintaxis y algunas funciones
> (clases en caso de Java) ya basta. Como llevo poco en Java (como 2
> días solamente) ahora me falta aprender clases. En realidad, mas que
> "aprender", sería "conocer".
>
Cierta la lógica es la misma, los recursos son los que cambian. Java es
un poderoso lenguaje, multiplaforma, pero cuidado con lo que escribe o
no podrá disfrutar de esa potencialidad.
>
> No entiendo porque el :facepalm: si dije bastante varias veces que no
> tengo idea de C o C++.
Lo del facepalm está mas claro que el agua. ¿Para que instalar una VM
con Visual Commnunity si tienes IDEs como Anjuta, KDEvelop y todos los
que ya nombre antes? No tiene ni pies ni cabeza lo que haces, a menos
claro que te guste Visual Community en Windows.
> Lo del compilador lo entiendo (mas o menos), después de todo he tenido
> que compilar varias veces para poder instalar programas que no estaban
> en los repositorios. A lo que iba era que Visual Studio tiene soporte
> "visual" para los "objetos" que se le pueden "insertar" en los
> programas. Algo así como en Netbeans puedes crear un JFrame y el mismo
> IDE te permite arrastrar y soltar los objetos dentro de la ventana de
> tu programa... eso se puede en Visual Studio para C++ (creo), y el
> equivalente en Linux sería...? A eso me refería.
Pues te doy conocimiento:
a) Netbeans funciona en Linux, y te permite trabajar de forma visual.
b) Elipse también,
c) Anjuta + Glade también te permiten trabajar así.
d) Builder + Glade.
e) CodeBlocks + Glade o QtDesigner.
f) KDEvelop + Glade o QtDesigner.
Incluso para los mas pro, puede usar Glade o QTDesigner y usar emacs y
vim para editar el código a mano y a la vieja escuela.
>
> Entonces, me monto la máquina virtual para poder usar las opciones de
> Visual Studio y no tener que comenzar en C++ creando ventanas con
> código. Es preferible crear las ventanas en Visual Studio (u otro IDE
> que lo permita) y revisar el código para ver como se hace desde él.
>
> Por cierto, no soy fan de este tipo de métodos. Prefiero todo desde código.
No quiere trabjar en Visual y quiere escribir código, entonces te
recomiendo vim o emacs (con el que te sientas más cómodo), incluso Geany
te sirve, basta y sobra para hacer eso que pides.
>
> Ingeniería inversa...
>
Respuesta equivocada. No tienes ni idea de que es, para que sirve y como
usar la ingeniería inversa, después de todo es algo que tu mismo has
aceptado, desconoces totalmente.
> Por cierto, el software que tenga los datos de conexión estará
> instalado en los clientes. Y supongo (por lo que dijiste hace rato)
> que se pueden obtener.
>
Acá otro detalle. Cierto, el software tiene lo datos de la conexión,
pero esos datos:
1.- No están metidos en el código, están en un archivo seguro, cifrado y
con clave. Puedes realizar ingeniería inversa al binario, y no obtendrás
esa información, porque no está allí.
2.- El código de tu programa solo tiene la interfaz para leer el archivo
seguro, pero para leerlo, te hace falta una clave que solo el usuario
conoce y que también está en un archivo seguro. En pocas palabras, sin
la clave, el archivo no se puede ni abrir, ni leer, ni escribir.
3.- Trata de hackear los archivos para obtener la clave, pero suerte con
eso, dependiendo de lo que uses en el programa te puede llevar mucho
tiempo sacar la información que buscas.
>
> Ya comenté que diseñar interfaces es fácil, pero al fin y al cabo
> funcionarían con HTML y CSS. Lo que pregunté (o me interesé) fue si
> era posible implementar JavaScript para crear interfaces en lenguajes
> como C, C++, C#, Java u otro lenguaje.
>
Si se puede, usando bindings, ya lo dije GNOME y Cinnamon hacen
precisamente eso, pero tiene una pega...puede ser muy lento y come memoria.
>
> Okey. Supongo que no necesito saber algo como eso para ser avanzado en
> algún lenguaje, ya que soy avanzado en JavaScript, no en el lenguaje
> que esta escrito GNOME3 o Cinnamon.
No entendiste lo que quise decir. GNOME y Cinnamon usan JS para crear
ciertas GUI en sus escritorios, no es un lenguaje aparte, es un binding
en JS para poder usar GTK, eso es todo, si no recuerdo mal, se llama gjs.
>
> Si el cliente envía los datos de conexión, estos no irán cifrados por
> lo que se podrán obtener.
Entonces vas mal. Si planeas hacer una app segura usando conexiones de
internet debes CIFRAR la conexión, o no importa lo que hagas, ni en que
lenguaje lo escribas, todo sera en vano, basta poner un sniffer en la
conexión y sabrán todo.
> En el caso de que vallan cifrados, el cliente lo habrá hecho (cifrar)
> por lo que se podría obtener el método que utilizó para cifrar y
> obtener los datos... ojo, esto asumiendo lo que dijeron varias veces.
>
No eso no funciona así. Si cifras una conexión de forma segura, la
información viajará blindada y podrán escuchar la conexión, pero jamás
sabrán que información está pasando por allí, a menos claro que tengas
unos medios muy especiales (NSA o servicios de inteligencia), pero eso
es otro asunto.
>
> No entiendo. De todas formas, la forma más segura es simplemente no
> hacer la conexión a la base de datos.
Eso ya es cuestión de diseño, puedes hacer las conexiones directamente a
la base de datos, o indirectamente usando un "proxy", que podría ser una
capa más de seguridad.
> El método que utilizaré será mediante sockets, de esta forma el
> cliente no se conecta a la base de datos, sino el servidor en
> respuesta al socket que envía este cliente.
Usa sockets, pero es más de lo mismo. Si no cifras los datos que van por
el socket, la vas a pasar mal. Una forma sencilla, rápida de hacer apps
usando sockets es usar SDL Net, pero está en C.
>
> Cifrar un archivo y dejarlo en el cliente no suena muy seguro. Por muy
> cifrado que este.
>
El archivo cifrado solo va a tener:
1.- Los datos de conexión del cliente (usuario y contraseña)
2.- Los dirección y puerto del servidor.
El resto de la data (información del resto de tus usuarios) está en la
base de datos del servidor, a la que solo TU tienes acceso.
Si un cliente es hackeado o le roban sus credenciales, solo podrá
obtener acceso a esa cuenta y nada más. Los datos de tu servidor,
estarán seguro, siempre y cuando:
1.- Tu programación del lado servidor sea segura.
2.- Tengas permisos bien definidos para lo que se puede y no se puede
hacer por parte de cada usuario en la base de datos.
>
> Tu dijiste lo mismo que él, parece que no le prestas mucha atención a
> los mensajes y las sugerencias que me han intentado hacer varios acá.
>
No sigo a @Camaleon, le tengo bloquead@ por troll desde hace mucho
tiempo, mucho antes de que usted entrara en la lista me parece.
Sugerencias como las que te he hecho, te han hecho otras personas
también, el punto es que algunas de esas sugerencias no las entiendes en
absoluto, y el mejor ejemplo es lo de "ingeniería inversa", allí erras
por completo el concepto de esa practica, con los comentarios que has
hecho anteriormente.
--
Dios en su Cielo, todo bien en la Tierra
Reply to: