Mensajes

Ahí está la explicación...

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


B#

(...)la primera es que, en muchos exploits que he visto funcionando, veo que  (no se si todos) te dan una shell en system32, y queria saber, porque esto es asi(...)

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

(...)se que los codigos hex del shellcode en los BO se aprovechan por ejemplo de una mala programacion con la funcion strcpy o memcpy, y la pregunta en si es, estos codigos (como estan desbordando un string) por que se ejecutan y no se vuelven solo parte del string?(...)

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...

(...)la otra es mas corta jeje, para que sirve la libreria NetApi32.dll?(...)

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

(...)y la ultima es, que es y para que sirve la ligadura dinamica en OOP?(...)

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#

[for]

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

Código (c) [Seleccionar] Expandir

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#

visto lo visto optaré por poner la dll en una shellcode byte a byte y generar el archivo dll con la shellcode e inyectar después, ahora mismo lo veo lo más simple ya que la dll sería un proyecto con numerosas dependencias llamadas a librerías etc.. ¿Que os parece?.

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#

[float]

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#

sin embargo respecto a la conversion a UCHAR la hago para que no me salgan bytes negativos de la forma de 0xFFFFFFAB como me ocurrio que luego generan error en la declaracion de la shellcode, de esta manera ahorro esos problemas con el casteo.

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

Sin embargo la autentica duda es: si cojo una dll de un messagebox por ejemplo y paso todos sus byte a una shellcode e inyecto la shellcode ¿deberia de inyectarse la dll sin problemas no?. La dll que uso para la shellcode hace un messagebox y la he inyectado en procesos sin problemas pero a la hora de inyectarla como shellcode surgen los problemas y crashea el proceso objetivo

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#

(...)este es el mensaje que me sale arriba a la derecha cuando inicio Debian(...)

Insisto...

en dicho caso conviene instalar un SO que esté probado por ATI y soportado

Linux Distributions Supported: This version of the AMD Radeon Software Linux Proprietary Graphics Driver is designed to support the following Linux distributions:

Distributions supported:

   Red Hat Enterprise Linux Suite 7.2, 7.1, 7.0, 6.7, 6.6, 6.5
   Ubuntu 12.04.4 LTS, 14.04.2, 14.04.3, 15.04, 15.10
   SUSE® Linux Enterprise 11 SP3, 12
   OpenSuSE 13.1

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

Aquí: https://forums.linuxmint.com/viewtopic.php?t=15576

un usuario cuenta como su procesador bajo del 60% al 10% cuando soluciono este problema... entonces es simplemente eso, ver que no sufra el procesador (disculpar si soy muy repetitivo)

La solución que el usuario dice que le funcionó es esta:

Pero yo voy a Menú > Administración y no me sale nada de Administrador de controladores, esto hay alguna forma de instalarlo?

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#

[salvo que realmente necesites]

Hola a todos me he instalado en el PC Debian Jessie 8.5.0, pero tengo un problemilla y es que se ve todo muy pequeño, y me sale un mensaje al iniciar el ordenador avisandome de que hay problemas con el tema de los drivers y la gráfica

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#

(...)"No se puede instalar el paquete <<grub-pc>> en <</target>>(...)

elige la opción de instalar el grub en sda (sin número), siempre recuerdo que preguntaba en que partición instalar el grub...


B#

Se supone que debo flashear una memoria USB para instalarle Linux y para ellos estoy usando Rufus(...)MI PC me muestra el pendrive con 3 GB nada más 3,68 de 3,68 (esto es lo que pesa la imagen .iso) y el pendrive es de 8 GB.

Eso pasa siempre que haces eso con los usb, la razón de porque tenés menos espacio es porque el usb tiene multiples particiones y windows nunca reconoció más de 1 particion por usb...

Habre un cmd e ingresa los comandos, los parentesis son referencia de que tenes que hacer:

Código [Seleccionar] Expandir

diskpart
list disk
(te va a listar todos los disco con sus particiones y ahí elegís el número del disco correcto)
sel disk (número de disco acá)
clean
exit
exit

Terminas desenchufando el usb (extraer el usb con seguridad si lo permite) y lo metes de nuevo y windows te sugerirá formatearlo...

EDIT 2: Con gparted desde un linux también puedes solucionarlo de manera gráfica más sencilla


B#