Genial!!!!

Ahora me guardo el pdf con los otros. Espero ver los demas mas adelante.

Saludos

Es un gran libro sobre patrones de diseño. Esta en ingles pero es muy bueno.

Descarga: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Saludos

Buenisimo CloudswX!!

Ahora lo descargo y le pego una leida, se agradece.

Saludos

Los lenguajes de programación esotéricos son lenguajes minimalistas, creados como prueba de concepto y/o reto, tanto para programar el lenguaje como para escribir para él. Veamos un repaso de algunos de ellos:

Brainfuck

Es el más conocido y el más popular, su sintaxis es bastante simple:

++++++++++
 [          Bucle para iniciar las memorias (se repite 10 veces)
    >+++++++>++++++++++>+++++++++++>+++>+<<<<<-
       70        100       110      30  10
 ]
 >++.              'H'   (72) 1
 >>+.              'o'  (111) 3
 ---.              'l'  (108) 3
 <---.             'a'   (97) 2
 >>++.             espacio (32) 4
 <+.               'm'  (109) 3
 ++++++++.         'u'  (117) 3
 -------.          'n'  (110) 3
 <+++.             'd'  (100) 2
 >+.               'o'  (111) 3
 >+.               '!'   (33) 4
 >.                '\n' (10) 5

Para explicar su sintaxis lo mejor es recurrir a otros lenguajes de programación. Así, en No tienes permitido ver los links. Registrarse o Entrar a mi cuenta nos proveen de esta tabla de equivalencias, en las que ptr equivale a un unsigned char:


Ook !

Está basado en el anterior, pero utiliza en su lugar la combinación de palabras Ook?, Ook! y Ook. Es una parodia del bibliotecario de Mundodisco, que es transformado en orangután y solo puede pronunciar esas tres palabras. Veamos un cacho de código.

Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook. Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook. Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook. Ook! Ook. 

Supuestamente este "programa" lo que hace es escribir el típico "hola mundo".

Befunge

En mi opinión el más original de todos, su estructura de control de flujo se basa en flechas que le dicen al programa dónde ir. Además, facilita mucho la creación de código mutante (código que se modifica a sí mismo):

vv  <      <
    2
    ^  v<
 v13v4
    ^   ^
>  >?>  ?>5^
    v   v
 v97v6
    v  v<
    8
.  >  >   ^
^<

El código de arriba se trata de un generador de números aleatorios infinito, que generará un número entre el 1 y el 9. Bastante más legible que los anteriores.

Malbolge

Aquí tenemos a un lenguaje de programación creado para ser irritante e ilegible (no, no es C, y no, tampoco es Perl). Se trata de Malbolge, cuyo nombre proviene del 8º circulo del infierno de La Divina Comedia. Aquí tenemos un "hello world" (o eso me han contado que es):

(=<`:9876Z4321UT.-Q+*)M'&%$H"!~}|Bzy?=|{z]KwZY44Eq0/{mlk**
 hKs_dG5[m_BA{?-Y;;Vb'rR5431M}/.zHGwEDCBA@98\6543W10/.R,+O<

Lolcat

Una simple broma. Veamos su código:

HAI
CAN HAS STDIO?
I HAS A VAR
IM IN YR LOOP
   UP VAR!!1
   VISIBLE VAR
   IZ VAR BIGGER THAN 10? KTHX
IM OUTTA YR LOOP
KTHXBYE

Dado que es bastante más legible que los lenguajes de programación anteriores, dejaré que adivinéis que es lo que se supone que hace.

INTERCAL

Y por ultimo , pero no menos irritante tenemos a una parodia del lenguaje de programación FORTRAN . INTERCAL. Y aquí el hola mundo .

DO ,1 <- #13
PLEASE DO ,1 SUB #1 <- #238
DO ,1 SUB #2 <- #108
DO ,1 SUB #3 <- #112
DO ,1 SUB #4 <- #0
DO ,1 SUB #5 <- #64
DO ,1 SUB #6 <- #194
DO ,1 SUB #7 <- #48
PLEASE DO ,1 SUB #8 <- #22
DO ,1 SUB #9 <- #248
DO ,1 SUB #10 <- #168
DO ,1 SUB #11 <- #24
DO ,1 SUB #12 <- #16
DO ,1 SUB #13 <- #162
PLEASE READ OUT ,1
PLEASE GIVE UP

Bueno , y eso es todo .

He de decir que algunos de estos lenguajes de programación son muy útiles para aprender sobre algunos conceptos informáticos. Por ejemplo, Brainfuck es perfecto para aprender sobre los punteros.

Fuente: desdelinux

Saludos

Una DLL (Dynamic Library Link) o biblioteca de enlace dinámico, es un archivo que contiene bloques de código (funciones o métodos) que se ejecutan por solicitud de algún programa, es en ese momento cuando se carga en memoria.

Diferentes programas pueden utilizar simultáneamente una misma DLL, debido a su esquema modular. Por ello, la desinstalación de un programa podría afectar a otras aplicaciones que hicieran uso de bibliotecas compartidas.


El archivo DLL utilizado para este análisis, fue creado como prueba de concepto (PoC) con algunas acciones maliciosas que son comunes. A continuación, se muestra que el archivo "malicious.dll", efectivamente corresponde a una biblioteca de enlace dinámico con ayuda del comando "file" para Windows.


Con la herramienta "CFF Explorer" se puede obtener información importante como: el lenguaje de programación con el cual fue creado el archivo, su tamaño en bytes, sus firmas md5/sha1, el nombre original del archivo, entre otros.

Para el archivo "malicious.dll" se muestra la siguiente información:


Es recomendable que, así como a los archivos ejecutables sospechosos, a las DLLs maliciosas también se les realice un análisis de cadenas, con el fin obtener más información. En este caso, utilizando "BinText", se puede apreciar que manda a llamar la interfaz de línea de comandos de Windows con el argumento "C:\WINDOWS\system32\calc.exe", lo cual es un indicio de que la DLL contiene código que ejecutará el binario de la calculadora de Windows.


Al desensamblar la DLL con "IDA Pro", se puede corroborar que, una vez que se inyecta en un proceso, se ejecuta "calc.exe". La llamada al sistema "ShellExecuteA" lleva a cabo una operación en un archivo específico, en este caso, abrir la calculadora de Windows.


A diferencia de los programas ejecutables, no se puede hacer doble clic sobre los archivos DLL para correrlos, puesto que no son una entidad autónoma, por lo cual requieren de un proceso para operar. Los sistemas operativos Windows cuentan con una utilería llamada "rundll32.exe" (versión de 32 bits) para ejecutar archivos DLL. Sin embargo, las acciones maliciosas serán atribuidas al proceso "rundll32.exe", por lo que, si se utiliza "ProcessMonitor" para dar seguimiento a las acciones de la DLL maliciosa, el filtro por nombre del proceso deberá ser para "rundll32.exe".

A continuación se muestra el árbol de procesos:


También, puede presentarse un problema al correr una DLL con el comando "rundll32.exe", si es que la biblioteca de enlace dinámico valida el proceso en cual debe ser inyectada. Una solución podría ser renombrar la utilería "rundll32.exe" por el nombre del proceso objetivo, lo cual implicaría hacer una inspección más a fondo en su código ensamblador.

La inyección de DLLs, es la inserción de código de las bibliotecas de enlace dinámico en el espacio de direcciones de algún proceso, para que se pueda ejecutar. En nuestro laboratorio, utilizaremos la herramienta "DLL_Injector.exe" programada en Visual Basic y la herramienta "DLL_Shot.exe" programada en C#, ambas desarrollada por el equipo de análisis de malware.

·         DLL_Injector: herramienta de interfaz gráfica para inyectar una o varias DLLs en un proceso.


·         DLL_Shot: herramienta de interfaz gráfica para identificar las DLLs activas inyectadas tanto en el proceso del malware como en otros procesos objetivo. Lo anterior, es mediante la comparación de las bibliotecas de enlace dinámico activas en el sistema, antes y después de la ejecución de malware o inyección de DLLs.


Para analizar la DLL iniciamos las herramientas de monitoreo: "Process Explorer", "TCPView", "Regshot", "DLL_Injector" y "DLL_Shot".


1 ) Ejecutar el programa en el cual se inyectará la DLL maliciosa, por ejemplo en el "Bloc de notas"


2 ) Listar los procesos en el sistema, desde la herramienta "DLL_Injector", con el botón "List" y seleccionar el proceso objetivo


3 ) Buscar la DLL maliciosa con el botón "Browse ..."


4 ) Tomamos el primer shot, tanto con la herramienta "Regshot" como con la herramienta "DLL_Shot"


5 ) Inyectar la DLL en el proceso objetivo con el botón "Inject"


6 ) Observar la actividad de los procesos


7 ) Observar la actividad de red


8 ) Tomar el segundo shot de las herramientas del paso 4


9 ) Comparar resultados


10 ) Analizar resultados

- En el paso 6, la actividad de procesos muestra que a partir del proceso "notepad.exe" troyanizado se levanta el proceso "calc.exe".

- En el paso 7, el proceso troyanizado abre el "puerto local 50500" en modo escucha, lo cual es un indicio de "Backdoor" (puerta trasera).

- En el paso 9, la actividad en el sistema de archivos fue la creación de una carpeta y un archivo con extensión "txt". En cuanto a las DLLs, se aprecia que el archivo "malicious.dll" se inyectó correctamente en el proceso "notepad.exe" y también se muestra la DLL "netcfgx.dll" cargada por el proceso "svchost.exe", la cual tiene como descripción Network Configuration Objects (objetos de configuración de red), que involucra protocolos de red y es compartida por varias aplicaciones de Windows.

Finalmente, una forma de verificar si el puerto local 50500, que fue abierto en modo escucha, tiene un shell asociado, es utilizando desde otro equipo el comando "telnet". A continuación se muestra la obtención del "cmd" de Windows:


Se establece una conexión de red al puerto 50500 desde un equipo Linux y otra instancia del proceso troyanizado se queda en modo escucha:


Fuente: malware.unam

Saludos

Buenas a todos!!!!

Tengo una aplicación desarrollada en Django, que utiliza una bd para controlar usuarios y una conjunto de información sobre un tema determinado.
Que consideraciones "básicas" de hardware tendría que tener para la máquina en la que se aloje?
Puse "básicas" porque se que depende también de las visitas que vaya a tener y demás, pero me gustaría saber si tengo que tener alguna consideración especial al ser Django.

Saludos

buenisimo, ahi lo agregue al indice.

Saludos

Buenisimo Alejandro9999, ser de gran ayuda.

Saludos

PyMerc es una aplicación que busca equipos en la red utilizando la API de nmap (python-nmap) para Python realizando un barrido ping. Una vez encuentra equipos los almacena en una base de datos sqlite que permite su futura edición para asignar nombres a cada equipo encontrado en función de su MAC.
Con los datos almacenados estos pueden ser mostrados por la terminal o bien lanzar un servidor web con el framework Bottle para ver los resultados desde el navegador.

Capturas:


Descargar: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
Fuente: 0verl0ad

Saludos

 A estas alturas todos sabemos que la plataforma Android es un auténtico caldo de cultivo para el malware por diversos motivos:

• Escasos controles en el momento de la publicación de aplicaciones en Google Play
• Ventanas de tiempo entre publicación de malware y su eliminación que permiten obtener un beneficio de estas actividades ilícitas
• Facilidad de distribución de aplicaciones a través de métodos alternativos a los canales oficiales
• Necesidad de una mayor granularidad en los permisos
• Un muy largo etcétera...

Pero de esta situación también podemos sacar algo positivo, donde reina el malware nosotros tenemos campo donde investigar, así que vamos a dedicar unas líneas a construir un entorno de análisis para jugar con el malware además de con todo tipo de aplicaciones Android.

Descripción del entorno

Con la idea de tener controlado el comportamiento de la aplicación a analizar vamos a crear un entorno repetible (a través de backups), en un dispositivo sobre el que tengamos pleno control (debe estar rooteado) y enrutando las comunicaciones que genere por una máquina que nos permita su análisis (utilizando iptables, wireshark y burp).

De forma gráfica el escenario que vamos a recrear es el siguiente:


Y para crear este entorno partiremos de los siguiente pre-requisitos:

• Tener un dispositivo rooteado donde hacer las pruebas (tenéis más documentación en los foros xda-developers en inglés y htcmania en español), y aunque estoy seguro de que esto sobra decirlo, si lo vais a utilizar para el análisis de malware no utilicéis vuestros dispositivo de uso diario.
• Instalación del Android SDK (tenéis más documentación en la Web oficial de Android ).
• Red Wifi a la que conectar el dispositivo.
• Disponer de una máquina con iptables, Wireshark y Burp instalados. En el ejemplo usaré una distribución Kali.

Empecemos con la configuración del entorno.

Preparando la distribución Kali

Como vamos a enrutar el tráfico del dispositivo a la máquina Kali, lo primero será configurarla:

• Iniciamos y configuramos Burp
• En Proxy > Options, editamos el Proxy que está escuchando para que atienda a todas las interfaces:

• Actúe de forma invisible:

• Genere un certificado de CA por host:

• Exportamos el certificado de la CA de Burp codificado en DER, para ello podemos configurar el cliente Web de Kali para que pase por el proxy y acceder a una página Web por HTTPS:

• Configuramos las reglas de pre-routing con iptables que nos permitirán analizar el tráfico HTTP/HTTPS en Burp:
• echo 1 > /proc/sys/net/ipv4/ip_forward
• iptables -F
• iptables -t nat -F
• iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
• iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8080
• Iniciamos Wireshark y le ponemos a la escucha en la interfaz de red por la que entre el tráfico del dispositivo

En este momento ya tenemos preparado el entorno de la máquina Kali, continuemos con el dispositivo.

Preparando el dispositivo Android

Antes de realizar el backup, vamos a hacer algunos ajustes previos en el dispositivo Android:

• Instalamos la aplicación ProxyDroid para enrutar correctamente el tráfico HTTPS a nuestra máquina de análisis de comunicaciones y la configuramos del siguiente modo:

• Importamos el certificado de la CA que habíamos exportado desde Burp, para ello lo copiamos a la SD (o memoria interna del dispositivo) y accedemos a Ajustes > Seguridad > Almacenamiento de credenciales > Instalar desde la tarjeta SD (o alamcenamiento). Tener en cuenta que estas opciones de menú pueden variar según la versión instalada de Android.
• Configuramos la Wifi en el dispositivo y establecemos como puerta de enlace la dirección IP de la máquina Kali

Con esto ya tenemos el dispositivo listo para su castigo, así que vamos a realizar un backup que poder restaurar finalizados nuestros análisis. Tenemos las siguientes opciones:

• Nandroid, os dejo un No tienes permitido ver los links. Registrarse o Entrar a mi cuenta a un tutorial.
• Herramienta adb del Android SDK:
• Para hacer backup:   adb backup -apk -shared -all -system -f C:\estado0.ab
• Para hacer restore:    adb restore C:\estado0.ab

Ya tenemos preparada la máquina Kali para capturar el tráfico y el entorno sobre el que vamos a realizar las pruebas, de modo que sólo queda activar la aplicación ProxyDroid en el dispositivo:


Y empezaremos a capturar el tráfico del dispositivo en el Wireshark y Burp de la máquina Kali:


Algunas herramientas útiles

Encontraréis de gran utilidad para la realización del análisis las siguientes herramientas:

• adb (incluida en el Android SDK)
• dex2jar
• jd-gui
• apk toolkit

Virtualizando el laboratorario

Si no disponéis de un dispositivo físico donde probar esta será vuestra mejor opción, pero incluso teniéndolo merece la pena virtualizar el laboratorio ya que os permitirá una mayor agilidad en la restauración del sistema además de facilitaros obtener el root.

Recuerdo los pasos para crear la máquina virtual y os dejo algunas indicaciones adicionales:

• Instalación y configuración de VM Android 4.3 x86 en VirtualBox:

• Rooteo completo de la VM: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta.
• Instalar una herramienta para la gestión de la ejecución con privilegios de root, por ejemplo SuperSU
• Instalar y configurar ProxyDroid y el certificado de Burp como se describía anteriormente
• Instalar un servidor FTP en la máquina Kali de análisis, por ejemplo vsftpd
• Instalar un cliente FTP en el dispositivo virtual, por ejemplo AndFTP. Configurar un perfil con el servidor de la máquina de análisis
• Crearemos una carpeta para el contenido de nuestros análisis en la SD, para ello accedemos a la terminal presionando ALT+F1 y hacemos un mkdir /sdcard/analisis
• Apagar la VM del dispositivo Android y guardar una instantánea que poder restaurar finalizado el análisis.

Finalmente utilizaremos Kali como máquina de análisis de comunicaciones y de la aplicación en sí.

Os dejo algunos trucos interesantes para manejarnos con el entorno virtualizado:

• Para controlar correctamente el ratón dentro de la VM seleccionar la opción Máquina > Inhabilitar integración del ratón
• Podéis acceder a la terminal con ALT+F1. En este modo echaréis en falta más de un símbolo, aquí tenéis el juego que utiliza.
• Podéis volver a la interfaz gráfica con ALT+F7
• Si analizáis una aplicación que gire la pantalla y cuando volváis a acceder a la HOME no se recupera la vista en horizontal, presionar 2 veces seguidas F9

• Si se queda la pantalla en negro (se ha bloqueado el dispositivo), seleccionar la opción Máquina > Apagado ACPI y se desbloqueará:

Recogiendo información

El primer paso es arrancar en la máquina Kali las aplicaciones Wireshark y Burp para inspeccionar las comunicaciones. También activamos ProxyDroid en el dispositivo virtual.

Lo siguiente que vamos a hacer es crear en el dispositivo un fichero que nos sirva de hito histórico para detectar más adelante variaciones con el comando find, de modo que presionamos ALT+F1 y escribimos touch /sdcard/analisis/instante.

Para continuar con el artículo he escogido la aplicación SMS, whatsapp, LLAMADA - SPY a la cual sólo le falta auto-declararse troyano:


Instalamos e iniciamos la aplicación. Si seguimos el proceso que indica nos pedirá que habilitemos la instalación desde orígenes desconocidos. Vemos que la cosa se anima en cuanto nos refleja todos los permisos que pide el segundo APK que quiere descargar:


Como estamos dentro de la VM podemos aceptar sin miedo, y si continuamos con el proceso que propone llegaremos a un punto en el que nos pide la dirección de correo sobre la que queremos vincular la actividad espía..., proceso que indica siempre que no hay conexión a internet, aunque sí que la haya. Sospechoso, ¿verdad?.

Finalizado el proceso anterior reiniciamos el dispositivo (para que se agarre bien el troyano) y seguimos nuestra tarea de recogida de información lanzando algunos comandos desde la terminal, para ello presionamos ALT+F1 y obtenemos algunos datos:


En resumen:

• Obtenemos el APK y todos los datos de la aplicación para analizarlos
• Obtenemos todos los ficheros modificados a partir de la fecha de creación del fichero creado antes de iniciar el análisis
• Obtenemos los procesos y conexiones activas del dispositivo

De vuelta al entorno gráfico (ALT+F7) podemos utilizar AndFTP para enviar toda la información recogida en el directorio /sdcard/analisis a la máquina Kali donde podremos analizarla con más detalle.


Además desde Burp podremos ver que la aplicación ha generado dos peticiones al dominio No tienes permitido ver los links. Registrarse o Entrar a mi cuenta:


Y desde Wireshark con File > Export objects > HTTP podremos exportar el APK descargado para su posterior análisis:


Analizando la información recuperada

Al final de la entrega anterior recuperamos cierta información que nos puede ser útil durante el resto del análisis, por ejemplo si revisamos el listado de procesos que realizamos al reiniciar el sistema tras instalar la aplicación nos encontraremos con que una nueva aplicación se ha iniciado automáticamente:


Por otro lado y a través de los ficheros modificados podemos ver los APKs instalados y como se ha descargado en la SD un paquete light.apk:


Si generamos un resumen con MD5 a los paquetes de spy2mobile y light veremos que se tratan del mismo fichero:


Y como vimos en las trazas de las comunicaciones del artículo anterior podemos deducir el proceso que ha seguido el troyano: a través de la aplicación com.supportcaptcha se realizó la descarga en la SD del paquete light.apk, que posteriormente se instaló bajo el nombre com.spy2mobile.light y el cual se inicia con el arranque del dispositivo.

Pero continuemos obteniendo información con otras herramientas.

apktoolkit

Nos sirve para extraer los recursos de la aplicación. Para usarla es necesario copiar el APK que queremos analizar en el directorio /usr/share/apktoolkit/, en nuestro caso vamos a centrarnos en el troyano que se descargó vía Internet una vez instalada la aplicación:


El resultado de esta aplicación nos permitirá inspeccionar el código smali (código ensamblador para el formato dex) sobre el que podremos localizar comportamientos anómalos a través de comandos en el sistema:



Además utilizando el explorador del sistema de ficheros podremos revisar los recursos recuperados del APK donde encontraremos las imágenes, definición de pantallas, textos, ficheros incluidos en la aplicación


Dentro de los recursos que encontraremos cabe destacar el fichero AndroidManifest.xml. donde se definen versiones, permisos, servicios, actividades... información esencial para que Android tenga conocimiento de cuándo y cómo ejecutar los componentes de la aplicación.
En el caso de la aplicación que estamos analizando podemos ver como nos hacen un all-in de permisos:


En ese mismo fichero también se reflejarán los broadcast receivers:


Como podemos ver la aplicación se declara a la escucha de llamadas salientes y del arranque del dispositivo. Cualquiera de estas dos acciones desencadenará que la clase com.source.MainReceiver gestione el evento, dato que en términos del arranque ya habíamos identificar al listar los procesos al inicio del sistema.

Herramientas d2j

Esta herramienta se utiliza de forma habitual para convertir un fichero en formato dex (los APK) en un fichero en formato jar:


Una vez realizado el paso anterior es posible decompilar el contenido del jar con las herramientas jd-gui o jad.
Es interesante comentar también que este conjunto de herramientas dispone de otras utilidades que nos permitirán:

- Modificar el contenido de un APK a través de código Jasmin.
No profundizo en esta opción ya que se escapa del objetivo del artículo, aunque podéis imaginar el uso de esta herramienta para modificar aplicaciones y publicarlas en mercados alternativos.

- Des-ofuscar código bajo un criterio establecido de forma manual.
Vamos a ver esta opción más en detalle. Primero abrimos el fichero jar generado con jd-gui:


Si exploramos las clases encontraremos que el código que nos interesa se encuentra ofuscado:


El siguiente paso será extraer los nombres de paquetes, clases, métodos y atributos para editarlos:


Modificamos su contenido para hacerlo más legible (aunque con sólo extraerlos se generarán nombres aleatorios que serán algo más sencillos de identificar que los ofuscados):



A continuación insertaremos estos nombres dentro del fichero jar y volveremos a abrirlo desde jd-gui:


El resultado que veremos será el siguiente:


sqlitebrowser

Con esta herramienta podremos ver de forma gráfica las bases de datos de tipo SQLite, de modo que lo primero que haremos será instalar el paquete en la máquina de análisis con:

apt-get install sqlitebrowser

Una vez instalada la herramienta la encontraremos en Applications > Programming > SQLite Database Browser.
El siguiente paso es disponer de la base de datos que queremos analizar, de modo que continuando con el ejemplo que teníamos entre manos vamos a intentar localizar su base de datos.

En Android lo habitual es que para gestionar las bases de datos se cree una clase que herede de la clase SQLiteOpenHelper, de modo que vamos a intentar localizar esta cadena en el código:


Tenemos una clase ganadora: com.source.b.f. Esta misma búsqueda la podemos realizar desde jd-gui para ver el código de forma más clara:


Si curioseamos esa clase nos encontraremos el siguiente método:


De modo que todo apunta a que tendremos una base de datos con nombre No tienes permitido ver los links. Registrarse o Entrar a mi cuenta, la descargamos desde su directorio por defecto (/data/data/com.spy2mobile.light/databases/) y la abrimos con sqlitebrowser:


Y aunque ya sabíamos desde el principio que estábamos analizando una aplicación para espiar el uso del dispositivo, confirmamos a través de la base de datos las múltiples tablas preparadas para capturar la información del usuario.

Conclusiones

Como veis tenemos a nuestro alcance múltiples herramientas que nos permitirán transformar la aplicación para que la podamos analizar desde distintas perspectivas, haciendo que los resultados del proceso de análisis se reduzcan a una cuestión de habilidad, experiencia y el tiempo que le queramos/podamos dedicar.

Finalmente os dejo una captura de la pinta que tiene el panel de administración Web del software espía que al final he podido configurar desde un dispositivo físico:


Artículo cortesía de Miguel Ángel García
Fuente: securitybydefault

Saludos

DEFT es una distribución Live CD muy fácil de usar, con un grandísimo listado de herramientas forenses y con una excelente detección del hardware.
No se enfoca únicamente al típico análisis forense de discos duros, si no que ofrece la posibilidad también de realizar forenses de red e incluso de dispositivos móviles.

Dentro del menú principal de la distribución, nos encontramos las siguientes categorías de herramientas incluidas:

• Analysis - Herramientas de análisis de ficheros de diferentes tipos
• Antimalware - Búsqueda de rootkits, virus, malware, así como PDFs con código malicioso.
• Data recovery - Software para recuperación de ficheros
• Hashing - Scripts que permiten la realización de cálculo de hashes de determinados procesos (SHA1, SHA256, MD5...)
• Imaging - Aplicaciones que podemos utilizar para realizar los clonados y adquisición de imágenes de discos duros u otras fuentes.
• Mobile Forensics - Análisis de Blackberry, Android, iPhone, así como información sobre las típicas bases de datos de dispositivos móviles en SQLite utilizadas por las aplicaciones.
• Network Forensics - Herramientas para procesamiento de información almacenada en capturas de red
• OSINT - Aplicaciones que facilitan la obtención de información asociada a usuarios y su actividad.
• Password recovery - Recuperación de contraseñas de BIOS, ficheros comprimidos, ofimáticos, fuerza bruta, etc.
• Reporting tools - Por último, dentro de esta sección encontraremos herramientas que nos facilitarán las tareas de generación de informes y obtención de evidencias que nos servirán para documentar el análisis forense. Captura de pantalla, recopilación de notas, registro de actividad del escritorio, etc.

Web Oficial: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
Descarga: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Saludos

Eres un trabajador más del ámbito de la seguridad informática. Acabas de despertarte un domingo por la mañana y has sido alertado de un incidente de seguridad. Te diriges a la oficina para averiguar lo que ha sucedido. Empezarás a mirar el incidente en los paneles de alrededor. El IPS/IDS y las alertas WAF muestran que ha habido una aplicación o malware no deseada en el sistema. La lista de conexiones del firewall te muestra que uno de los hosts tiene conexiones inusuales hacia fuera de la red. Y por último, el antivirus muestra información sobre este host infectado. Después de estas pequeñas comprobaciones iniciales y de suponer que efectivamente tienes un bicho, lo que queda por hacer es averiguar qué tipo de malware hay en el host en cuestión y cuán malicioso es su código. Por supuesto, hay que ordenar al equipo de red y antivirus que realicen una evaluación de los daños inmediatos de la red, mientras se escanea el host infectado en un entorno aislado. ¡No está mal para un domingo por la mañana! Volverás a casa pensando que el incidente está bajo control.


¿Qué podemos hacer para proteger nuestros activos de red, recursos de red, y lo más importante, nuestros datos? Como medidas preventivas, se puede empezar por actualizar el hash de IDS para detectar el siguiente ataque de software malintencionado similar y actualizar la base de firmas del antivirus para detectarlo a nivel de host. Aparte de estas medidas, todavía tenemos que obtener más información acerca de este software malicioso, o en otras palabras, es necesario llevar a cabo un análisis de malware para averiguar el comportamiento exacto de esta pequeña y desagradable pieza de software.

¿Qué es un malware?

En primer lugar, ¿qué es un malware? ¿Podemos considerar cualquier pieza de código que no está autorizado a estar en nuestra red como un software malicioso? De forma general, podemos decir que un malware es una pieza de software capaz de realizar cualquier acción que causa algún tipo de daño a un usuario u organización, un equipo, o una red. Esto incluye pero no se limita a los virus, troyanos, gusanos, rootkits, scareware y spyware.

Si se determina que la pieza de software encontrada es perjudicial, un análisis de malware es el arte de la disección del software malicioso para entender cómo funciona, cómo identificarlo y cómo derrotarlo o eliminarlo.

Uno de los propósitos y objetivos del análisis de malware suele ser el poder proporcionar la información necesaria para responder a una intrusión en la red. Este propósito incluye el determinar exactamente lo que sucedió, y qué alcance y grado de disperesión tuvo en la red.

Al analizar los supuestos elementos de software malicioso, en primer lugar se necesita explorar lo que el archivo binario sospechoso puede hacer, cómo detectarlo en su red, y cómo medir y contener el daño. En el post de hoy hablaremos de un caso práctico con un virus educativo, el RaDa, al cual someteremos a una serie de pruebas que revelarán parte de sus intenciones.

Análisis de Malware

Configuración del entorno de laboratorio

En primer lugar, si no se dispone de un entorno de laboratorio adecuado para llevar a cabo un análisis de malware, es posible que se deban volver a examinar las opciones que se tienen, para alinear lo mejor posible los recursos disponibles con la eficacia del análisis. Como ejemplo, se puede utilizar un entorno virtual para realizar el análisis o tener sistemas físicos separados. A diferencia de los entornos virtuales, los datos pueden tener fugas en el sistema base y esto puede eventualmente perjudicar a todo el sistema. Los malware más modernos son capaces de detectar los sistemas virtuales y cambiar sus comportamientos para permanecer sin ser detectados. De todas las opciones que hemos probado, tanto VMWare como VirtualBox ofrecen buenas soluciones para el análisis de malware. Usaremos VirtualBox para nuestro análisis.

Por otra parte, tener sistemas físicos dedicados puede tener varias desventajas, tales como tener que restaurar el sistema en cada ciclo de análisis. Para ello utilizamos software libre, como la herramienta udpcast disponible para estos fines. En  caso de que tengas suficiente presupuesto, Norton Ghost proporciona características más avanzadas para hacer restauraciones del sistema.

Una vez decidido el entorno en el que se va a trabajar, el siguiente paso sería definir el acceso a la red de esos sistemas. Los malwares avanzados son capaces de detectar cambios en la dirección IP y se esconden o no revelan la información sobre la ubicación real de otros nodos o puntos de control. Estas detecciones pueden desencadenar algunas otras funciones ocultas, tales como ataque DOS al servidor interno. Por lo tanto, recomendamos entornos de red aislados con servidores virtuales que incluyen DNS propios, y servidores HTTP y de correo. En el caso de prueba adicional con conexión a internet, la red aislada puede aplicarse a través de un cortafuegos con reglas estrictas establecidas para supervisar las posibles conexiones abiertas y cerradas.

El conjunto de herramientas

Después de haber decidido y configurado el entorno de laboratorio, el siguiente paso es seleccionar un conjunto de herramientas que faciliten el proceso de análisis. Recomendamos las siguientes herramientas que pueden ser útiles en distintas etapas del ciclo de análisis, aunque hay muchas otras disponibles. Principalmente usaremos herramientas libres o gratuitas, incluidas las versiones demo de algunas herramientas comerciales.

En la siguiente sección se ofrece una breve descripción de cada herramienta que utilizamos para llevar a cabo el análisis.

OllyDbg

OllyDbg es un depurador a nivel de aplicación. La interfaz OllyDbg muestra el código ensamblador, volcado hexadecimal, la pila y registros de la CPU. OllyDbg también soporta rastreo, puntos de interrupción condicionales, visión de cabecera PE, edición hexadecimal, y plug-in de soporte.

En la primera puesta en marcha, OllyDbg pide configurar el directorio de datos del usuario (UDD) y el directorio de plug-ins. UDD se utiliza para guardar información específica de la aplicación como puntos de interrupción. Ofrece amplias opciones de depuración como la configuración de breakpoints en la carga de nuevos módulos, la creación de threads, la forma de procesar las excepciones, etc. OllyDbg soporta el establecimiento de puntos de interrupción de hardware, puntos de interrupción de software, puntos de interrupción de memoria e incluso puntos de interrupción condicionales.

IDA Pro

Al igual que OllyDbg, IDA Pro es un depurador / desensamblador a nivel de aplicación que nos ayudará enormemente en seguir la pista de la ejecución del programa. Cuenta con una versión de demo y una versión freeware más antigua, que es gratuita solo para uso no comercial.

UPX

UPX es un compresor/descompresor de código ejecutable, que logra una excelente relación de compresión y ofrece descompresión muy rápida cuidando el consumo de memoria. Una medida más que utilizan los ejecutables para ocultarse es el almacenar su código comprimido, por lo que necesitaremos una herramienta capaz de extraer el código ejecutable en claro, como UPX.

Autoruns

Esta herramienta, que cuenta con la lista más amplia de ubicaciones de inicio automático, muestra qué programas están configurados para ejecutarse durante el arranque del sistema o de inicio de sesión, y muestra las entradas en el orden en que Windows las procesa. Estos programas incluyen los de su carpeta de inicio, Run, RunOnce, y otras claves del registro. Puede configurar Autoruns para mostrar otras ubicaciones, incluidas las extensiones de shell del Explorador, barras de herramientas, objetos de ayuda del navegador, las notificaciones de Winlogon, servicios de inicio automático, y mucho más. Autoruns extiende por mucho la utilidad MSConfig incluida en Windows Me y XP.

ProcessExplore

ProcessExplore es, como su nombre indica, un explorador de procesos. Su interfaz gráfica se compone de dos subventanas; la superior siempre muestra una lista de los procesos activos, incluidos los nombres de las cuentas que poseen, mientras que la información mostrada en la inferior depende del modo en que Process Explorer esté configurado. En el modo de DLL, mostrará los archivos DLL y archivos asignados en memoria que el proceso ha cargado. Process Explorer también tiene una herramienta de búsqueda muy potente que mostrará rápidamente qué procesos tienen handlers abiertos o sus DLL cargados.

Las capacidades de Process Explorer lo hacen especialmente útil para localizar problemas de DLL – versión o pérdidas de identificadores, y para dar una idea de la forma de funcionar de Windows y otras aplicaciones.

Process Monitor

Process Monitor es una herramienta de monitorización avanzada para Windows que muestra en tiempo real actividad en el sistema de archivos, el registro, y los procesos en ejecución. Combina las características de las herramientas Filemon y Regmon, y añade una amplia lista de mejoras que incluyen el filtrado avanzado y no destructivo, las propiedades de eventos integrales tales como identificadores de sesión y nombres de usuario, pilas de threads completas con soporte para símbolos integrados de cada operación, registro simultáneo en un archivo, y mucho más. Las características de Process Monitor hacen de ella una utilidad fundamental en la solución de problemas del sistema y en el conjunto de instrumentos de caza de malware.

Active Registry Monitor

El Active Registry Monitor (ARM) es una utilidad diseñada para analizar los cambios hechos al registro de Windows – tomando snapshots de su estado y guardándolos en una base de datos. Posteriormente, pueden compararse dos de estas fotografías y obtener un listado de claves/datos nuevos, eliminados o, simplemente, cambiados.

TCPview

TCPView es un programa de Windows que muestra la lista detallada de todos los puntos finales TCP y UDP en el sistema, incluyendo las direcciones y el estado de las conexiones TCP locales y remotas. En Windows Server 2008, Windows Vista y XP, TCPView también informa del nombre del proceso que posee el punto final. TCPView proporciona un subconjunto más informativo y bien presentado del programa Netstat que se incluye con Windows.

WinVi

WinVi es un editor gratuito para MS Windows para la edición y la detección automática de archivos Unicode en codificaciones UTF- 8, UTF-16 Little Endian y UTF-16 Big Endian. WinVi funciona como un editor Vi para Windows. En el análisis de malware se utiliza esta herramienta como un editor hexadecimal que puede soportar archivos de hasta 2 GB.

Técnicas de análisis de malware

Muy a menudo, cuando se realiza el análisis de malware, la única cosa que se tiene es el propio ejecutable malicioso, que no dará demasiada información, ya que está destinado a no ser comprendido por seres humanos. Con la intención de encontrarle sentido, vamos a usar una variedad de herramientas y trucos, cada uno revelando una pequeña cantidad de información.

Habrá que hacer uso de una gran variedad de herramientas con el fin de obtener una comprensión amplia del malware en cuestión. Existen dos enfoques fundamentales para el análisis de malware: los análisis estáticos y los análisis dinámicos. El análisis estático consiste en examinar el malware sin ejecutarlo, mientras que el análisis dinámico implica la ejecución del malware en entornos controlados.

Análisis estático básico

El análisis estático básico consiste en examinar el archivo ejecutable sin ver las instrucciones reales. El análisis estático puede confirmar si un archivo es malicioso, proporciona información sobre su funcionamiento, y a veces ofrece información que permitirá realizar un network footprinting simple. El análisis estático básico es sencillo y puede ser rápido, pero es en gran medida ineficaz contra el malware sofisticado, y se pueden pasar por alto funciones importantes.

Análisis Dinámico Básico

Las técnicas de análisis dinámicas básicas implican ejecutar el malware y la observación de su comportamiento en el sistema con el fin de averiguar algunos aspectos de su comportamiento, poder eliminar la infección, y producir firmas eficaces. Sin embargo, antes de poder ejecutar el malware de forma segura, se debe configurar un entorno que permita estudiar el malware ejecutándose sin riesgo de daño al sistema o la red. Al igual que las técnicas básicas de análisis estático, las técnicas básicas de análisis dinámico pueden ser utilizadas por la mayoría de las personas sin grandes conocimientos de programación, pero no serán eficaces con todo el malware y también se puede pasar por alto funcionalidad importante.

En la Práctica

Mostraremos un ejemplo práctico de cómo realizar un análisis de una pieza de malware para identificar su funcionalidad.

Disclaimer: No se recomienda la realización de este ejercicio en un entorno sin acondicionar debidamente, por el riesgo que puede suponer para todos los equipos de la red.

El virus que vamos a analizar, el virus RaDa, es un virus real creado en el marco del Proyecto Honeynet para aumentar la concienciación sobre la seguridad en torno a ejemplares de malware y para señalar la necesidad de contramedidas defensivas adicionales con el fin de luchar contra las actuales amenazas de malware.

Una vez localizado (o descargado) el ejecutable del malware, y aislado en nuestro entorno de laboratorio, procedemos al análisis del mismo, pasando por cada una de las etapas y usando varios de los software mencionados.

Análisis estático

En el análisis estático de este virus vamos a intentar recabar tanta información como sea posible, que nos ayudará a comprenderlo mejor y a orientar de forma eficiente nuestros esfuerzos en el posterior análsis dinámico.

Como primer paso, se lleva a cabo una recolección de información previa observando los detalles del virus y realizando una visualización en un editor hexadecimal. Esto revela algunas cadenas en el código del virus, además de ayudarnos a verificar que se trata de un ejecutable.


El siguiente paso comienza con cargar el ejecutable (el virus RaDa) en OllyDbg para llevar a cabo un análisis de código con el fin de descubrir sus capacidades funcionales. En primer lugar, abrimos el archivo ejecutable en el OllyDbg para ver los detalles básicos. La siguiente figura muestra cierta información de los registros, la CPU y el estado de la memoria del programa, incluyendo un mensaje de advertencia que indica que el código está comprimido, cifrado o codificado para ocultar su verdadera naturaleza.


Para salvar este paso y poder extraer el ejecutable real y ver sus instrucciones, o al menos obtener información sobre el tipo de compresión, codificación o cifrado lleva (y, en definitiva, averiguar más cosas sobre la naturaleza del virus), se utiliza la utilidad de descompresión de ejecutables UPX:


Tal y como se puede observar en la imagen superior, el virus se resiste a desempaquetarse a través del método común con UPX. Por lo tanto, podemos probar a forzar el proceso usando el comando upx -9 --brute, que puede tardar un buen rato.

Después de un rato no ha habido suerte en el desempaquetamiento, por lo que vamos a moldear un poco el análisis, redireccionando nuestros esfuerzos en cierto modo hacia un análisis de comportamiento del malware, más que un análisis estático, debido a que el virus está preparado para evitar este tipo de análisis. Para este propósito, es necesario realizar una ejecución controlada del virus, analizar sus puntos de inicio, y encontrar un breakpoint del virus.

Para poder localizar dichos puntos, vamos a empezar por analizar el mapa de memoria  del malware, cosa que podemos hacer con el OllyDbg:


El mapa de memoria indica que hay tres secciones en el binario de RaDa: JDR0, JDR1 y .rsrc. El entry point de RaDa.exe (0x0040FD20) está ubicado en la sección JDR1. Podemos echar un vistazo también a la sección JDR0 haciendo doble click sobre la etiqueta de la sección, aunque nos encontraremos en este caso que la sección está vacía:


Podemos obtener algo más de información sobre la sección JDR0 (0x004018A4) usando el IDA Pro:


La siguiente captura de pantalla muestra que el código en JDR1 desempaqueta el código ofuscado que contiene en la sección JDR0. El registro ESI apunta a la dirección del bloque cifrado/ofuscado de código, mientras que el registro EDI apunta a la dirección de memoria a la que será copiada el código una vez se haya desempaquetado. Al terminar la sección JDR1, el control del programa salta a la dirección en que se ha desempaquetado el código (jmp loc_40FD42).


Observando además la información presente en la vista General Register, en el registro EIP, podemos consolidar que la dirección de memoria  JDR1:0040FD20 es el punto de inicio del programa. Dicho esto, aún es necesario extraer un buen String dump del código empaquetado.

Con el OllyDbg podemos obtener cierta información de los (posibles) módulos de los que puede hacer uso el virus, que nos pueden ayudar a comprender la naturaleza del virus más a fondo:


También podemos observar los handles del virus, para un propósito similar:


Recapitulando hasta ahora:

• La información recabada en el análisis estático será de gran ayuda para, a la hora de hacer el análisis dinámico, saber dónde deben ir dirigidos nuestros esfuerzos.
• Los handles del virus nos ayudarán a saber de qué recursos del sistema el ejecutable pretende hacer uso. Todo ejecutable hace uso de algún recursos del sistema; la cuestión aquí está en filtrar qué recursos son potencialmente peligrosos como para que los use un fragmento de software desconocido, y cuáles son más y menos habituales.
• El mapa de memoria del ejecutable nos ha ayudado a determinar breakpoints del virus, que nos puede servir para controlar eficientemente la ejecución del virus en el análisis dinámico.
• La lista de módulos ejecutables del malware nos da una pista (a veces, falsa) de los módulos que puede utilizar el virus.

Reunidas todas estas pistas, hemos preparado el terreno para dirigir nuestro análisis dinámico de la forma más eficiente posible.

El análisis dinámico

Ejecutaremos el virus en un ambiente controlado para ver su capacidad de abrir conexiones con el mundo exterior (calling home), las alteraciones del registro, modificaciones del sistema de archivos y los procesos en ejecución. Para controlar este tipo de actividades se utilizarán los programas TCPView, Active Registry Monitor, Process Explorer, Process Monitor y la aplicación Autoruns.

Al haber localizado en el análisis estático el punto de inicio del programa, podemos controlar su ejecución:



Una vez tenemos el entorno de laboratorio bien preparado y con el virus listo para ser ejecutado, el primer paso es averiguar cómo intenta comunicarse con el exterior: ¿cuáles son los puertos y las conexiones que el virus puede abrir hacia el mundo exterior? El TCPView muestra los detalles de conexiones salientes del malware:


El monitor de procesos y el ARM muestran las claves del registro recién alteradas del sistema local:


Como una observación, podremos ver que el virus se está ejecutando detrás de la aplicación Internet Explorer para ocultarse. La única indicación que podemos ver es que el proceso "IEXPLORE.EXE" está abierto por el virus para conectarse al destino remoto 10.10.10.10 en el puerto 80. También observamos que el proceso parece consumir más y más memoria.


El ProcessExplorer de Sysinternals nos da información relevante del virus en ejecución, pudiendo comprobar los DLL's que carga, y compararlos con lo encontrado en el análisis estático:



Echando un ojo al Advanced Registry Editor, podemos ver los cambios que hace el virus en el registro de Windows:


También observamos los cambios que ha hecho en el sistema de ficheros:
Cambios en el sistema de ficheros introducidos por RaDa


Por último, también podemos ver en el Process Monitor información sobre el proceso RaDa.exe y el IEXPLORE.EXE, en especial, que RaDa ha sido capaz de lanzar el IEXPLORER como NTAUTHORITY\SYSTEM, siendo RaDa ejecutado por un usuario con privilegios reducidos:



Hasta aquí...:

Después de realizado los análisis estático y dinámico, se han podido comprobar varias cosas:

El virus intenta ocultar su código ejecutable empaquetándolo, así como su punto de inicio. Hay virus más sofisticados que lo ponen mucho más complicado, con decenas de secciones de código distintas.

El programa Active Registry Monitor nos indica que se ha creado la siguiente clave del registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\RaDa:C:\RaDa\bin\RaDa.exe. Esto permite que RaDa persista tras el reinicio del sistema.

El TCPView muestra que hubo intentos de conexión desde iexplore.exe, Internet Explorer, a 10.10.10.10:80. Parece que RaDa utiliza Internet Explorer como herramienta para conectarse con el sistema externo, y que además, es capaz de lanzarlo como el usuario NTAUTHORITY\SYSTEM.

A través del Process Monitor se ha podido comprobar que se crearon los directorios C:\RaDa, C:\RaDa\tmp y C:\RaDa\bin. El ejecutable RaDa.exe se ha copiado en el directorio C:\RaDa\bin\.

El panel de Process Explorer muestra el proceso RaDa.exe en su lista activa, (no oculto bajo otro ejecutable), mostrando el crecimiento de la memoria usada.

Este breve análisis supone solo una introducción al análisis de malware, sin entrar mucho en detalle en los aspectos más técnicos. Seguiremos publicando artículos que poco a poco irán entrando más a fondo, desmenuzando a todos los niveles las técnicas del análisis de malware más comunes, con ejemplos prácticos para poder experimentar con conocimiento y aprender cosas interesantes de este área de la seguridad informática.

Fuente: hard2bit

Saludos

Bienvenido mrt694!!!!
Siéntete cómodo y ante cualquier cosa no dudes en preguntar.

Saludos

1.- Evitar la creación innecesaria de objetos, Lazy Initialitation

La creación de objetos en Java es una de las operaciones mas costosas en términos de uso de memoria e impacto en el performance.  Esto es evitable creando o inicializando objetos solo en el momento en que serán requeridos en el código.

public class Paises {

    private List paises;

    public List getPaises() {
        //se inicializa solo cuando es requerido
        if(null == paises) {
            paises = new ArrayList();
        }
        return paises;
    }
}

2.- Nunca hacer variables de instancia públicas

Hacer una clase publica se puede ocasionar problemas en un programa.  Por ejemplo si tienes una clase MiCalendario. Esta clase contiene un arreglo de cadenas diasDeLaSemana.  Pero es una arreglo público y este puede ser accedido por cualquiera.  Tu asumes que este arreglo contiene siempre los 7 nombres de los días de la semana.  Alguien por error puede cambiar el valor e insertar un error!

public class MiCalendario {
   
    public String[] diasDeLaSemana =
        {"Domingo", "Lunes", "Martes", "Miércoles", "Jueves", "Viernes", "Sábado"};
   
    //mas código
   
}

La mejor práctica es como mucho de ustedes saben, es siempre definir estas variables como privadas y crear los métodos accesores, "setters" y "getters"

private String[] diasDeLaSemana =
    {"Domingo", "Lunes", "Martes", "Miercoles", "Jueves", "Sabado", "Domingo"};

public String[] getDiasDeLaSemana() {
    return diasDeLaSemana;
}

Pero escribir los métodos accesores no resuelve el problema del todo.  El arreglo sigue siendo accesible.  La mejor forma de hacerlo inmodificable es devolviendo un arreglo clonado en lugar del arreglo mismo.  Esto se logra modificando el método get de la siguiente forma.

public String[] getDiasDeLaSemana() {
    return diasDeLaSemana.clone();
}

3.- Tratar siempre de minimizar la Mutabilidad de las clases

Hacer una clase inmutable es hacerla inmodificable.   La información de la clase se preservara durante el tiempo de vida de la clase.  Las clases inmutables son simples y fáciles de manejar.  Son "thread safe".  Normalmente son los bloques para formar otros objetos mas grandes.

No obstante, crear objetos inmutables pueden golpear significativamente el rendimiento de una aplicación.  Así que elije cuidadosamente si quieres que una clase sea o no inmutable.  Trata siempre de tener clases pequeñas con el menor número de clases inmutables.

Para hacer una clase inmutable puedes definir sus constructor de forma privada y luego crear un método estático para inicializar al objeto y devolverlo.

public class Empleado {

    private String primerNombre;
    private String segundoNombre;
   
    // constructor private default
    private Empleado (String primerNombre, String segundoNombre) {
        this. primerNombre = primerNombre;
        this. segundoNombre = segundoNombre;
    }
   
    public static Empleado valueOf (String primerNombre, String segundoNombre) {
        return new Empleado (primerNombre, segundoNombre);
    }
}

4.- Trata de usar mas las Interfaces sobre las Clases Abstractas

No es posible la herencia múltiple en Java, pero definitivamente puedes implementar múltiples interfaces.  Esto hace que cambiar la implementación de una clase existente sea fácil y que puedas implementar una o mas interfaces en lugar de cambiar la jerarquía completa de clases.

Pero si tu estás cien por ciento seguro de que métodos de una interface tendrás, entonces solo implementa esa interfaz.   Es bastante difícil agregar un nuevo método en una interfaz existente sin alterar todo el código que se está implementando.  Por el contrario un nuevo método puede ser fácilmente agregado en una clase abstracta sin alterar la funcionalidad existente.

5.- Limita siempre el alcance de una variable local

Las variables locales son grandiosas.  Pero algunas veces pueden insertar mas bugs durante el copiado y pegado de código viejo. Minimizar el alcance de una variable local hace que el código sea mas legible, menos propenso a errores  y mas mantenible.

Por lo tanto, debemos declarar variables justo antes de ser usadas.

Procura inicializar una variable desde su declaración.  Si eso no es posible asígnale el valor nulo.

6- Trata de usar librerías estándar en lugar de hacer las tuyas desde cero.

Escribir código es divertido.  Pero no reinventes la rueda.  Es bastante recomendable usar librerías estándar que ya han sido probadas, debugeadas y usadas por otros.    Esto no solo mejora la eficiencia de un programador sino que redice las posibilidades de tener errores en el código.  Además, usar una librería estándar  hace al código mas legible y mantenible.

Por ejemplo Google tiene liberada la nueva librería Google Collections que puede ser usada para agregar mas funcionalidad a tu código.

7.- Siempre que sea posible trata de usar tipos primitivos en lugar de las clases Wrapper

Las clases Wrapper son buenas, pero también son lentas.  Los tipos primitivos son como clases, sin embargo las clases wrapper almacenan la información completa acerca de una clase.

Algunas veces un programador puede agregar un error en el código usando una wrapper por un descuido.  Por ejemplo:

int x = 10;
int y = 10;

Integer x1 = new Integer(10);
Integer y1 = new Integer(10);

System.out.println(x == y);
System.out.println(x1 == y1);

El primer System.out.println imprimirá true mientras que el segundo imprimirá false.  El problema cuando comparas dos clases wrapper es que no se puede usar el operador ==, por que en realidad se están comparando referencias y no sus valores actuales.

Además si estás usando una clase wrapper no debes olvidar inicializarla.  Porque el valor por default de las variables wrapper es null.

Boolean bandera = null;
     
        //mas código

if(flag == true) {
    System.out.println("Se establece el valor de bandera ");
} else {
    System.out.println("No se establece el valor de bandera");
}

El código lanzará un NullPointerException cuando se trate de comparar con true y el valor sea nulo si en el código intermedio no fue inicializada.

8.- Usa los Strings con mucho cuidado.

Usa siempre las cadenas con mucho cuidado en tu código.  Una simple concatenación de cadenas puede reducir el rendimiento de tu programa.  Por ejemplo si queremos concatenar cadenas usando el operador "+" en un ciclo for entonces todo el tiempo se estará creando un objeto String.  Esto afecta tanto a la memoria como al rendimiento.

Además en lugar de que instancies una objeto String no uses su constructor, sino que debes instanciarlo directamente. Por ejemplo:

//instanciación lenta
String lenta = new String("solo otro objeto string");

//instanciación rápida
String rapida = "solo otro objeto string";

9.- Siempre regresa colecciones vacías en lugar de nulas

No importa que tu método regrese una colección o un arreglo, siempre asegúrate de que cuando sea necesario se regrese vacío y no nulo, en aquellos casos en los que no contendrá elementos porque la lógica de tu programa lo requiera.  Esto te ahorrará un montón de tiempo cuando hagas pruebas para valores nulos.

10.- El copiado defensivo es salvador

El copiado defensivo hace que los objetos creados estén libres de la mutación.  Por ejemplo en el código siguiente tenemos definida la clase Estudiante la cual a su vez tiene una variable con la fecha de nacimiento que es inicializada cuando el objeto es construido.

public class Estudiante {
    private Date fechaNacimiento;
   
    public Estudiante(fechaNacimiento) {
        this. fechaNacimiento = fechaNacimiento;
    }
   
    public Date getFechaNacimiento () {
        return this.fechaNacimiento;
    }
}

Ahora podríamos tener el siguiente código que use al objeto Estudiante.

public static void main(String []arg) {
    Date fechaNacimiento = new Date();    
    Estudiante estudiante = new Student(fechaNacimiento);
    fechaNacimiento.setYear(2019);
    System.out.println(estudiante.getFechaNacimiento ());
}

En el código siguiente creamos tan solo al objeto Estudiante con algunas fechas de nacimiento por default.  Pero entonces cambiamos el valor de el año de nacimiento.  Después imprimimos el año de nacimiento, este año fue cambiado por 2019!

Para evitar estos casos, se puede utilizar el mecanismo defensivo copias. Cambie el constructor de la clase del estudiante a lo siguiente.

public Estudiante(fechaNacimiento) {
    this.fechaNacimiento = new Date(fechaNacimiento);
}

Esto para asegurarnos de tener otra copia de la fecha de nacimiento que usamos en clase Estudiante.

11.-  Nunca dejes salir una excepción de un bloque finally

12.- Nunca lances "Exception" directamente.

Fuente: decodigo

Saludos

Bienvenido a Underc0de!!!
Esperamos verte seguido y que puedas aprender como ver tus conocimientos

Saludos

La verdad que muy bueno Stuxnet.

Espero en alguna ocasión poder asistir.

Saludos

Indice:

Php y el manejo de objetos en memoria
Php: Hacking, Debugging o simplemente diversión
Software libre y la diferencia con el software privativo desde una óptica intrínsecamente profesional y no política
La orientación a objetos y sus enfoques como estilo y paradigma

Descarga: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Fuente: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Saludos

Dentro de los lenguajes utilizados para programar códigos maliciosos encontramos AutoIt, veamos como podemos llegar a analizar este tipo de amenazas ya que en los últimos meses hemos detectado varias muestras de malware desarrolladas en este lenguaje alojadas en servidores vulnerados de Latinoamérica.

La muestra sobre la cual vamos a realizar el análisis corresponde a una campaña de propagación que buscaba afectar usuarios brasileños, a través de un correo electrónico que simulaba ser un comprobante de depósito en formato PDF.


Lo que realmente descarga este correo electrónico es un archivo ejecutable que si un usuario desprevenido lo descarga y ejecutra en su computadora, a pesar que durante unos segundos no ocurrirá nada sobre la máquina, después empezamos a ver que se genera tráfico de red.


Vemos que la muestra establece una comunicación con un servidor, intercambiando paquetes TCP. Además al principio de la comunicación luego de la ejecución la muestra envía cierta información del sistema.

Además del análisis dinámico podemos tratar de entender como fue construido este código malicioso. Para ello podemos analizar las propiedades del archivo ejecutable descargado que dice ser un complemento de Java.


Cuando tratamos de hacer análisis estático sobre muestras de malware se suele recurrir a herramientas de debugging. Para el caso de las muestras que han sido compilados desde AutoIt podemos utilizar un desensamblador para llegar hasta el script y lograr que el análisis sea más sencillo. Para lograrlo utilizamos Exe2Aut una herramienta que nos sirve como decompilador.


Después de hacer la decompilación nos encontramos con un código ofuscado. Lo único entendible a simple vista son las 7 pausas pausas de 3000 milisegundos al principio del código, lo cual explica la demora en la ejecución de esta muestra. El resto del código se convierte en un dolor de cabeza al momento de analizarlo.

Sin embargo, si miramos por un momento el código podemos darnos cuenta que hay una función que se repite en todo el script y que como argumento tiene cadenas de caracteres ilegibles.


Si vamos a buscar esta función dentro del script, nos encontramos con una función que realiza una serie de operaciones sobre su argumento.


Lo que se puede entender de esta función es que va recorriendo la cadena de caracteres que se ingresa y hace unas transformaciones de forma iterativa para obtener la cadena de caracteres con la información que podemos entender.


Si vamos siguiendo la ejecución del script, nos podemos dar cuenta de los valores reales que toman las variables definidas dentro del código una vez que han sido desofuscadas.


Podríamos separar solamente esta función para desofuscar las diferentes cadenas de caracteres y lograr entender lo que está modificando este código malicioso en nuestro sistema.


Una vez que logramos desofuscar muchas de las cadenas podemos a llegar entender cuales son los archivos que modifica e incluso las variables con la información del sistema que envía.


Una de las cuestiones importantes para analizar las muestras desarrolladas en AutoIt es que desde el Laboratorio de ESET Latinoamérica hemos encontrado variantes de la familia Win32/Injector.Autoit en servidores de sitios latinoaméricanos, haciéndose pasar por actualizaciones de Adobe Flash, herramientas para pagar impuestos entre otras técnicas de ingeniería social. La recomendación es para que nuestros usuarios tengan instalada una solución de seguridad en sus dispositivos y eviten ser infectados con códigos maliciosos que roben información del sistema.

Autor: Camilo Gutiérrez Amaya, ESET

Saludos

Puedes hacer como te dice ZanGetsu, desde source. Pero esto significaría que tienes que programar tu propio crypter.

Y de binario mirate todos los tutoriales que encuentres como para entender o ver que se puede hacer. Primero que nada aprendete a como localizar firmas. Descargate un Offset Locator y aprende avfuck, dsplit, 256 combinaciones, etc.

Ya luego es practicar y practicar e ir aprendiendo tips propios.

Saludos

Lista de reproducción sobre arduino

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Fuente: codigofacilito

Saludos