Este articulo también se encuentra en wiki.elhacker.net,

---

Introducción

Encontrar información sobre el desarrollo de drivers no siempre es tarea fácil, sin importar el sistema operativo del cual estemos hablando.
Normalmente, lo ideal para entender este tipo de temas correctamente es leer libros especializados en el tema u ir directamente a las fuentes. Suele ser lo correcto ya que el tema es complejo, largo y puede volverse pesado para quien se apure en entender todos los conceptos implicados.

Por ahora, esto no sera mas que una introducción, por lo tanto tratare que sea breve. Es solo un intento de dar una perspectiva general sobre este tema y con esto lograr que mas gente decida a interiorizarse en el, con suerte mas adelante podremos ver técnicas y/o conceptos mas avanzados y que la mayoría los entiendan.

---

subsystem, ¿que es?

Es ideal conocer a fondo las herramientas que estamos utilizando, y con esto no solo me refiero al lenguaje, si no tambien al entorno de trabajo que utilicemos.

El proceso de compilado y linkeado genera un binario adecuado para que el sistema operativo en el cual estemos pueda comprenderlo. En Windows, este formato es lo que varios conocen como PE (Portable Executable Format)
Alrededor de PE, tenemos un concepto llamado subsystem. Un subsystem, entre otras opciones incluidas en la información del header PE, describe como cargar un ejecutable que también incluye el punto de entrada (Entry Point) en el binario.

---

Conociendo tus herramientas.

Posiblemente muchos recién se enteran lo que es un subsystem, y esto se debe a que generalmente en la etapa de aprendizaje de lenguajes como C/C++, uno puede simplemente descargar un IDE y ponerse a trabajar. Los errores no causan tantos problemas cuando todavía no salimos del modo usuario.

Por ejemplo, las personas que utilizan Visual C++, habrán hecho ya alguna aplicacion en consola u alguna aplicacion para Windows. Al crear el proyecto, el subsystem viene predefinido, tal como /SUBSYSTEM:CONSOLE o /SUBSYSTEM:WINDOWS.

La novedad en todo esto, es que un driver es linkeado con otro tipo de subsystem, llamado NATIVE.

MSDN /SUBSYSTEM

---

Los drivers también tienen un "main".

Por supuesto, los drivers también tienen un main, un Entry Point.
Si sabemos que es un driver lo que vamos a realizar, basta con que el main reciba los parámetros adecuados y retorne lo esperado para un driver. El sistema se encargara de cargar el driver cuando lo requiramos y darse cuenta que es un driver.

Podemos utilizar cualquier nombre como Entry Point, pero por convención en Windows se utiliza DriverEntry.
Si estas utilizando el DDK, al seleccionar que vas a construir un driver se utilizan una serie de opciones predefinidas. Esta es la razón por la cual DriverEntry se convirtió en algo similar al Entry Point oficial.

Al especificar /DRIVER, tenemos tambien otras opciones, directo de la MSDN:

Use the /DRIVER linker option to build a Windows NT kernel mode driver.


En este caso utilizaremos:

---

Conceptos básicos. Lo que debes saber.

Antes de comenzar, hay que cambiar la mentalidad de "Compilar y probar" que todos solemos adquirir mientras aprendemos a programar en modo usuario.
En el mundo de los drivers la situación cambia y lo hace en forma drástica.

Como mínimo podrías ocasionar un BSOD, y si estamos ante un driver que iniciara siempre con el sistema, tenemos un problema.
Igualmente, nada que no puedas revertir entrando en modo seguro u volviendo a configuraciones previas, pero esto solo cabe en las practicas y no en casos reales.

En conclusión, no compiles y pruebes el código de un driver al menos que entiendas a ciencia cierta que es lo que realiza, y mas aun si antes de compilarlo vas a modificar secciones del código.

Cabe recordar, que esta es solo una introducción de los conceptos básicos, por lo tanto quien quiera interiorizarse a fondo no le queda mas alternativa que revisar la MSDN u libros como "Programming the Windows Driver Model".


Interrupt Request Level

Abreviado como IRQL, partamos de la definición del DDK:


Si, puede ser difícil de comprender a la primer lectura, por eso vamos a intentar explicarlo en términos mas sencillos.
El IRQL de un procesador ayuda a especificar como un determinado thread puede ser interrumpido. Dicho thread solo puede ser interrumpido mediante código por un nivel mas alto de IRQL en el mismo procesador.
En estas épocas, es normal ver equipos con varios procesadores. En esos casos cada procesador corre en su propio IRQL

Estos 4 niveles serán con los que tendrás que trabajar normalmente.
Normalmente las APIs llevan una pequeña nota aclarando en que nivel de IRQL necesitas estar para poder utilizar determinada API. En reglas generales, a mas alto sea el nivel, menos APIs podes utilizar.

• Passive
• APC (Asynchronous Procedure Calls)
• Dispatch
• DIRQL

---

El nivel mas bajo. En este nivel corre un thread que se ejecute en modo usuario.


Este es el nivel donde ocurren las "Asynchronous Procedure Calls". Cuando ocurre una APC, el nivel del procesador se aumenta a APC_LEVEL.


La memoria paginada no es accesible en este nivel, por lo tanto toda la memoria accesible debe ser no-paginada. Esto ocasiona que disminuya en gran parte la cantidad de APIs que podes utilizar.


En este nivel generalmente un driver no lidia con interrupciones. Es mas que nada una forma de conocer que dispositivos tienen prioridad sobre otros.

I/O Request Packet

Abreviado IRP, basicamente es una estructura que permite a diferentes drivers comunicarse entre si y requerir tareas a finalizar.
El manejo de IRPs puede ser muy simple u demasiado complejo dependiendo de cual sea la estructura de los drivers.

El IRP también contendrá "peticiones secundarias", conocido como "IRP Stack Location". Cada driver contendrá sus propias peticiones secundarias respecto de como interpretar el IRP, denominada IO_STACK_LOCATION.

Creando el DriverEntry

Comenzando con un poco de código, el prototipo del DriverEntry:

NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject, PUNICODE_STRING pRegistryPath);

DRIVER_OBJECT es una estructura que representa el driver.  Este objeto contiene un puntero a DEVICE_OBJECT, la cual es otra estructura que representa un dispositivo en particular.
Un solo driver puede manejar múltiples dispositivos, y tal así, DRIVER_OBJETCT mantiene una lista de todos los dispositivos que para los cuales ese driver maneja peticiones.

Registrypath es una cadena que apunta a una ubicacion en el registro donde la informacion para el driver fue guardada. El driver puede utilizar luego esta ubicacion para guardar informacion especifica.

Veamos la primer parte de nuestra rutina de entrada:

NTSTATUS DriverEntry(PDRIVER_OBJECT  pDriverObject, PUNICODE_STRING  pRegistryPath)
{
    NTSTATUS NtStatus = STATUS_SUCCESS;
    UINT uiIndex = 0;
    PDEVICE_OBJECT pDeviceObject = NULL;
    UNICODE_STRING DriverName, DosDeviceName;
 
    DbgPrint("DriverEntry!\n");
 
    RtlInitUnicodeString(&DriverName, L"\\Device\\ehn");
    RtlInitUnicodeString(&DosDeviceName, L"\\DosDevices\\ehn"); 
 
    NtStatus = IoCreateDevice(pDriverObject, 0,
                              &DriverName, 
                              FILE_DEVICE_UNKNOWN,//No asociado a ningun dispositivo en particular
                              FILE_DEVICE_SECURE_OPEN, 
                              FALSE, &pDeviceObject);
 

Lo primero que se nota es la llamada a DbgPrint, esta funciona como el printf de toda la vida, pero en este caso el output va a parar al kernel debugger. Estos mensajes se pueden ver perfectamente con una herramienta como DbgView de Sysinternals

RtlInitUnicodeString inicializa una estructura del tipo UNICODE_STRING.
Esta estructura esta definida de tal modo que:

typedef struct _LSA_UNICODE_STRING {
  USHORT Length;
  USHORT MaximumLength;
  PWSTR  Buffer;
} LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING, *PUNICODE_STRING;

Donde "Lenght" es la longitud actual de la cadena, "MaximunLenght" es el tamaño máximo que la cadena puede tener, y "Buffer" es el puntero a la cadena.
Como podemos ver, esta estructura contiene el tamaño de la cadena por lo tanto no necesitamos verificar si la cadena esta terminada en NULL.

Luego de crear el dispositivo, ahora queda configurar el Driver Object para que llame a nuestro driver cuando ciertas peticiones se realicen. Estas peticiones se denominan IRP Major requests.
Existen tambien las denominadas Minor requests a las cuales nos referimos con anterioridad como peticiones secundarias, se encuentran en el stack location del IRP.

        for(uiIndex = 0; uiIndex < IRP_MJ_MAXIMUM_FUNCTION; uiIndex++)
             pDriverObject->MajorFunction[uiIndex] = ehn_UnSupportedFunction;
 
        pDriverObject->MajorFunction[IRP_MJ_CLOSE]             = ehn_Close;
        pDriverObject->MajorFunction[IRP_MJ_CREATE]            = ehn_Create;
        pDriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL]    = ehn_DeviceControl;
        pDriverObject->MajorFunction[IRP_MJ_READ]              = ehn_Read;
        pDriverObject->MajorFunction[IRP_MJ_WRITE]             = ehn_Write;
 

Es decir, cuando una aplicación en modo usuario llame a algunas de estas funciones:

• CreateFile
• CloseHandle
• WriteFile
• ReadFile
• DeviceIoControl

se llamara a tu driver.

---

Rutina Unload

Lo siguiente es la función de descarga del driver:

pDriverObject->DriverUnload =  ehn_Unload;

En realidad la rutina de descarga solo se necesita si queres descargar tu driver en forma dinámica, en ese caso la rutina debe ser especificada. Si no se especifica una función de descarga, el sistema no dejara que el driver sea descargado.

Esta es, por ejemplo, una forma simple de rutina de descarga:

void Example_Unload(PDRIVER_OBJECT  DriverObject)
{    
 
    UNICODE_STRING DosDeviceName;
 
    DbgPrint("Unload!!\n");
 
    RtlInitUnicodeString(&DosDeviceName, L"\\DosDevices\\ehn");
    IoDeleteSymbolicLink(&DosDeviceName);
 
    IoDeleteDevice(DriverObject->DeviceObject);
}

Definir las otras funciones es tarea para el hogar ya que creo es la parte mas divertida de todo esto y la que supongo motivara mas para los que quieran interiorizarse en el tema.
Igualmente este ejemplo es de lo mas básico y es el que se utiliza para comprender estos conceptos por lo tanto probablemente al buscar los conceptos que faltan para definir lo necesario se encuentren con ejemplos conceptualmente similares, por lo tanto la dificultad es casi nula pero si sera bastante divertido de seguro.

---

Cargar y descargar el driver en forma dinámica.

int _cdecl main()
{
    HANDLE HSmng,HServ;
    SERVICE_STATUS Sstatus;
 
    HSmng = OpenSCManager(NULL, NULL, SC_MANAGER_CREATE_SERVICE);
 
    printf("Cargando el driver!\n");
 
	if(HSmng)
    {
        HServ = CreateService(HSmng, "ehn", 
                                 "ehn driver", 
                                  SERVICE_START | DELETE | SERVICE_STOP, 
                                  SERVICE_KERNEL_DRIVER,
                                  SERVICE_DEMAND_START, 
                                  SERVICE_ERROR_IGNORE, 
                                  "C:\\ehn.sys", 
                                  NULL, NULL, NULL, NULL, NULL);
 
        if(!HServ)
        HServ = OpenService(HSmng, "ehn", SERVICE_START | DELETE | SERVICE_STOP);
 
 
        if(HServ)
        {
            printf("Iniciando servicio\n");
 
            StartService(HServ, 0, NULL);
            printf("Presione una tecla para cerrar el servicio\n");
            getchar();
            ControlService(HServ, SERVICE_CONTROL_STOP, &Sstatus);
 
            DeleteService(HServ);
 
            CloseServiceHandle(HServ);
 
        }
 
        CloseServiceHandle(HSmng);
    }
 
    return EXIT_SUCESS;
}

Para cualquier detalle respecto de las APIs utilizadas, referirse a la documentación del DDK y de la MSDN.

---

return EXIT_SUCESS


Luego de definir las funciones correspondientes en el driver, al utilizar las APIs desde modo usuario podrán comprobar que secciones de código se utilizan de su driver, incluso al definir las funciones que restan les basta con poner algunos dbgprint para luego ver con dbgview que es exactamente lo que se esta ejecutando.

Lo que no hay que hacer

Toda área tiene una lista de cosas que NO hay que hacerse, el desarrollo de drivers no es la excepción y Microsoft se encargo de resaltar este tipo de errores.

Como ejemplo, las primeras 10, hay mas en el link:




Referencias

Lectura recomendada para los que quieran interiorizarse y/o iniciarse en este tema.  

WDK
Peering Inside the PE: A Tour of the Win32 Portable Executable File Format
Key driver concepts
Getting started: Writing Windows drivers

Libros:
"Programming the windows driver model"

Saludos!

He decidido hacer nuevamente la encuesta respecto de que lenguajes se utilizan habitualmente puesto que las anteriores me parecen que no reflejan con mucha exactitud cuales son los lenguajes mas utilizados en el foro.
Las anteriores encuestas se pueden ver aqui.

Esta también expirara en el termino de 1 año como las anteriores, pero voy a restringir las opciones a votar a un máximo de 5 ya que la anterior permitía un total de 11 siendo 11 las opciones. Creo que todos estamos de acuerdo en que casi nadie utiliza mas de 5 lenguajes en forma habitual al menos que este todos los días probando los ejemplos del "Hola mundo" que aparecen en Wikipedia.  

Por supuesto digo casi, porque puede haber excepciones, pero realmente sera una estadística tan baja que ni siquiera vale la pena contemplar.
El problema creo yo es que "habitual" puede interpretarse de muchas maneras, así que definamos por ejemplo, en el termino de 1 mes, que lenguajes se utilizaron en mayor medida? esos serán los que haya que votar.

Recuerden, no es una competencia para ver quien conoce mas lenguajes, así que traten de ser objetivos con los votos. Que lenguajes utilizan habitualmente?

Saludos!

El primer error se da en las advertencias enviadas mediante cake, no se si en todos los casos pero si por lo menos en varios.

Al enviar una advertencia, el mensaje automatico queda algo asi como:


Ese "undefined" se agrega en casi todo mensaje enviado mediante cake. Si por ejemplo se envía una advertencia a todos los participantes del hilo, queda algo así:

---

El segundo error, se da en el "mostrar nuevas respuestas a tus mensajes". Al hacer un post y luego visitarlo por el regreso automático -el que se activa desde el perfil- el post no se marca como visitado. Si luego presionas el "mostrar nuevas..." aparecen los últimos mensajes que hayas hecho sin importar si visitaste todos y las ultimas respuestas son siempre propias. Tienes que volverlos a visitar para que se marquen como leídos y creo que eso antes no sucedía.

Eso solo.

Saludos!

Si tienes un source interesante y todavía no esta en la lista, ponlo en este mismo post o envíalo por pm y sera agregado.

---

---

A:

• ADT estructuras de datos

---

B:

• Broadcast scanner 4 win 2k/XP
• Brute Force Iterativo

• Brute Force
• Burbuja, Insercion y Seleccion

---

C:

• Cliente IRC
• Curso de Comunicacion de Procesos en C
• Conectar servidor SSL
• Configurar TIMEOUT de respuesta en un Socket
• Crypter Simple
• Crypter Simple Vr 2(?) FIX 1
• Capturar pantalla en jpg

• Crono
• Crear Ventanas Hijas

• Contar caracteres, lineas, y palabras de un archivo de texto

• Cronometro

• Comparador de dos archivos de texto
• Criba de Eratostenes
• Cambiar el titulo de la ventana activa por el titulo que queramos

---

D:

• Demonio - Troyano en C++ y Qt4 con licencia GPL
• Detectar VirtualBox
• DLL Injection
• DLL- Inyección con ejercicio
• DLL- Como generarlas y utilizarlas
• DLL inyect

---

E:

• Empezando con sockets: cliente y servidor
• Encriptacion RC4/ARC4
• Empezando a cifrar ficheros
• EPI Crypter 1.0
• EPI Crypter 2.0

• Enviando mails

---

F:

• Funcion in_cksum(), en paquetes ICMP

• File Bin2Hex

---

G:

---

H:

• Haciendo un proceso inmortal

---

I:

• Inline Assembly en C
• Inyeccion DLL
• Introducción a la inyección de código

---

J:

---

K:

• Keylogger
• Keyboard Hook - Keylogger

• Kuang2

---

L:

• Listar funciones de libreria DLL
• Luxur kernel
• Listas enlazadas heterogéneas
• Listar directorios y archivos
• Lectura/Escritura de datos de una aplicación externa
• Library Injector

---

LL:

---

M:

• Manejo de procesos en C

---

N:

---

O:

• Obtener tags de archivos mp3

• Opin: Libreria para manejo de archivos

---

P:

• Pseudo Random Encryption Algorithm
• Pong 0.1

• PExtractor v0.2 Stable Release

• printf de los valores de Registro REG_BINARY y REG_DWORD]
• Programa booteable

---

Q:

• QtPassGen

---

R:

• ReverseSHell
• Recorrer la IAT

---

S:

• Sockets en linux
• Servidor SSL con Pthreads
• Sudoku

• Sniffer
• Screenshot
• Split 100% funcional
• Sockets-practical

• Subir Archivos via HTTP

• Subir fichero a un FTP

---

T:

• Teorema del binomio

---

U:

---

V:

---

W:

• Win Backdoor Bind port

---

X:

---

Y:

---

Z:

---

[/list]

Vamos Argentina! mañana a todo o nada 

Requisitos:

• Tor
• Cliente IRC que soporte SASL

En este caso para el ejemplo utilice xchat.

---

1) Configuración Tor.

• Abrimos el archivo de configuración, por defecto se encuentra en:

o

• Al final del archivo agregamos la linea:

• Guardamos el archivo y reiniciamos Tor.

2) Configuración xchat.

• En la lista de redes, creamos una (pueden llamarla como quieran). En este caso la llamaremos freenode.
• La editan y en la lista de servidores agregan:

• Vamos a Configuración>Preferencias>Red>Configuración de la red:

Nombre de equipo: localhost.
Puerto: 9050.
Tipo: SOCKS5

3) Login SASL

• Descargamos cap_sasl.py y lo colocamos en el directorio de instalación
• Xchat>Cargar complemento>cap_sasl.py (La interfaz de Python debería cargarse automáticamente si reinician xchat)
• /SASL -set Nombrered(En este caso es freenode) nick pass
• Conectar

---

Me preguntaron varios sobre esto por Msn así que preferí hacer un post al respecto. Lo hice lo mas sencillo posible pero si algo queda poco claro no duden en preguntar.

Saludos!

Este articulo también se encuentra en wiki.elhacker.net,

La mayoría que recién esta empezando con C/C++ y viene al foro a sacarse dudas, cometen errores similares. Incluso muchos tienen conceptos erroneos sobre la utilidad o eficiencia de ciertas funciones, probablemente debido a el estudio de textos incorrectos o de libros anticuados.

Pero incluso a veces uno no puede escapar de ciertas cosas. Imaginen a alguien que recién entra en la universidad y el profesor le hace incluir conio para utilizar getch. Seguramente el alumno de por sentado que hacer eso esta perfecto, e incluso el profesor recompense con notas altas a los que programan tal cual se ha enseñado.
Por lo tanto, ciertas cosas son comprensibles y el único consejo que se puede dar es que nunca den por sentado algo, es recomendable informarse antes para ver que es lo que se esta realizando, sobre todo en programación.

Para los que quieran revisar un poco explicaciones mas detalladas del "por que" de ciertas reglas, puede revisar este draft, que aunque puede tornarse bastante técnico para alguien que recién comienza, puede servir bastante:

WG14/N1256 Committee Draft — Septermber 7, 2007 ISO/IEC 9899:TC3 (Gracias Queta)


1) gets();

La falta de control en un programa es un factor bastante negativo, y también peligroso en caso de programas comerciales o masivos. Ese es el principal problema de gets, no tiene control interno.

¿Que signifca no tener control interno?

Significa que la funcion acarrea como consecuencia el mal comportamiento del programa, resultados inesperados y erroneos, vulnerabilidades entre otras tantas cosas.
Define una cadena de 10 caracteres, y gets va a aceptarte eso y muchisimo mas como entrada.

Veamos este codigo:

#include<stdio.h>
 
int main()
{
 
char letra1[]="AAAAA";
char letra2[]="BBBBB";
char letra3[]="CCCCC";
 
printf("A: %s\nB: %s\nC: %s\n\n",letra1,letra2,letra3);
 
printf("Ingrese la letra D, 5 veces: ");
gets(letra2);
 
printf("\nA: %s\nB: %s\nC: %s\n\n",letra1,letra2,letra3);
 
getchar();
}

Como vemos nada paso, y los elementos de letra2 se reemplazaron por el input ingresado como debería ser . Ahora en vez de 5 veces, ingresemos la letra 'D' mas veces de lo que el programa nos indica:


Que paso con letra1? precisamente lo que no queremos que pase en nuestro programa. gets sobreescribio una zona de memoria que no debia sobreescribir, ya que el input debia ser ingresado en letra2, pero simplemente no le importo que el input sea muchisimo mas grande que el tamaño de la cadena. Razon mas que suficiente para no utilizarla.

Por lo tanto es recomendable utilizar fgets();

fgets(char *string, int length, FILE * stream)

Es decir:

fgets(letra2, 5, stdin);

Con fgets permites que sean ingresados lenght-1 caracteres.
Aunque no todo es color de rosas, y en caso de que se ingresen menos caracteres de los que has definido como tamaño, tendras que lidiar con un salto de linea '\n'. Obviamente es una nimiedad que puedes arreglarla de esta forma:

if (letra2[strlen(letra2)-1] == '\n')//string.h para strlen(); 
letra2[strlen(letra2)-1] = '\0';

Supongo que con esto queda claro que no tiene sentido utilizar gets();.

Links:
http://en.wikipedia.org/wiki/Fgets
http://www.gidnetwork.com/b-56.html


2) fflush(stdin);

fflush(stdin) es un invitado casi diario. Pocas veces pasa un dia sin que alguien lo recomiende o lo mencione como la solucion! a los malos comportamientos de las pausas en los programas.

STDIN, como su nombre lo indica, significa 'Standard input'. Es decir, el ingreso por teclado.

Acorde al Standard, fflush espera solamente un stream de salida (STDOUT: 'Standard Output) por lo que el comportamiento con streams de entrada como STDIN es indefinido. Por mas que en algunas plataformas funcione, o que en algunos compiladores funcione, no deberia ser utilizado.

Por el otro lado, para evitar esas pausas fastidiosas es necesario evitar las funciones que dejan basura por doquier (como scanf();) y utilizar funciones como la ya mencionada fgets();


http://foro.elhacker.net/programacion_cc/fflushstdin-t91101.0.html
http://foro.elhacker.net/programacion_cc/zanjar_de_una_vez_fflushstdin-t265125.0.html;msg1294511
http://foro.elhacker.net/programacion_cc/error_super_basico_en_c_quien_me_ayuda_soy_nuevo-t262118.0.html;msg1275898
http://foro.elhacker.net/programacion_cc/problema_con_el_compilador_gcc_de_ubuntu-t248582.0.html




3) system("PAUSE");

Otro invitado diario es la pausa utilizando system. Esto incluso me ha tocado en mi universidad. Que el profesor me haga realizar ejercicios exclusivamente utilizando system y la pausa tambien habia que realizarla exclusivamente utilizando system. En fin, seguramente muchos consideren que realizar esto no es un gran problema, y probablemente tengan razon en los codigos que uno realiza como tarea estudiantil. Pero es un habito malo, y como todo, hay que dejarlo algun dia. Claramente no puedes pasarte toda la vida llamando al sistema para hacer una pausa.

*No es portable, solo va a funcionar en sistemas que tengan el comando PAUSE.

*Es una funcion pesada. Llamar al sistema, suspender tu programa, buscar el comando PAUSE, etc etc etc etc.

Por el otro lado si se siguio la norma de no dejar basura en el buffer de entrada, se puede utilizar soluciones mas sencillas como getchar(); (o cin.get(); en C++).


4) conio.h

Librerias inutiles si las hay, pero por sobre todas las cosas NO standard. No existe problema para el cual sea exclusivamente necesario utilizar conio.h. Y visto que aca la mayoria de los que la incluyen lo hacen para utilizar getch(); supongo que con todo el parrafo anterior habran quedado claras las alternativas.

http://en.wikipedia.org/wiki/Conio.h
http://www.gidforums.com/t-7379.html


5) void main();

Seguramente para justificar esto habría que decir que el estándar dice que void no puede ser el valor de retorno del main, lo cual es verdad, pero no siempre es suficiente. Sobretodo considerando que muchas veces en los libros el void main dice presente.

No voy a extenderme mucho con esto ya que voy a dejar los links necesarios para el que quiera entender porque sucede, pero como base comprendamos esto:
 
-Devolver un valor void es perder la garantia que un valor de retorno distinto de 0 implica un error, lo cual es malo tanto para el SO como para el determinado programa que pueda estar llamando a tu código.

-Esta mal acorde al estándar.

-Puede que tu programa no funcione correctamente.

Los errores pueden depender de los mecanismos de retorno o la arquitectura especifica en la cual estemos. Pero por supuesto, si elegimos un lenguaje de alto nivel como lo es C o C++, es para no tener que preocuparnos por esos asuntos.

En conclusión, el que quiera entender el " por que", leer los siguientes links.

Links:

http://www.eskimo.com/~scs/readings/voidmain.960823.html
http://home.att.net/~jackklein/ctips01.html#int_main
http://users.aber.ac.uk/auj/voidmain.shtml


6) Procesamiento de cadenas: string.h

La mayoría de las funciones que no tienen la posibilidad de pasar como argumento el tamaño del buffer que debe procesarse, estan completamente expuestas al desbordamiento de buffer. Sobre todo si el contenido del buffer origen es ingresado por el usuario, y por sobre todas las cosas, si no se hicieron las validaciones correspondientes. (Por ejemplo, haber utilizado gets o no haber chequeado el tamaño de la cadena antes de copiar/concatenar o cualquier otra forma de procesar una cadena).
Obviamente no voy a hablar sobre todas las funciones, pero si sobre dos ejemplos que dan la pauta de lo que sucede y de lo que debería hacerse: strcpy y strcat.

a) strcpy ( char * destination, const char * source );

Veamos un ejemplo de un codigo incorrecto:

#include <stdio.h>
#include <string.h>
 
int main()
{
char cadena1[]={"aaaa"};
char cadena2[100];
char cadena3[]={"0123"};
 
printf("Ingrese cadena: ");
fgets(cadena2,100,stdin);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s\n\n",cadena1,cadena2,cadena3);
strcpy(cadena1,cadena2);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s",cadena1,cadena2,cadena3);
getchar();
return 0;
}

Como se ve claramente, el problema esta vez no estuvo en la recepción de los datos (en el sentido técnico), si no en el copiado. Ya que strcpy no verifica si el buffer destino es efectivamente capaz de contener los datos del buffer origen, lo cual por supuesto ocasiona perdida de datos y buffers overflows.
Obviamente si el fgets se hubiese utilizado correctamente, esto no hubiese sucedido.

b) strcat ( char * destination, const char * source );

La misma historia sucede aqui. Al no poder especificar el tamaño del buffer destino la funcion es insegura. Veamos un ejemplo incorrecto:

#include <stdio.h>
#include <string.h>
 
int main()
{
char cadena1[]={"aaaa"};
char cadena2[100];
char cadena3[]={"0123"};
 
printf("Ingrese cadena: ");
fgets(cadena2,100,stdin);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s\n\n",cadena1,cadena2,cadena3);
strcat(cadena1,cadena2);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s",cadena1,cadena2,cadena3);
getchar();
return 0;
}

Como pueden ver suceden errores muy similares. Obviamente es un error tonto de programación en el cual el desarrollador pasa un mal argumento a fgets, ya que de haberlo hecho bien el error no sucederia. Pero ese no es el asunto, lo importante es que tanto strcpy o strcat (y toda la familia de funciones) no realizan (o permiten realizar) la validación extra necesaria. Imaginen que creas una cadena para tomar una ruta del sistema operativo para luego concatenar, ¿Y si el atacante se da cuenta de eso y decide explotar el overflow por ese lado? mil variantes pueden existir y probablemente no siempre uno cubra todas ellas.

c) Entonces que se puede utilizar?

strncpy y strncat cumplen su función perfectamente si se utilizan en forma correcta.

c1) strncpy ( char * destination, const char * source, size_t num );

#include <stdio.h>
#include <string.h>
 
int main()
{
char cadena1[]={"aaaa"};
char cadena2[100];
char cadena3[]={"0123"};
 
printf("Ingrese cadena: ");
fgets(cadena2,100,stdin);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s\n\n",cadena1,cadena2,cadena3);
strncpy(cadena1,cadena2,1);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s",cadena1,cadena2,cadena3);
getchar();
return 0;
}

c2) strncat ( char * destination, const char * source, size_t num );

#include <stdio.h>
#include <string.h>
 
int main()
{
char cadena1[]={"aaaa"};
char cadena2[100];
char cadena3[]={"0123"};
 
printf("Ingrese cadena: ");
fgets(cadena2,100,stdin);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s\n\n",cadena1,cadena2,cadena3);
strncat(cadena1,cadena2,0);//Obviamente esta linea es un absurdo
 //Pero queda claro el control que la funcion mantiene
printf("cadena1: %s\ncadena2: %s\ncadena3: %s",cadena1,cadena2,cadena3);
getchar();
return 0;
}

Estas ultimas funciones a pesar de poder utilizarse perfectamente como solucion a lo anterior expuesto, tambien tienen sus contras:

-Tanto strncpy o strncat no proveen un valor de retorno que pueda implicar un error o el exito de la cadena resultante, si no que devuelven un puntero al buffer destino. Por lo tanto requiere un esfuerzo extra por parte del programador.

- strncpy no finaliza la cadena resultante con null si el destino es al menos igual en tamaño que el origen, por lo tanto siempre debe finalizarse la cadena con null después de la llamada a strncpy.

- strncpy tambien tiene un comportamiento que puede afectar el rendimiento del programa en caso que el buffer destino sea considerablemente mas grande que el buffer origen, ya que en este caso se realiza el zero-padding, es decir, llena el resto de la cadena con nulls.

Microsoft tiene una lista de funciones baneadas (lo que en Visual Studio se conoce como deprecated) y obviamente tiene el reemplazo de estas llamandolas funcion_s. Ejemplo: strcpy_s, strcat_s, gets_s y etc.
Pueden ver las funciones catalogadas como inseguras en este header, y su reemplazo en esta lista. (Gracias Vertex por los links)

Tambien existen opciones como strlcpy y strlcat, las cuales pueden ver a fondo en este link.


------------------------------------------------------------------------------------------

Continua

Pues eso, anda alguien viciando ese juego?

Un video para los que no lo conocen

Y otra vez y vaaan, creo que es la cuarta vez que un juego con este motor me da dolores de cabeza (Cod 5, Mirrors Edge etc)

Voy primero con el problema y despues con las cosas que hice y el hardware que tengo.


Problema

Inicio el juego y queda el splash screen como 5 minutos, luego como que quiere iniciar y queda en black screen.


Hardware y SSOO

PC 1

Core 2 Duo e8400
4gb ram 1066mhz
Geforce 9800gt

SO1: Windows XP Pro SP3 x32
SO2: Windows Vista Ultimate x64

Juegos probados con anterioridad en esta pc: Crysis, Crysis warhead, GTA 4 etc

PC 2

Pentium D
2gb ram
Geforce 6200

SO: Windows XP Pro SP3 x32


Intentos fallidos

1*Actualizar graficas
2*Actualizar DX
3*Actualizar Physx
4*Tunear baseengine.ini
5* Desactivar Unimodem (De forma manual, cambiando los valores DevicePresence/Emulated en el registro)
6*Reinstalar
7*Reiniciar muchas veces
8*Ejecutar modo compatibilidad
9*Probar varias medicinas
10*Putear
11*Rezar a Zeus
12* Deshabilitar aceleracion de sonido

Nada de esto funciono, alguien tiene alguna idea? Googlie, bingie y Yahooie y nada.



Un saludo!

Bueno esa es la pregunta.

Un asistente que hable y reconozca la voz, se le pueda poner tareas programadas. No importa si es Windows o Linux.
Para poner un ejemplo sencillo, que pueda tanto despertarte hablando como asi tambien maximizar la pantalla si le das la orden por voz.

Sin tener que utilizar el esclavo o cosas asi porque es muy cutre.

Un abrazo