Crear Un Parche Universal Para Rips Autoboot Con Exploit

Restale 150 sectores y veras que el fallo esta en el sector 22 de la imagen (los 150 primeros, son el pregap y cdmage, cuenta a partir de ahí) . Arranca cdgenps2 y mira el LBA que te pone al inicio y entenderas lo que quiero decir. El problema es que estais jodiendo la estructura que almacena los datos sobre los ficheros del directorio raiz del CD.

No me he leido el hilo, pero teoricamente, lo que quereis hacer es cambiar el SYSTEM.CNF para que autoarranque con un disco PSX , no?. Entonces deberiais tener en cuenta estos detalles: un sector tiene una capacidad de datos de 2048 bytes y los ficheros no comparten LBA (salvo que lo hagamos aposta, claro) Y 2048 bytes es mas que suficiente para el SYSTEM.CNF, claro.

¿entonces? ¿como hay que proceder? Pues es bien sencillo: primero, necesitamos leer la imagen desde el cd a modificar, con el CloneCD. Si usais Clone, el fichero IMG contiene todos los sectores de la imagen con los 2352 bytes necesarios (es decir, con ECC y EDC). La idea ahora es que hay que buscar la palabra SYSTEM.CNF en el LBA 22 y leer la longitud y el LBA adonde apunta. Leemos ese LBA (seria leer en el fichero en la posicion LBAx2352) y despues reescribimos unicamente ese 'sector' con los datos del SYSTEM.CNF nuevo (no debe pasar de 2048 bytes, claro). Ya solo nos queda ajustar la longitud del SYSTEM.CNF en el LBA 22. Todo esto se puede hacer abriendo el fichero para lectura y escritura, sin necesidad de duplicarlo.

Luego está el tema de la correccion de ECC/EDC en esos sectores. Si no me equivoco, el propio CloneCD tiene capacidad para reparar eso al tostar y en todo caso, se pueden regenerar.

Para tostar, seria renombrar ese fichero nuevo creado a IMG y utilizar CCD y SUB que nos generó al leer o crear un cue y tostar con NERO, segun preferencias

Tambien se puede usar ISO. Si extraes ISO directamente, manejas los datos utiles del sector. Los calculos entonces son LBAx2048, por supuesto. Entonces podriamos usar CDRWIN para crear la imagen a CD-XA. Si alguno lo recuerda de los viejos tiempos de la DC, Cdrwin tiene la capacidad de pillar una ISO (2048 bytes sect) y tostarlo a XA generando los EDC, etc por si mismo

P.D: no se si alguno se dio cuenta, pero en la iso 1.28 del Mediaplayer hay una version de cdgenps2 que corrige el fallo de los LBA 0 a 15 y al fijar LBA de un fichero.

Varias cosas:

Gracias por tu colaboracion a este proyecto, Hermes.

Respecto a extraer con imagenes de ccd, o de iso, pues no esta mal, pero el problema es que partimos de imagenes bin y cue, porque nos resultan "mas manejables", tu ya me entiendes...

El punto en el que nos encontramos es que el PARCHEADOR de guarroman0 ya cumple perfectamente con su labor. Añade la linea que necesitamos, y aumenta el tamaño del system. Todo ello sin necesidad de abrir el bin, ni usar isobuster para extraer nada, ni na de na.

El system no siempre se encuentra en el LBA 22, o en el comienzo, sino que dependiendo del bin, unas veces esta en una posicion y otras en otra.

El problema es que despues de aplicar el parcheador, siempre se nos producen un par de errores y nos gustaria que esto no fuese asi, para no tener que emplear cdmage o eccregen.

Respecto a los errores, tienes razon, a estas alturas ya esta comprobado... Uno de ellos corresponde al LBA 22, o como tu bien explicas 150+22 = sector 172. Este error es comun para todos los bin parcheados y da igual en que posicion esta el system.... pero ademas hay un segundo error que se produce en uno u otro sector, y sospecho que este si depende de la posicion lba que tenia el system antes de parchear.

Nos limitamos asi pues a añadir una entrada en el system, y modificamos su tamaño, pero seguimos dependiendo de eccregen o cdmage, y nos gustaria que no fuese asi.

Respecto al resto, lo de los 2048 bytes y demas, algo sospechaba yo, al descubrir modificando los system de forma rudimentaria, que en realidad no aumentaban su lba, sino que aunque yo aumentara su tamaño en 30 bytes, la posicion seguia siendo la misma.

Del resto ni idea, seguro que zeroday o guarroman0 entienden mejor que yo tus palabras... Sigo siendo bastante negado para estas cosas.

Una cosa mas... Creo, y repito CREO, que en realidad nos podriamos saltar el paso de ECCRegen o CDMage, sencillamente tachando la casilla modo RAW en cdrwin, pero como el modo RAW no es compatible con todas las grabadoras, pues seria interesante crear el parcheador lo mas "STANDAR" posible.

Para el resto, repito: Confirmado, EL PRIMER ERROR esta siempre en sector 172, EL SEGUNDO parece que depende del lba del system...

Pdta.: Dead to Rigths by warblood, imposible de autobotear, ni con parcheador ni manualmente (no tiene relinks)... tiene un system un tanto "peculiar"... ¿alguien lo ha conseguido?, yo como mucho arranco cogswaploader con el pulsando select y despues x para arrancarlo, pero del tiron no va como el resto....

Quiero felicitar a los creadores del parche y a los que trabajan para mejorarlo y me gustaría aportar mi granito de arena en la parte que pueda, empezando con algunos comentarios.

Si siempre salen 2 errores de ECC/EDC está claro que es porque se el parcheador este modifica la imagen en 2 sitios:

- el LBA 22, donde se encuentra siempre la información del "directorio raiz", para cambiar la longitud del system.cnf modificado.

- el LBA del system.cnf, por motivos evidentes

Según tengo entendido, el ECC/EDC son unos pocos bytes al final de cada "sector", con información de chequeo y recuperación de errores para ese "sector", por lo que si modificamos 2 "sectores" la solución es regenerar el ECC/EDC a partir de la nueva información del "sector" y reescribirla encima de la información antigua. Supongo que el algoritmo para calcular ECC/EDC será público ¿no? Intentaré buscar algo por internet...

Aunque no los conozco muy bien, sé que hay otros parcheadores de imagenes para PS2 ¿ninguno regenera el ECC/EDC? ¿no hay fuentes?

Un punto que supongo que será sencillo de mejorar, es la busqueda del system.cnf dentro del bin/cue, que parece que ahora mismo recorre la imagen de principio a fin, hasta que encuentra el system.cnf. Si este está al final, puede tardar unos minutos... ¿Por qué no leer el indice del LBA 22 y saltar directos al LBA del system.cnf? Supongo que allí estará la información del LBA también además de la longitud ¿no? Y si no, ¿como hace Isobuster o cualquier otro gestor de imagenes para sacar la información?

Y por último, digo yo que habría que mirar la opción de usar CDRWin para que al grabar fuese regenerando el ECC/EDC, que puede ¿no? ¿Y Fireburner también, no?

Si voy descubriendo cosas aviso por aquí

Por cierto, esta web igual os es de utilidad, entre otras cosas habla de los formatos "mode 2" y viene un algoritmo GNU de cálculo de EDC (es un dato tipo CRC de 4 bytes solo, haciendo XORs con una tabla se consigue)

http://www.wsu.edu/~benp/mcfcd.htm

He visto más algoritmos como este, buscando en programas GNU con código abierto, en particular aquellos que generan imagenes de VCDs, que se generan también en modo 2...

Del ECC no he visto nada, pero tampoco he buscado mucho. ¿El ECC lo genera la grabadora al tostar la imagen? Igual por eso no encuentro nada ¿Se puede ignorar entonces y esperar a que la grabadora lo regenere?

Primer error grave...

El parcheador no ha podido con FIFA 2003 PAL.... Dice que el bin esta siendo usado por otro programa ¿?

Estrayendolo todo con isobuster y generando con cdgen, tambien plantea dificultades.... Cdgen se cuelga intentando componer la imagen cuando lleva unos 28mb

En el caso de Dead to rigths tiene un system peculiar, y por eso puede ser el error, pero en el caso del FIFA todo parece en su sitio....

Como mola... parece que el hilo vuelve a las andadas...

Quiero agradecer a Kyke y a Hermes su interés en este proyecto.

En cuanto pueda le echaré un vistazo a la página que menciona Kyke en su último mensaje pues si es cierto que hay un algoritmo GNU para el cálculo de los códigos lo incorporaré el programa.

Y por supuesto la mejora de la que hablas (no mirar en toda la imagen) es algo que tenía pensado incorporar en breve.

Y en cuanto a lo del FIFA ????? no sé que pasa... trataré de averiguarlo.

Guarroman0, anoche estuve mirando un rato el tema del formato ISO con un editor hex y es muy sencillo de interpretar las entradas de un directorio, así puedes ir al LBA 22 y recorrer todas las entradas hasta el "system.cnf;1" y te aparece la longitud en bytes (algo que ya has visto) y el LBA inicial del fichero, con lo que el segundo paso es automático

"Descubrí" algo curioso, que los datos de longitud y lba-inicial de cada entrada aparecen dos veces!, 4 bytes por cada uno, una vez en formato big-endian y otra en little-endian. Supongo que por eso cuando parcheas la imagen el Windows te da una longitud y el Isobuster te da otra (uno mirará uno y el otro mirará el otro). Deberias corregir ambos datos de longitud .

También me fije en tu código del parcheador y he visto que lo que haces es buscar la cadena "BOOT2" en toda la imagen... me parece que este es el primer punto a mejorar, con las modificaciones de arriba

Yo no tengo idea de programación en windows, pero si quieres yo podría hacer (en cuanto tenga una tarde libre) un programita sencillo en C standard que parcheé de forma inmediata el system.cnf, eso si desde MS-DOS, y que alguien prepare una GUI cómoda de uso al estilo del parcheador actual. O le paso el código C y que se incluya todo un mismo programa. ¿Se puede meter una rútina en código C en Visual Basic? Además a partir de aquí se puede compilar para Linux, para usar desde la shell. Si quieres podemos seguir hablando de estos detalles por email, para no aburrir a los foreros

Otra cosa es que en la mayoría de los casos no es necesario regenerar el EDC/ECC, porque las grabadoras de CDs generalmente ignoran esa información y lo generan automáticamente a la hora de tostar. Creo que esos datos se usan únicamente a la hora de leer el CD, y es directamente el firmware de la unidad el que detecta e intenta corregir los datos...

Esto lo digo porque parcheé una imagen y la tosté sin regenerar el EDC/ECC; al volver a leer la imagen tostada, resulta que no habia errores de EDC/ECC, mientras en la imagen antes de tostar si que habia en LBA 22 y en el del system.cnf

Con esto quiero decir que se debería probar hasta que punto es necesario el proceso de regeneración... hace unos años está claro (según la web del eccregen) que habia varios modelos de grabadoras que no regeneraban esos códigos, pero hoy día debe ser algo más standard Yo tengo una LG 52x de esas baratas y perfecto.

Y en último caso, cómo la información del EDC/ECC es por sector, sólo queda "sin protección" el sector de la carpeta raíz y el system.cnf, quedando el 99.9% del disco "protegido".

Escrito originalmente por Africa
Primer error grave...

El parcheador no ha podido con FIFA 2003 PAL.... Dice que el bin esta siendo usado por otro programa ¿?

Estrayendolo todo con isobuster y generando con cdgen, tambien plantea dificultades.... Cdgen se cuelga intentando componer la imagen cuando lleva unos 28mb

En el caso de Dead to rigths tiene un system peculiar, y por eso puede ser el error, pero en el caso del FIFA todo parece en su sitio....

¿Usado por otro programa? ¿Has probado a reiniar Windows? Suele funcionar

Yo no tengo el FIFA, pero si da errores al reconstruir será porque tenga ficheros "enlazados" o algo de eso ¿no? ¿Has mirado si te ocupa más la carpeta una vez extraido todo con Isobuster que la propia imagen?

Y del otro juego ni idea ¿que system.cnf tiene que sea peculiar?

Lo de k esta siendo utilizado por windows en fin cosas del windows, reinicia y ya ta.

Si no tengo mal entendido las grabadoras no regeneran los ecc/edc cuando escriben en RAW DAO en los otros creo que si aunque a lo mejor no chutaría el bakup

A ver si te pasas el system.cnf pa que lee heche un vistazo o por lo menos lo podrías copiar y pegar akí.

Si keréis mirar codigo de ecc/edc, el cdrecord de linux lo tiene creo.

Supongo que en "RAW DAO" igual grabará el EDC/ECC de la imagen... otra cosa a probar Yo grabé ayer con "DAO / SAO" en el Alcohol 120%, y la imagen funcionaba en la PS2 con el xploit y chip USB externo.

Que no, que no.... Que con FIFA no hay manera, ni desmontando la imagen y haciendolo manualmente. Respecto a ser usado por otro programa, es que no esta siendo empleado por ningun otro programa.... Ni reiniciando, ni nada, es mas, me deja eliminarlo, cambiarlo de sitio o lo que quiera.... Es decir, NO ESTA SIENDO UTILIZADO POR NADA. Lo que ocurre es que el parcheador dice que si.
Algo tiene ese bin (espero que sea el unico) puesto que no me deja ni con cdgen.... Se queda colgado cuando intento crear el cd en unos 28,7 mb... Da igual las horas que pasen...

Respecto al system "rarito" te lo pego aki, corresponde como ya dije a DEAD TO RIGHTS de Warblood. En realidad lo que tiene de raro es que tiene todo igual que todos, pero en una sola linea. Pero a este bin, tambien le ocurre algo, puesto que haciendolo manualmente y corrigiendo yo lo de las lineas tampoco arranca del tiron. Aunque el rip no contiene relinks, ni en hex ni normalitos, no me estrañaria ni un pelo, que el colega Sdestroyer hubiese hecho de las suyas con el, y por eso los problemas, aunque esto es solo una suposicion. Mas que nada, porque warblood dice que es su primer rip, y no me estrañaria que siendo colegas, susho le hubiese echado un cable.

System original:

BOOT2 = cdrom0:\SLES_515.81;1 VER = 1.00 VMODE = PAL

System modificado por parcheador:

BOOT = cdrom:\SLES_031.46;1
BOOT2 = cdrom0:\SLES_515.81; VER = 1.00 VMODE = PAL

Resultado, solo funciona si pasas por mcloader con start, o por cogswaploader pulsando select, pero si lo dejas tal cual, despues de exploit te devuelve al navegador de la consola mostrando cd de psx.

System modificado manualmente por mi a la vieja usanza:

BOOT = cdrom:\SLES_031.46;1
BOOT2 = cdrom0:\SLES_515.81;1
VER = 1.00
VMODE = PAL

Resultado, lo mismo que el anterior, pulsando start o select si, pero del tiron no.

Una cosa curiosa que acabo de descubrir... al copiar y pegar sobre estas lineas queda algo asi:

BOOT = cdrom:\SLES_031.46;1
BOOT2 = cdrom0:\SLES_515.81;1

VER = 1.00

VMODE = PAL

Resulta cuanto menos chocante, porque en mi pc lo veo correctamente, este y todos los demas, sin embargo al pegarlo aki, se produce una separacion de dos lineas, en lugar de una que es lo que yo veo en el cd....

Para África:


He encontrado cuál es el problema con el FIFA...
resulta que la búsqueda del sector en mi programa es de lo más cutre, se basa simplemente en la búsqueda a lo bestia de la cadena "BOOT2=" en toda la imagen y esto como dice kyke es mejorable en tiempo pero, es más, para el caso del FIFA es necesario cambiar este método de búsqueda pues da la casualidad que hay una secuencia de bytes en otro sector previo al del system.cnf que tiene una cadena igual a "BOOT2"...

Lo he comprobado rápidamente cambiando la cadena de "BOOT2" a "BOOT2=cdrom" pero esta no es la manera de hacer las cosas, lo que hay que hacer es lo que dice kyke:

Guarroman0, anoche estuve mirando un rato el tema del formato ISO con un editor hex y es muy sencillo de interpretar las entradas de un directorio, así puedes ir al LBA 22 y recorrer todas las entradas hasta el "system.cnf;1" y te aparece la longitud en bytes (algo que ya has visto) y el LBA inicial del fichero, con lo que el segundo paso es automático

que trataré de implementar cuanto antes.

Por cierto kyke muchas gracias por la inestimable ayuda que nos estás dando, sobre lo del programa en C estaría genial pero bueno, prácticamente ya lo tengo hecho en VB... te lo dejo a tu elección, lo de meter código en C en VB creo que no es posible pero es muy fácil llamar a un programa externo (GUI)

África, aguanta un poco o pégame un toque

África, aguanta un poco o pégame un toque

Resistire


Me alegra ser util, "monstruos", aunque solo sea como "betatester".

Como ya dije antes, se trataria de encontrar un parcheador lo mas universal posible.... y al hilo de esto... ¿funciona con todo tipo de imagenes, o estamos limitados a bin y cue?

Africa, no tengo ni idea de como va ese system.cnf Es la primera vez que lo veo todo en una linea, aunque la verdad es que no suelo fijar mucho... ¿has probado a poner a mano todo en una linea igual, añadiendo el "boot = " al principio de la linea original y separando con un ";" al final?

Y para los "saltos", igual es por el editor de texto que uses, si está en formato Unix el fichero te lo muestra como si fuera modo msdos, pero al copiar/pegar lo hace tal cual ¿? Miralo con un editor hex o algo parecido y fijate en los código de saltos de carro y retorno de página (0x0D y 0x0A creo).

Guarroman0, no pretendo que sea a "mi elección", que yo soy un invitado personalmente me parece que será muy sencillo y rápido hacer en C lo que se tiene ahora (con los detalles que quedan por pulir), y a la hora de incorporar nuevas funcionalidades también es un punto a su favor. También es verdad que no tengo idea de VBasic, ni ganas de aprender, y poco puedo ayudar en el tema programación en ese caso, y tampoco tengo un tiempo fijo que pueda dedicar a colaborar en un equipo multiprogramación... igual me pego 2 semanas con mucho tiempo libre, igual no paro en un mes ni para leer emails... No sé como andais vosotros de C, pero yo creo que me voy a animar a hacerlo cuando pille unas horas "libres"... aunque sea por matar el gusanillo que tengo con este tema Si resulta que sale bien y os animais a hacerle una GUI, pues c*j*nud*, y si no, pues siempre tendremos el actual ya mejorado.

Y respecto a la "universalidad", por una parte en C se podría compilar para DOS y Linux y cualquier otra cosa que se quiera (sin GUI).

Los formatos de imagenes BIN son muy similares (o iguales?) a las IMG del CloneCD o Alcohol y parecidas a las ISO... al fin y al cabo son los sectores de 2048 bytes los que nos interesa, y cada formato de estos lo único que hace es "adornar" estos sectores con algo más de información... por lo que el parcheador podría extenderse facilmente para soportar esos formatos de imagenes.

Si es valido para linux y para dos y para lo que sea pues miel sobre hojuelas...

Lo que yo queria decir, es que fuese valido para cualquier tipo de rip, que como ya explique al principio del hilo, yo he encontrado tres modelos distintos. Y que ademas seria interesante que fuese la imagen que fuese el parcheador cumpliese su labor.

Todo ello contando que el parcheador lo hiciese todo, es decir, parchear y ademas corregir los sectores defectuosos.

No se, ya parto de la base de que yo en programacion ni idea, y quizas lo que quiero es la luna... En fin, eso esta en vuestras manos, como ya he dicho, solo puedo hacer de betatester y poquito mas. Por mi parte ya me doy con un canto en los dientes tal como esta.... que tu no sabes lo que es hacer un autoboot manualmente si el rip es de sdestroyer.....

Respecto a añadir manualmente todo en la primera linea, me pondre ha ello mañana, ya lo pense... aunque tarde... despues de tres copias.... Hare una cuarta, pero mas bien, parece algun tipo de anti boot de zeroday, por asi llamarlo. Arranca con mcloader, arranca con cogswaploader... y sin embargo con dloader de zeroday no....

Parecido lo he visto yo este fin de semana en una v8 con mcloader, o con action replay usando un usb... siempre nos tiraba fuera, y por supuesto con dloader tambien.... Gracias a Hermes y su cogswaploader la cosa tuvo arreglo..... Por cierto, por si a alguien le interesa, Confirmado, se puede instalar en una v7 o v8 un usb sin tener que depender de swap magic... gracias a Hermes. En este caso, los autoboot no son tal, puesto que hay que pasar por cogswaploader, pero no hace falta cambiar el cd, simplemente pulsar x.
Creo que podre probar en una v9 y os cuento...

Un par de cosas:

Fifa rulando ok... gracias guarroman0.

Y la segunda:

Otro mas para analizar, y van muchos ya.... En este caso se trata de Italian Job distribuido por Enesbe segun un rip de CHRONIC. Ocurre como con el que os contaba, y con otros.... Arranca pero te manda al navegador de ps2. La manera de arrancar es pasando por mcloader o por cswaploader, ya sea pulsando start o select (en mi caso, claro, esto es configurable...)

Cada vez estoy mas convencido de que el problema es de dloader de zeroday... Molaria una version mejorada, que se basase en cogswaploader, solo que sin tener que ver menus ni pulsar x, ya que parece ser que cogswaploader se lo salta todo, todo y todo. Otra vez gracias a Hermes, y no me canso.

Algo tiene dloader (desconozco en que otro programa se basa) que no consigue engañar a la consola en todas las ocasiones. Con la mayoria si, pero en cada vez mas casos, falla en algo, y no parece que sea el parcheador.

De hecho, el parcheador cumple su cometido, que no es ni mas ni menos que arrancar exploit. Pero algo falla con algunos juegos, que no parecen compatibles con dloader4.

Zeroday, abandona tu retiro y haznos una visita. Te invitaremos a un cafecito y charlaremos amigablemente... Trae tu los pasteles y una nueva version de tu maravilloso invento.

Sigo testeando, por cierto... ¿si quemo un bin sin corregir los ecc y funciona, quiere decir que funciona, o puede cascar a lo largo del juego?

Lo mirare a ver, heche un vistazo al codigo del cogswaploader y no procesa el system.cnf sino k simplemnete resetea la consola con el system.cnf, lo raro es k no cargue otra ves el xploit ¿?Africa prueba con uno k vaya directo pero pasando por el cogswaploader a ver si te carga el juego u otra ves el xploit.Lastima k no tenga ningun juego de esos k no chutan pa probar

Eso ya esta probado, de hecho lo he vuelto a probar para asegurarme. Carga el juego, sin problemas, en todos los casos. Da igual si es directo o es de los conflictivos. Pasando por cogswaploader rulan todos.

Es mas, como ya he explicado en otro post... Funciona incluso con las v7 y 8.... Sin tener que hacer cogswap. Los directos, en esas consolas, con tu dloader no rulan. Arranca exploit, se ve tu pantalla y directamente te sale el famoso pantallon rojo con introduzca disco de formato.... Sin embargo, si en vez de tu dloader empleo el cogswaploader entonces sin problemas. Arranca cogswaploader, pulsas x, y a jugar.

Al hilo del tema, mas cositas curiosas acerca del programita de Hermes. O mucho me equivoco o en el caso de los dvdrs, se pasa por el forro el tema del TOC. Segun tenia entendido, no se puede arrancar mediante cogswap un dvdr mayor que el original empleado. Pues bien, con cogswaploader he cargado el ffx con un f1 2003 original. Segun las listas de toc que circulan, el f1 tiene apenas 3 gigas si llega, y en cambio ffx tiene mas de 4.
Antes ya me habia dado cuenta, puesto que lo arrancaba con metal gear, que tambien es mas pequeño, pero en este caso la diferencia es minima... En el caso del f1 o mucho me equivoco o la diferencia si que es abismal.... y sin embargo lo arranca.

No es la primera vez que el colega Hermes nos ilumina con sorpresas de este estilo, asi que no se que pensar.

Pos na entonces nueva vers dentro de poko
PD:He repasao el cogs y si k procesa cnf.

Bueno, entonces parece que los "system.cnf" raros y algunos rips que no cargan, debe ser por el dloader, no por el sistema de "parchear" para arrancar el xploit. Es un alivio. Esperemos que zeroday saque pronto una nueva versión y no tener que andar con varios loaders en memoria

Y lo que comentas de los DVDs con el TOC más pequeño, es posible que un DVD-R de TOC mayor arranque usando uno original de TOC más pequeño, pero en algún momento del juego se acabará parando, en el momento que tenga que leer "por encima" de ese TOC menor... Si los ficheros de arranque, system.cnf, el SLES, o cualquier otro... se encuentran "por encima" de ese TOC es cuando se cuelga "al arrancar", si no se colgará después.

Mas pruebas:

El sistema no es compatible con los mandos BLAZE de autodisparos y similares.... Probare hoy mismo con volantes y pistolas y demas....

En realidad esto casi que nos da exactamente lo mismo, puesto que se supone que todos tenemos el dual shock original...

Sigo testeando y trasteando....

Hasta donde he podido probar, funciona con todas las pistolas, y volantes a mi alcance. Tambien rula con mandos psone dualshock. Faltaria probar con los primeros de psx, los que no tenian palancas analogicas.

En fin, que hasta el momento todo ok, excepto con un mando BLAZE DUALSHOCK PLUS, que se queda clavado con la pantallita de zeroday.

¿Damos por concluido el hilo y el tema?
¿Va a haber cambios de importancia o yasta todo bien como esta?

Africa, ¿me he perdido algo o te has confudido de hilo?

Los rips autoarrancables mediante exploit + dloader4, no funcionan si el mando conectado al puerto uno de ps2 es el BLAZE DUALSHOCK PLUS, uno de estos mandos que llevan funciones de autodisparo y demas. Con todos los demas mandos y artilugios que han caido en mis manos, funcionan ok, sin incidencias.

Yo creo que si que tiene relacion con lo que tratamos....

Por cierto, he visto tu post de casualidad.... No he recibido notificacion mediante mail... Esto si que no tiene mucha relacion con el tema.

Por mí... a otra cosa mariposa.

Lástima no llevar a la práctica las últimas ideas de kyke... pero en mi caso es que ahora tengo un aluvión de curro y no puedo liarme.

Venga, un saludo a todos

Si me pillara una tarde inspirado y con poco curro lo haría. Avisaré de ello por aquí.

¿Que pasó con el "system.cnf" de una linea? ¿Se consiguió auto-arrancar de alguna forma? ¿Con el cogswaploader tal vez?

Eso ya esta probado, de hecho lo he vuelto a probar para asegurarme. Carga el juego, sin problemas, en todos los casos. Da igual si es directo o es de los conflictivos. Pasando por cogswaploader rulan todos.

Con cogswaploader rulan TODOS. El "problema" es dloader4 de zeroday... Por la razon que sea, hay algunos rips a los que no engaña, sin embargo, esos mismo van sin problemas pasando por cogswaploader.

Por eso propuse a zeroday, unos mensajes atras, una modificacion de su dloader4, es decir un dloader5, basado en cogswaploader de hermes.

Pero sospecho que no es tan facil, o que zeroday anda tan liado como todos....

Bueno, ya estoy yo por aqui tambien.

Africa, debes de tener en cuenta que el cogswaploader esta programado en parte para las V7 y siguientes (para saltarse la doble comprobacion del swap), ademas de actualizar la toc y comprobar los ejecutables de los discos, por eso seguramente sea por lo que algunos back ups actuales no te arranquen con el dloaderv4 y sin embargo si con el cogswaploader (esta mas preparado para las protecciones).

Lo de la pantalla de Dloader con mandos Blaze es normal algunos mandos no originales no son reconocidos hasta arrancar el juego en cuestion (problemas programacion del fabricante), momento en que la ps2 ya los reconoce.
Sin embargo el Dloader (en todas las versiones)cuando arranca hace una verificacion del mando (en el puerto 1), y si no hay mando (o no lo reconoce como es tu caso), pues no arranca (se queda girando el cd pero sin pasar de la pantalla de dloader se queda en un bucle infinito el programa verificando el puerto 1 hasta que le pongamos un mando original o uno que reconozca, en ese momento empezaria a arrancar).
Si no prueba a arrancar el dloader sin mandos enchufados y veras como de la pantalla de presentacion no pasa (a ver si Zerodayz hace que si no hay mando o no lo reconoce continue la ejecucion.. ).
Tambien pasa con algunas marcas de Multipads (ej.Interact con este multipad tambien falla con el cogswaploader), mandos con funciones especiales (con macros ej. Saitek, este falla hasta con el disco Memory Manager),con algunas pistolas de ps1(con conector de mando psx ej.Hypnosys), algunos mandos sin cables, e incluso con los mandos a distancia y asi podria seguir un buen rato mas. (Con mi mando antiguo digital de psx si me arranca y funciona otra cosa es que el juego de ps2 no lo soporte y luego tengas que cambiarlo ).

Saludos a toda la gente del hilo, seguir asi .

A eso me referia yo con lo de testear.....
Un placer verte por aki Angelgoca.

Mas malas noticias... El parcheador no funciona con FUTURAMA PAL, ni con SOCOM de espalps2.

En el caso de Futurama, volcado al disco duro, modificado manualmente, arrastrar y grabar con nero y a jugar....
En el caso de Socom la cosa se complica. Muchos relinks, mañana me pongo al tajo.

Sigo probando.

hola ante todo gracias por el parcheador.
bueno lo he probado con el pes3 la release de isosphere y me dice: se ha pruducido un error,asegurese que el fichero bin no esta siendo usado por otra aplicacion.
e reiniciado y todo y nada de nada e visto aver si tenia activado solo lectura y lo tiene desactivado aver si alguien save como solucionar esto

Lamentablemente el parcheador falla con muchisimas imagenes querido colega goma.

Esperamos con impaciencia una nueva version... pa eso del mes de agosto que andaremos todos un poco menos atareados

Rápidamente que me piro.....

He hecho unas modificaciones al parcheador, ahora se supone que encuentra el System.cnf mucho más rápido puesto que ya no busca en toda la imagen sino que busca el desplazamiento de donde está el fichero en la información contenida en la propia imagen... un rollo, el caso es que me ha funcionado con una imagen. Id con ojo que no lo he probado demasiado pero creo que este nuevo sistema va de que te cagas (propuesto por kyke).

A ver si os rula, ya me contáis.

Un saludo a todos.

(nota: no pongo el fuente por razones de tiempo, si lo queréis decídmelo)

Un saludo

Felicidades guarroman0

Yo por mi parte estoy interesado en los fuentes, al menos para ver si viendo como funciona te puedo hacer algún otro comentario de interés, jejeje. Pero por lo que dices debe ir bien ahora siempre ...

Y adaptarlo para que funcione también con imagenes ISO, NRG, CCD y alguna otra no deberia ser muy complicado. De entrada habría que entender bien como distribuyen la información todos esos formatos, pero sé que no es muy distinto... una cabecera mayor o menor según el tipo y luego cada sector correlativo del tamaño X... y como la primera información a buscar sabemos dónde está siempre (en el LBA 22 para buscar el SYSTEM.CNF) pues ya tenemos el punto de partida.

Apuesto a que en Internet se encuentra la documentación apropiada, pero así de memoria te digo que el ISO y NRG (del Nero) son exactamente iguales lo único que el NRG mete una cabecera de XXX bytes siempre, que imagino nos podemos saltar. Por otra parte el .IMG del CCD (del CloneCD) creo que es igual al .BIN. Y lo que nos falta sería una relación entre .BIN y .ISO ¿alguien se la sabe?

Ya digo que lo suyo sería encontrar la información exacta. Además todo esto se podría probar a partir de un CD ya creado extrayendo las imagenes con cada programa y comparandolas con la información que tengamos...

Up up, que este hilo es interesante. Si tengo tiempo realizo una pekeña aplicacion en C. Y asi hacemos ports para todos los SO xD

nosotros ya la hemos hecho y la tenemos compilada para win32 y linux-386. se llama XPATCH y esta comentada en otro hilo de este mismo foro

Hola, yo soy uno de los creadores de XPATCH, junto con Troxxon y Venchska; que nos juntamos "en grupo" al poco de tratar este tema y hemos puesto en práctica las ideas del mensaje... XPATCH está hecho en C y se distribuye precompilado para Win32 y Linux. Se usa desde "linea de comandos" (cmd y command en Win32 y la consola o un terminal en Linux). Si alguien se quiere currar una GUI estaría bien

En cuanto al funcionamiento, hace básicamente todo lo que comentamos "más arriba" hace unas semanas... hace la búsqueda del SYSTEM.CNF en la imagen BIN/CUE directamente, sin recorrerla completamente (Hermes, no es siempre el LBA 22 donde está la info del directorio raiz, a veces está un poco antes o después, supongo que dependerá de la aplicación que se use para crear la imagen PS2), parchea el fichero añadiendole la linea "BOOT = ...(lo que queramos)" y cambia la longitud del fichero (en los dos campos donde ésta aparece!); todo eso en un segundo más o menos . Incluye una opción de "prueba" y otra de "ejecución" Y los demás detalles los encontrareis en la ayuda del programa (ejecutadlo sin parámetros).

XPATCH no corrige el ECC/EDC de la imagen BIN pero todas las grabadoras actuales lo hacen automaticamente; y si no os fiais, pues le pasais el CD-Mage y lo corregís ahí. Hemos probado multitud de imagenes de juegos y ha funcionado en el 100% de los casos, así que animo a los que se ofrezcan de betatesters a probarlo con las imagenes "raras" .

Saludos a Africa, Guarroman0, zeroday y demás gente del hilo, que os tengo olvidados

Me ofrazco voluntario agregame al msn doschiclesnuevos@hotmail.com

Escrito originalmente por goma
Me ofrazco voluntario agregame al msn doschiclesnuevos@hotmail.com

Hola, no tengo MSN, pero te puedes bajar XPATCH de http://www.ps2troopers.tk y probarlo tú mismo

No te olvides comentar aquí si te funciona, para animar al personal, o si no lo hace, para ver que falla!

Hola Kyle, se puede saber de donde se supone que se baja el XPatch???? He ido a ps2troopers y buscando en los foros he encontrado un link que NO funciona ya que te manda a una pagina de tripod con un link al buscador Toorents...

Hola shader,

ya está arreglado el ENLACE, dentro del foro de SOFTWARE de PS2Troopers.com

Por cierto ¿nadie lo ha probado? ¿nadie tiene ninguna opinión sobre XPatch?

Hola Kyle, pues a mni no me va el enlace http://usuarios.lycos.es/ps2troopers/soft/xpatch10b-win32.zip ... He provado el parcheador de Guarroman0 y me va perfecto. Saludos.