Hola, quería saber que opinan ustedes de esta idea.
He buscado artículos pero no encontré demasiado. Los datos están ahí pero no me apetece analizarlos de momento, quizá ustedes lo sepan.
La idea es que los procesadores x86 son muy ineficientes en general intrínsecamente por su diseño y arquitectura.
Mi argumento principal que respalda esto es su complicado juego de instrucciones.
Quizá muchos de ustedes han intentado alguna vez crear un desensamblador de x86, en C por ejemplo, y no es algo trivial ni fácil, el código que necesita es bastante y necesariamente complicado, no hay soluciones demasiado elegantes (a mi juicio).
Eso que nosotros hacemos en C o cualquier otro lenguaje, los microprocesadores tienen que hacerlo pero por medio de hardware, transistores, unidades lógicas. Ello hace que necesiten muchos más transistores que otras arquitecturas, y por tanto más consumo de potencia, o sea, eficiencia (da igual, energética o de potencia de cálculo, no diferencio).
Quizá sea por ello que en los sistemas empotrados x86 desaparece por completo, en general. Se tiende a microprocesadores ARM por ejemplo que consumen muchísimo menos y tienen gran potencia (aunque menos que los x86 que usan mucha más energía y frecuencias).
Es otra de las causas quizá por la que las GPU's, sus núcleos de procesamiento, tampoco usan x86, bueno, esto sería obvio ya que tienen otros usos más específicos, pero bueno, podrían compartir el juego básico, todo microprocesador tiene instrucciones de control, de movimiento de datos, etc.
Me consta también que Intel muchas veces "inteltó" (chiste malo) deshacerse del juego de instrucciones sustituyéndolo por otros, pero no pudo por el mercado.
Y mi atrevida sugerencia: si usáramos el mismo número de transistores y la misma frecuencia (y la misma técnica de última generación litográfica, etc), en un procesador tipo ARM, RISC o lo que sea, que un x86 actual, se superaría enormemente la potencia de cálculo.
El problema es arrastrar esa vieja compatibilidad "hacia atrás" (por la voz inglesa), que sólo obliga al diseño a estar estancado, cargando con viejas funcionalidades obsoletas que lo limitan, es una especie de evolución darwiniana de los procesadores, en que quedan miembros inútiles que antiguamente eran usados (tenía un nombre que ahora no recuerdo, si me lo pudieran recordar...

Otra idea que arroja esto, es que Intel debería estar realmente interesado en la pervivencia del modelo de código cerrado, ya que si pudiéramos usar sólo código abierto, no habría tanta dificultad en compilar los sistemas para cualquier máquina.

Se me olvidó mencionar también la idea, de que mucha de la lógica de los x86, se empeña en optimizar este código, de alguna manera estas unidades sobran en otra arquitectura, y habría espacio para otro tipo de lógica, o son complejas, en otra arquitectura serían más simples.

En resumen, más transistores = más potencia, es obvio, pero transitores mejor utilizados, también = a más potencia.

Bueno, el título no es muy informativo, esto es más una curiosidad que otra cosa.
El otro día me acordé de aquellos viejas leyendas, quizá mitos, de antaño, que circulaban por el underground (de aquella se llamaba a esto underground, recuerdan? xD) como el libro del anarkista creo que era uno, que concretamente ponía una receta para crear disquettes explosivos.
Luego estaba aquello de los virus que te 'jodían' el disco duro con un temible 'aterrizaje de pistas'. Luego ves un disco por dentro y te cuentan esas cosas, pero bueno, hay gente que aún se asusta por estas cosas, no estoy seguro pero creo que lo del aterrizaje de pistas ya está superado. Es decir, muchas veces se me fue la corriente con alto uso del disco duro y nunca se me estropeó ni nada. Además aquello de aquellos viejos sistemas en los que existían los comandos de aparcamiento de cabezales, pues no sé, pero los programadores hoy en día ya no nos preocupamos por eso, creo.
Mi pregunta es, un software malicioso, ¿qué tanto puede causar daño físico hoy en día a los modernos aparatos de hardware?
A priori se me ocurren varias cosas:
- Flashear un firmware incorrecto a la bios que impida el arranque del pc (esto me pasó por cacharrear demasiado lejos, perdí aquel ordenador)
- Overclocking por software (creo que ahora se hace por software totalmente, ¿estoy en lo cierto?), quizá controlar la refrigeración, hacer uso extremo de los ciclos y quemar el procesador.
- Mismo para la gpu.
- No sé si la memoria RAM... pudiera sobrecalentarse. Tampoco sé qué control tiene el procesador sobre ella.
- Creo que algunas CPU's tienen un firmware (por llamarlo de alguna manera, una memoria con datos permanentes que se puede sobreescribir) con las microoperaciones de cada instrucción.
- Lo de aterrizaje de pistas, supongo que podría seguir vigente si pudiéramos acceder al firmware del HDD.
- Usar el láser del modo de grabación para destrozar la superficie de discos con información.
¿Qué opinan? ¿Es posible?

Gracias MCKsys, conozco ese sitio, pero no tengo buenas impresiones de él. Además según tengo entendido es para B2B, o sea, no sé si podría comprar ahí por lo que puse en el primer post.
¿Tú has comprado en esa web? si es así, ¿qué opinión te merece?

Hola, me pareció muy interesante tu post, así que me lié a buscar información, y estas son mis conclusiones:

Lo primero es que veo mucho, demasiado oscurantismo alrededor de encontrar información interna del cacharro ese, llegué a pensar que no usaba un microcontrolador. Se ve que a la empresa no le interesa dar mucha información sobre cómo está hecho el parato. Este enlace es fundamental, contiene fotos de uno abierto, de donde puedes sacar que chip es: http://www.mpc-forums.com/viewtopic.php?f=21&t=53199&start=15
El chip es 6417727F SH3-DSP 160V, de ahí googleas y ya te da que es de la casa Renesas.
De ahí sólo te queda buscar el datasheet y el manual de la página:
http://www.renesas.com/products/mpumcu/superh/sh7700/sh7727/device/HD6417727F160CV.jsp
Efectivamente es un SH7727
Ahí tienes un manual de 1000 páginas que lo explica todo, al menos todo lo que puede. Esa debería ser tu guía de estudio.
El formato de un firmware, el .bin por ejemplo, suele ser una imagen de la memoria, de la memoria ROM, es decir ese fichero se graba como tal en la ROM, luego leyéndote el manual aprendes cómo arranca y cómo mapea esa memoria en su espacio virtual de direcciones (y su ensamblador). El otro lleva una extensión diferente, no tengo ni idea de qué es. En todo caso no son formatos ejecutables, eso creo, es decir, los firmwares no son ejecutables, simplemente se flashean a una memoria ROM, que luego al arrancar el chip se mapea en diferentes direcciones. O sea, más bien te interesa saber con qué programa lo flasheas y cómo lo hace, ahí tienes esa parte de la información.
Tengo que decirte que si quieres aprender ing. inversa este es un método fabuloso, aprenderás mucho, pero tardarás bastante en lograr tu cometido, la meta es algo lejana, y más si no sabes de informática y de estas cosas.
Lo último, una idea, si sigues con ello, podrías hacer un sistema operativo alternativo a esto, creo que esto del oscurantismo viene de la tajada que están sacando con ese firmware que lleva un precio tan desproporcionado para lo que es. Desde luego sería un proyecto con el que podrías llevarte algo de fama, o dinero si lo haces bien. Según he leído, ese sistema no tiene alternativas ni competidores.
Preguntas que en que lenguaje se programó, mi apuesta es que seguramente C con ensamblador por supuesto. En la página de Renesas puedes encontrar software, compiladores, emuladores, etc, supongo como en todas. Es Akai la que le interesaba ocultar que lleva dentro, pero sólo hay que abrir el cacharro y mirarlo, en todo caso ahí lo tienes hecho.
Saludos, hacía mucho que no pasaba por este foro y este post en ing. inversa me ha resultado muy grato.

Hola, estaba buscando comprar un sensor CMOS como el que llevan las cámaras digitales para percibir imágenes. El caso es que no tengo ni idea de cómo conseguirlo, he buscado y buscado y no he encontrado nada que me convenciera. En las típicas tiendas de DIY y cosas de esas directamente no hay o poca variedad.
Hay webcams realmente baratísimas, aunque he mirado en alguno de sus documentos de descripción del producto y no dicen que chip llevan(que debería ser más barato aún que la propia cámara).
En las webs de fabricantes, Samsung, Aptina, Cmosis, tienen unos distribuidores certificados o algo así, pero estos a su vez no veo la manera de poder comprar como individuo. No entiendo mucho de estos entramados empresariales. Quiero decir por ejemplo, en algunos casos no ponen precio, y tienes que rellenar un formulario donde tienes que poner que empresa eres, en otros casos ves que tienen una cantidad mínima o un gasto mínimo de 500 euros y cosas así.
No tengo ni idea de cómo conseguir una de estas piezas sin tener que comprar la webcam baratita y desarmarla (con el riesgo de que no descrubra que chip es o no tenga documentación en la red, o que no esté apropiada para conectarla a mis deseos).
¿Alguien sabe como hacerse con un cacharro de estos online? ¿Cómo lo hacen las universidades?
Gracias.

Ya avancé algo más, estaba empacado con Xenocode. Logré extraer los ensamblados .NET, ahora necesito modificarlo, pero me pasa una cosa, al desensamblarlo con cualquier programa los nombres de métodos, clases, etc, se ven con una interrogación, lo que hace que no recompile(puesto que todos se llaman igual). No sé cómo puedo seguir.

Hola!
A ver si pueden resolver mi duda
Qué puedo llegar a hacer con VHDL? Siempre tuve la duda de si con VHDL puedo llegar a construir un microprocesador, porque es algo que me gustaría. Sólo sobre plano, digamos. Es decir, no conozco muchos proyectos de microprocesadores libres, por que? por que no hay algo estilo linux que haga procesadores económicos y con técnicas modernas?
Mi pregunta es si VHDL resuelve todos los problemas que se plantean al construir un micro, es decir, si todo lo que pueda hacer con VHDL o algun lenguaje de estos se puede trasladar directamente a una oblea de silicio sin más problemas.
Bueno, quizá debería empezar preguntando para que sirve exactamente VHDL...
Saludos.

Hola, estaba intentando reversear este programa y lo he atacado por diversas partes y no se me ocurre que hacer
He probado:
- Debuguearlo en .NET, el caso es que Reflector no lo carga, dice que no es un assembly válido, en realidad es un ejecutable pero en el fondo es un .NET. No estoy muy ducho con estas cosas, es de la versión 2.0 del framework y pude cargar el programa en el Mdbg a pelo, ayudado por olly. Sin embargo no pude meterlo en calimero, ni ningún otro. No se a que se debe esto, es como si fuera un ejectuable que guarda un ensamblado .net dentro. Está claro que si pudiera extraerlo todo  sería mucho más fácil.

- Usa una mochila FAST hardlock de Aladdin, intento atacar por la dll de hlvdd.dll pero me parece muy osado por mi parte. He conseguido menos aún, ni siquiera logro que llame a HlLogin, sólo a Hlinit

- No encontré muchos tutoriales de crackeo bajo .net, algunos sí, pero ninguno cubre mi caso, es decir algo que está como encerrado dentro de un ejecutable.

- No puede ser muy moderna la protección pues el programa es del 2008.

¿Alguna orientación? Sobre todo me interesaría aprender a crackearlo por la parte de .NET, lo de las mochilas me interesa pero no tengo nivel ni la mochila propiamente para experimentar.

Gracias.

Genial, justo es eso. Gracias Eternal.

Hola
Mi aplicación utiliza un fichero xml cuya última versión está en un server http, cada vez que es actualizado quiero descargármelo pero no siempre pues es voluminoso.
¿Saben de alguna forma para comprobar si un fichero en una web ha cambiado? ¿Se les ocurre alguna forma de hacerlo sin tener que descargarme el fichero ni implementar otro servicio/fichero en el server?