Mirando extrañado por qué a veces me permitía Excel 2007 poner contraseñas de un tamaño u otro acabé mirando como almacenaba la contraseña de escritura. Realmente eliminar esa contraseña tiene poco impacto en la seguridad, pero no deja de ser curioso. Además, algo que llama la atención al mirar los tres formatos de documentos principales (xlsx, pptx, docx), es que las contraseñas de escritura se almacenan en distintos elementos y de forma distinta.
En Excel 2007 es en el archivo xl/workbook.xml y en el elemento:
[fileSharing userName="Chema" reservationPassword="C7F0"/]
En Power Point 2007, tras echarle un ojito, la password de escritura se almacena en el fichero ppt/presentation.xml y en el elmento:
[p:modifyVerifier cryptProviderType="rsaFull" cryptAlgorithmClass="hash" cryptAlgorithmType="typeAny" cryptAlgorithmSid="4" spinCount="50000" saltData="Xx6HJBnD5fz8U/JNdkRfCg" hashData="lhvRS29IYY/PrYlQuQjkaP8RZPE" cryptProvider="" algIdExt="0" algIdExtSource="" cryptProviderTypeExt="0" cryptProviderTypeExtSource=""/].
Ni puta idea de como gestiona los parámetros y para que los utiliza, tendré que leerme el estándar OOXML, pero lo que sí es evidente es que no parece usar la misma estructura que en los ficheros xlsx.
ppt/presentation.xml en el fichero pptx
El caso es que borrando ese elemento el fichero pierde la contraseña de escritura. En el docx, sucede lo mismo, pero el fichero vuelve a cambiar, en este caso es doc/settings.xml y el elemento es:
[w:writeProtection w:cryptProviderType="rsaFull" w:cryptAlgorithmClass="hash" w:cryptAlgorithmType="typeAny" w:cryptAlgorithmSid="4" w:cryptSpinCount="50000" w:hash="B83Aa09Xmlw1MgFZtqovrzxpKok=" w:salt="R4UpJlcEjWhQxkxRj2CJ8g==" /]
En este caso, aunque los atributos no son exactamente iguales sí que se parece mucho más a como funciona pptx.
doc/settings.xml en el fichero docx
Bueno, esto no deja de ser más que una curiosidad, ya que si se pone la password de lectrua... todo esto no tiene sentido ninguno y no se puede ver nada del fichero... pero tiene cierta gracia, .... En fin, en lo que pierdo el tiempo por tener la contraseña más larga que el espacio que me dejaban.
Saludos Malignos!
Off topic:
ResponderEliminar----------
Joder, parece que he estado en otra galaxia. El tema del bug Excel sale hasta en la sopa.
Muy importante para aquel a quien le interese:
Este documento de Chris Lomont aclara absolutamente todo lo ocurrido. En la página 15 viene la explicación (el fallo se da cuando EAX contiene xFFFF. Ocurre porque cuando se produce desbordamiento en registro EBX, hay un incremento de EAX. El incremento en 16 bits (inc ax) no se comporta exactamente igual al incremento en 32 bits (inc eax) y el resultado es un error en una bifurcación posterior.
Respecto a las comprobaciones de Spectra validando todo tipo de funciones lo más probable es que se limitaran a código VBA o similar (.NET, C++), pero que comprobaran valores de celdas por lo que no podrían haber detectado el bug.
Ahora bien ahora mismo no me atrevo a decir ninguna de estas 2 cosas:
1-Para poder decir si es un error de bulto o no hay que entender completamente el documento anterior y eso requiere mucho tiempo.
2-¿La ventaja del software libre podría ser la de cuatro ojos ven más que dos? No he trabajado en ningún proyecto de software libre, pero si alguien me quiere dar su opinión se lo agradezco.
Saludos.
Alguien tenía que decirlo: ¡Qué suerte que el ISO no aprobó un formato tan rebuscado!
ResponderEliminar@mikelats, a bajo nivel el problema es complejo, pero habría que ver cuales han sido las líneas de código a alto nivel, pq seguro que se verá mucho mejor el fallo. La pregunta 2...es equivalente a abrir un flame... ;)
ResponderEliminar@iceman, el objetivo de la ISO es aprobar estandares, así que, como ya sabes, tenemos a principio de años la BRM dónde ese deben aportar ideas para poder estándarizarlo. Todo a su tiempo, no obstante, siendo ECMA, ya es un estándar abierto, así que no hay ningún problema.
Saludso!
[offTopic]Texto antiguo seguro que habeis leido, pero interesante[/]
ResponderEliminarCyberInsecurity: The Cost of Monopoly
http://cryptome.org/cyberinsecurity.htm
@sirw2p, interesante, no lo había leído. Cuidado, que no nos oiga el maligno ;-)
ResponderEliminartranquilo mikelats el texto esta encriptado solo unos pocos pueden leerlo :P .
ResponderEliminarNo deja de ser curioso como forma de eliminar una pass de escritura..que sí, quel o normql es poner una de lectura, pero el infeliz que ponga una de escritura por algún motivo pensando que el documento así queda protegido...vaya chasco!
ResponderEliminar@sirw2p, la conspiranoia!! Sed buenos chicos!
ResponderEliminartu lo que no sabes es que cuando abres con el notepad un archivo con contraseña. no se ve ese codigo sino que se ven signos y letras extraños. LISTO
ResponderEliminarHola anónimo listo!, leete el post, que dice, contraseña de escritura, no de lectura, te explico como funciona?.
ResponderEliminarSaludos del "LISTO".
PD: ¿Te crees que he trucado todas las capturas amiguete?....
tengo un ppt con contraeña de escritura y me estoy reventando la cabeza porque no la puedo eliminar, necesito modificar urgente ese documento, espero me puedas ayudar gracias! "jechu_31091@hotmail.com"
ResponderEliminarAl cmbir el nombre al archivo.pps a archivo.pps.zip sale u mensaje de alerta, que el archivo puede quedar inutilizado.
ResponderEliminarLuego cuando intento descomprimirlo sale que el archivo esta dañado.
Porque no funciona el procedimiento.