elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Security Series.XSS. [Cross Site Scripting]


+  Foro de elhacker.net
|-+  Programación
| |-+  Programación General
| | |-+  .NET (C#, VB.NET, ASP)
| | | |-+  Programación Visual Basic (Moderadores: LeandroA, seba123neo)
| | | | |-+  Aplicación Visual Basic que truena
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: Aplicación Visual Basic que truena  (Leído 2,310 veces)
pmoren

Desconectado Desconectado

Mensajes: 5


Ver Perfil
Aplicación Visual Basic que truena
« en: 14 Julio 2019, 07:01 am »



Hola a todos, resulta que tengo un cliente que cuenta con un sistema SCADA, ya funcionando desde hace 15 años. El caso es que ahora va a cambiar sus medidores de flujo, por unos más modernos con nuevas funciones ( los cuales funcionan por  red a puerto serie convertidos a través de un  servidor digiport ). Para comunicarse con estos medidores de flujo , usan un programa que fue mandado a hacer el cual se llama acucom. Este acucom fue programado en visual basic6  hace como 15 años. Resulta que mi cliente es un poco desordenado y el código fuente que tenia del acucom, no es exactamente la misma versión que el binario que tiene corriendo (pero si muy parecido) . Esto es, cuando yo compilo el código fuente que ellos tienen, el binario que se produce es distinto ( por un par de KB) al que ellos tienen corriendo. Ahora bien, tampoco se en que VERSION de VISUAL BASIC compilaron, y como VB6 tiene muchos parches y services packs eso mete mayores dudas a la ecuación, ya que yo estoy compilando todo con VB6 sin service packs.
En base al código fuente original , un programador me desarrollo todos los cambios para que el nuevo programa funcione con los nuevos medidores de flujo, sólo que el no conoce muy bien los API´s originales del sistema, y uso conectores standards . Tenemos una copia idéntica de su maquina virtual en la oficina e hicimos las pruebas con los medidores de flujo y todo funciona ok.
Todo el nuevo programa , el acucom v2 está programado en VB6, SIN USAR los SP del VB6. No sé que cambie entre usar el SP y no usarlo.

Sin embargo cuando montamos todos los cambios en Producción tenemos el siguiente problema.

Descripción del problema:
Nuestro programa acucom v2 corre en el servidor de producción sin problema. Pero cuando algún usuario pica un botón del SCADA, de la parte gráfica, en ese momento se traba toda la máquina y tanto nuestro programa  como el resto de “programas satélites” empiezan a tronar. Aparece en el task manager que no responden. Cabe mencionar que ese botón invoca consultas a la BD, a través de macros y de Access.
La diferencia entre nuestras pruebas de laboratorio y el servidor de producción, es que en laboratorio como no existen muchos equipos remotos, muchos de los “programas satélites” no arrancan o solo arrancan parcialmente.
 El gran problema es que nuestro acucom v2 levanta bien y no se truena, más bien choca con algo del sistema, no encuentro la manera de debbugear o de ver exactamente con que está chocando ni porque.
El otro problema que tengo, es que como es un servidor que YA  está siendo usando para producción, mi cliente casi no me presta el sistema de producción, por lo cual tengo muy poco acceso a este servidor para hacer pruebas. Todo debo hacerlo sobre la maquina virtual que tengo, la cual es una copia exacta a la de mi cliente

Descripción del sistema:

El sistema corre en Windows 2003 server  sobre una maquina virtual VMware .
El sistema es un tipo de sistema standard conocido como SCADA. Básicamente se compone de una base de datos en Microsoft SQL Server 2000 y la aplicación principal (el SCADA) . El SCADA es un programa que se compra a un gran fabricante de software ( obviamente viene sin código fuente).
El SCADA, no es un solo programa, es todo un sistema de compúto  (es un conjunto de muchos programas coordinados) y está diseñado para interactuar con equipos remotos.
A este SCADA se puede personalizar varías cosas, como son pantallas, puntos de acceso a la base de datos. También cuenta con Apis y se conecta a la BD, de varias maneras, tanto directamente como usando tablas espejo de MS ACCESS 2000.
Este tipo de sistema permite la interacción con programas externos y trae algunos protocolos de comunicaciones propios, pero también es muy común que se le integren protocolos de comunicación y otros programas hechos por programadores externos.
Preguntas:
    1. Como puedo saber la versión con la que se compilo el programa, incluyendo los service packs?
    2. Hay manera de descompilar el binario y en ese caso de algo ayuda ya tener un código fuente parecido?
    3. Puedo escribir el programa en un Visual Basic más moderno? Ayudaría de algo con mi problema actual? O en otro lenguaje .. no tengo limitantes al respecto.
    4. Como puedo debbugear el problema, ya que el programa truena, y no tengo mayor información, no sé cómo atacar el problema o por donde buscar una solución. Ya que en realidad tampoco sé que es lo está originando realmente.
    5. Les ha pasado cosas parecidas con esas versiones de software? En esas épocas salían parches y sp nuevos cada rato..
    6. Que se les ocurre que pueda hacer para resolver este problema?


« Última modificación: 14 Julio 2019, 07:09 am por pmoren » En línea

Serapis
Colaborador
***
Desconectado Desconectado

Mensajes: 3.391


Ver Perfil
Re: Aplicación Visual Basic que truena
« Respuesta #1 en: 15 Julio 2019, 15:42 pm »

Instala el servicepack sp6 de visual Studio. El servicepack, no va a dañar nada funcional, sino al contrario haría que si algo operaba con el sp6, y uego no está presente si que diere problemas, luego instalarlo, debería solventarlo.

No das los detalles que realmente importan... pero al menos es de suponer que un programa más o menos complejo tendrá librerías compiladas al mismo tiempo,.. sería adecuado cuando compiles que señales la compatibilidad adecuada al caso. "compatibilidad de versión"... esto es, repasa adecuadamente las propiedades del proyecto.

Justo acabo de compartir el archivo en otro mensaje, para instalar... copio y pego aquí:

Citar
Aquí las descargas que señalé ayer...
https://workupload.com/archive/CrtCf8Z

Accesible las 2 siguientes descargas:
1 - VB60SP6-KB957924-v2-x86-ESN.msi - 9'80Mb. Actualización acumulada para vb6 - sp6 (español). Contendrá todas las librerías que pudieran faltarte...
2 - vb6cli - Problemas de licencia de controles.rar  - 26kb. leer el txt que viene dentro, para tener claro su cometido...

Es normal que no te dejen operar en el equipo de producción si allí funciona todo bien, no pueden arriesgarse a que alguna prueba lo dañe... Lo adecuado, sería crear una imagen del disco duro de ese equipo, reproducirla en otro idéntico, y ahí sí, ya podrías operar sin miedo a dañar nada... como es copia idéntica cuando funcione el nuevo sistema sin problemas podría asegurarse que también lo haría en el equipo de producción, aunque igualmente aconsejo antes de hacer cambios, crear una imagen del equipo al momento actual... también sería adecuado que te prestaran 2 o 3 equipos viejos para probar en remoto, igualmente sería conforme que fueran una imagen de sendos equipos reales y así se vería como afecta.

Ten en cuenta que compilar un mismo proyecto siempre arrojará un ejecutable distinto aunque todo lo demás fuera igual (por cuestión de la fecha). En cuanto a la variación de tamaño del ejecutable, perfectamente puede obedecer a la configuración de la compilación, por ejemplo si en las propiedades del proyecto eliges compilar para código reducido o código rápido, etc... generará ejecutables de  diferentes tamaños. Eso sí, no compiles a p-code, compila a código nativo, por cuestión de eficiencia.

También podría variar el tamaño si se hayan añadido/eliminado mensajes de texto (por ejemplo basta el simple mensaje del 'about', que hacía referencia al autor/es previo/s para que varíe 1-3kb.).

El modo más adecuado de hacer cambios en sistemas complejos es hacerlo en fases... primero x cosa cuando funcione se hace el siguiente cambio. Si algo falla al menos queda claro que fase contiene los errores y minimiza donde encontrarlos. Pretender hacer 25 cambios (nuevo programa, nuevas BDs, nuevas conexiones, nuevos S.O., etc...) te complica las cosas, porque cuando algo no depende de tí, la info que provea del problema, pués eso 'no depende de tí'...

...dicho de otro modo, prueba primero a que el programa funcione con los viejos medidores (esto te asegura que la versión del que tienes el código fuente, está completo y libre de errores, quien sabe si esa era una versión previa con errores que luego se corrigieron en una nueva versión de la cual no se posee el código fuente)... Si ahora el programa que tú compilas funciona bien con los  viejos medidores y con todo lo viejo, puedes asumir que el código fuente es correcto y es a partir de ahí que debes hacer los cambios (copia del proyecto para trabajar en la nueva copia), para operar con los nuevos medidores.
Y si ahora hay problemas ya sabes que cosas pueden ser descartadas y en cuales centrarte... en fin procede en pasos lógicos que descarten desde el origen que tengan problemas y por tanto dar por sentado que los errores están en partes donde no están. en proyectos grandes es fácil que un problema afecte a distintas partes, pero entendiendo el error queda claro como y dónde solucionarlo, pero si ni siquieras llega uno a czar el errror se va a ciegas... subiendo escalones uno a uno, cuando uno se rompa y te caigas, ya sabes que ese escalón falla, se arregl y se sigue adelante...


En línea

Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  

WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines