Prueba ingresar a la terminal desde el usuario que tiene el problema, escribe lo siguiente y reinica la pc:

sudo rm -Rf "./.gconf" "./.cache" "./.config"

B#

Es irrelevante en todos los micro-controladores/procesadores modernos se usa el estandar IEE 754 y siempre va a tener un mínimo de error de precisión dado que no se puede representar números no divisibles por 2, sin importar lenguaje de programación, tipo de arquitectura, etc...

En el caso de 0.1f:
1.0 /2-->0.5 /2-->0.25 /2-->0.125 /2-->0.0625 /2-->0.03125 /2-->0.015625 /2-->0,0078125 y podría seguir así y nunca llegar a 0.1 aunque sigas sumandos bits por derecha nunca llegarás al número exacto...


B#

Ahí está la explicación...

http://docs.python.org.ar/tutorial/2/floatingpoint.html#error-de-representacion


B#

Si mal no recuerdo el cmd se encuentra en esa carpeta asi que sino se le especifica ningun path se abre siempre ahí...

Porque están desbordando la pila(stack) de ejecución de la función que llaman strcpy/memcpy, en la pila están los parámetros,el caller(dirección de retorno) y las variables locales en ese orden... Se supone que al desbordar una variable local podés subir hasta el caller, modificarlo para luego que salte al código de la stack desbordada, haga "lo que se le cante al código" y finalmente retornar con la dirección del caller original o saltar hacia la dirección...

Es una librería del sistema que se supone que maneja redes
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370675(v=vs.85).aspx


Es un tema de lenguajes de alto nivel y se refieren a que si tenés una clase padre con tales funciones y una clase hija que deriva del padre, cuando "sobre-escribas" una función del padre en la clase hija se llamará a la función de la clase hija, esto sucede cuando defines un objeto de la clase padre pero lo inicializas con el contructor de la clase hija, por decirlo de una manera facil de entender...


B#

Ahí te lo arreglé, no verificaste si el archivo estaba bien abierto y el for se iba de rango probablemente:

int main()
{
	tipoPunto arreglo[10];
	LECTURA(arreglo,sizeof(arreglo)/sizeof(tipoPunto));
	return 0;
}
 
void LECTURA(tipoPunto*arreglo,int tamanio)
{
	FILE*arch;
	int i=0,j=0;
	arch=fopen("puntos.csv","r");
	if(arch)
	{
		while(!feof(arch))
		{
			fscanf(arch,"%d,%d\n",&arreglo[i].x,&arreglo[i].y);
			i++;
		}
		fclose(arch);
	}
	for(j=0;(j<i)&&(j<tamanio);j++)
	{
		printf("Punto %d = %d - %d\n",j+1,arreglo[j].x,arreglo[j].y);
	}
}

B#

No entiendo cuál es el objetivo de hacer la shellcode, si ya puedes inyectar una dll en el "proceso objetivo" de la manera común y que el Windows te la cargue correctamente con sus dependencias... Además no te salvás de hacer la tarea de cargarla como el SO excepto que ya no tenés que parchear el shellcode desde el "proceso atacante" sino desde el "proceso objetivo"...


B#

Jamás uses variables con float u double para especificar el elemento de un vector, en este caso j modifícalo como entero...

EDIT: j y n son de diferentes tipos... por lo que va a ver pérdida de datos, cuidado con eso en el futuro...


B#

Puedes ahorrarte ese problema ya con declarar el buffer como PUCHAR en lugar de PCHAR...


Cada archivo PE tiene al inicio la cabecera DOS, la cabecera PE, secciones de información extras, si es libería/driver o utiliza ASLR seguro tiene secciones de reubicaciones (.reloc), secciones de datos globales (.*data), secciones de importaciones y exportaciones (.import / .export si mal no recuerdo), secciones de código ejecutable (.text / .code , etc...) y algunas veces secciones de recursos.
Si lo que quieres hacer es pasar todo a una secuencia de bytes y enviarselos directamente a un programa y redireccionar un hilo de ejecución al primer byte estás frito, dado que no está apuntando a código real sino a información del archivo PE.
Cuando inyectas con otros métodos por ejemplo hilo remoto con LoadLibrary, el API de dicho proceso se encarga de cargar y verificar si es un archivo PE, procesar los datos, cargar módulos dependientes, reubicar los datos del código a ejecutarse en caso de que esté ocupado la mismas direcciones virtuales del proceso por otro módulo y capaz algo más que se me olvide de momento.
Conclusión tendrías que no solamente inyectar el código sino que además realizar las mismas tareas que el PELoader a mano desde otro proceso lo cuál se vuelve una tarea demasiado tediosa y mucho más si además tienes que cargar dependencias...

EDIT: Capaz te sirva (como una sugerencia de una flasheada que se me ocurrió recién ) crear un ejecutable normal sin ASLR, lo cuál te evitarías la tabla de reubicaciones, evitar objetos o variables globales para la secciones de datos (usando únicamente locales), evitar llamar a APIs del SO directamente para evitar la secciones de import creando tus propias GetProcAddress, GetModuleHandle y LoadLibrary (en internet hay info) si necesitas APIs. En lugar de recopilar todos los bytes del PE solo obtienes los de la sección/es ejecutable/s y el offset de tu función inicializadora (main), creando primero un JUMP CALL al principio del payload hacia el main y luego metiendo todos los bytes recogidos de la/s sección/es ejecutable/s.


B#

Insisto...


http://support.amd.com/en-us/download/desktop?os=Linux+x86_64


Eso es para Linux Mint que está basado en Ubuntu (Sistema soportado) y dicha opción existe:




...solo que en tu caso debería decir fglrx en lugar de nvidia, si quieres cinnamon te recomiendo Linux Mint 17 (Ubuntu 14.04)

https://www.linuxmint.com/release.php?id=22


B#

Cuidado con las placas ATI y los drivers privativos en Linux, yo siempre tuve varios problema instalandolos y realmente no los recomiendo salvo que realmente necesites utilizar aceleración gráfica, en dicho caso conviene instalar un SO que esté probado por ATI y soportado.
Los drivers de ATI (privativos) tienen problemas con Gnome (Escritorio por defecto en Debian) debido a problemas con la interfaz EGL y aunque durante en los últimos 2 años mejoraron bastante ya dejaron de ser soportados oficialmente por AMD desde el final del año pasado y nunca tuvieron el mismo rendimiento que en Windows. En su lugar ahora utilizan los drivers radeon/amdgpu (libres) que están escritos por Mesa con ayuda de AMD...

Yo personalmente te recomendaría utilizar ubuntu 14.04 si realmente necesitas aceleración gráfica
Acá te dejo un link de como instalarlo bien
https://www.youtube.com/watch?v=tc8s5yhylbo

EDIT: No instales versiones 16.04 en adelante porque no son soportados...


B#