A nadie le importa una mierda, pero... v14

[Bahamunt]

Entonces te hacen falta otros tantos para poder comprártelo xD

[Are_]

(05-26-2017, 04:19 PM)Reboot escribió: Lógicamente. Dinero Gratix siempre viene bien para tapar alguna trampa o darse un capricho... El problema es cuando el capricho se llama Tesla T_T

~~~~~D:

[CucuFaiter]

(05-26-2017, 04:52 PM)Are_ escribió:

(05-26-2017, 04:19 PM)Reboot escribió: Lógicamente. Dinero Gratix siempre viene bien para tapar alguna trampa o darse un capricho... El problema es cuando el capricho se llama Tesla T_T

~~~~~D:

Yo también quiero mi tesla T_T

Aunque creo que habré de esperarme como a 2025, que tenga dinero y estos sean lo suficientemente baratos.

Regalo de 40 cumpleaños. Ale. Decidido xD

¿Aguantará mi Seat leon otros 8 años?

[CucuFaiter]

ANLIUM, pero estaba mirando si había nuevos episodios de HdA en Pordede cuando me ha salido el típico anuncio de tías tetonas. Era de un juego online.

"Este es el juego #1 de mujeres sensuales con poca ropa (o algo así ponía). Pero antes, debemos hacerte unas preguntas".

Abajo, hay una caja con dos respuestas y su correspondiente pregunta.

"¿Eres mayor de 18 años?"

Contesto "no". Siguiente pregunta.

"En este juego salen muchas mujeres muy sensuales y con poca ropa ¿estás dispuesto a admitirlo?"

Contesto "no".

"Verificando respuestas..."

Sale la típica barra de Loading.

"Ok, ya puedes crear a tu personaje".

Me ha dado la risa tonta y aquí llevo un rato descojonandome en la soledad de mi cuarto.

[Reaper45]

(05-25-2017, 10:37 AM)Reboot escribió: ANLIUM o quizás un poquito sí: https://www.extremetech.com/extreme/2498...-computers

Hackear ordenadores con un puto SRT. Estoy alucinando. ¿Cómo puede ser posible? Aunque estoy leyendo que más que por el SRT es por bajar los subtítulos zipeados.

No es por el zip, no hay código fuente del exploit disponible, pero he visto los parches al párser de .SRT del VLC y es un buffer overflow de manual.

Nada raro ni espectacular, simplemente algún medio sacando esto because yes y el resto imitándoles.

[Reboot]

Caray. ¿Y cómo pasas del buffer overflow a ejecutar código? ¿Va incrustado en el propio archivo?

No será espectacular, pero... El riesgo lo tienes ahí. Y me parece de aurora boreal que por abrir un simple archivo de texto termines petando el parser (que se supone que debería estar preparado para no petar) y ejecutando código malicioso.

[Reaper45]

A grandes rasgos:

Los parsers, decoders, y reproductores en general se hacen en C o C++ por temas de eficiencia, y ahí hay que controlar que no te pases de la memoria reservada. Entiendo que sabes lo que es un buffer overflow, esto es habitual, y es parecido a lo que ha pasado en este caso:

char miBuffer[256];
[blablabla]
int nLength = strlen(lineaDelSubtitulo);
puntero = malloc(nLength);
[copiar linea del subtitulo a puntero]

Después se hace un for o lo que sea y se copia puntero a miBuffer que es limitado. Si simplemente te pasas del limite, sea codigo java o no, la aplicación se explota. Pero en lenguajes que no administran la memoria y que delegan la comprobación del límite al copiar el buffer al programador, se explotan por violación de segmento, lo que viene ser que has sobrescrito lo que no tocaba (en lugar de detectarlo y explotarse deliberadamente a lo bestia como en java, c#, etc, como toca).

El caso es, puedes sobreescribir suficiente memoria que no le pertenece hasta llegar al puntero del stack con la siguiente instrucción de código. Se puede poner ahí una instrucción jmp que salte al principio de tu buffer, el cual has llenado con basura, NOPs y tu código precompilado para tomar control, pues el SRT es el que provee lineaDelSubtitulo.

Hay muchos nombres de técnicas de explotación de bugs, vulnerabilidades y sus correspondientes protecciones, pero todo se basa en joder la RAM de formas imaginativas, o de hacer complicado joderla por datos que se desconocen.

[Reboot]

Sí, sí. Si lo de los buffer overflows lo conozco bien, pero, coñe, si vas a asignar 256 caracteres, lee un máximo de 256. No entiendo que la peña pique código tan mal... Y lo dice un boticario.

[Reaper45]

Para mí es comprensible, mantener una base de código inmensa es muy propicio a hacer ñapas como esta pues mover cosas en memoria es muy habitual, y más en el caso que nos ocupa, sobre todo cuando hay fechas de entrega que te impiden ser lo suficientemente Sheldon con tu código. O tu compilador o tu VM te ayuda, o te ocurrirá con un 100% de probabilidades.

Luego esta el tema de que parchees una vulnerabilidad en una función crítica y te cargues el rendimiento. Hace nada pasó eso con la Nintendo 3DS, pa que veas.

Todo es mejorable, claro está.

[EmuAGR]

(05-30-2017, 08:09 PM)Reaper45 escribió: Luego esta el tema de que parchees una vulnerabilidad en una función crítica y te cargues el rendimiento. Hace nada pasó eso con la Nintendo 3DS, pa que veas.

Diría que eso no es verdad, solicito pruebas.