› Foros › Xbox 360 › Exploits y homebrew
Y claro que se puede hacer todo en 20 minutos... pero solo si es de 16megas porque leer los 64 primeros megas de una jasper tarda 30 minutos de crono al igual que restaurar su nand original.
Mi gran mosqueo es que no se con exactitud que Xell es bueno para una jaster de 512 y cb 6751 ¿por qué? porque yo he creado 4 distintos según estos parámetros:
Tanto si lo creas con Python como con gbuild (hacen el mismo xell) pero los parches según esta tabla son distintos si:
"la nand donada es de jasper 512 cb 6750 con das 13604 sacada del Hilo de pantalla negra y todo OK del primer post y que dicen que la hicieron funcionar"
nand donada inyectando datos a mano y usando el comando CDJASPER, checksum del parche xell: D569F80E4060A6E0771370B172073426
nand donada inyectando datos a mano y usando elcomando cd, checksum del parche xell: 4613A6B691991277B27185C6B4EA25C4
nand donada sin inyectar datos y usando el comando cd, checksum del parche xell: 2C5866CF41510F3023E62
nadn donada sin intectar datos y usando el comando cdjasper, checksum del parche xell: 6FFFD1F836DA3876033ED83D93432E18
asi obtengo cuatro parches xells distintos.... para una sola nand donada, y nunguno me arranca el Xell, pero para más comedura de coco, si cojo otra nand donada de por ejemplo 16megas o un nanddump de 66megas (de una 256megas), ya tengo generados 16 parches Xells distintos
claro que hay diferencia con una de 16megas... porque con la de 16megas solo puedes generar dos Xell, con comando CD o con comando CDJASPER, pero con la jasper de 512m cb6751, se suman todos los problemas posibles.
blaKCat escribió:para los cb6751 que no les funcione nada pueden probar a hacer el build usando solo el cb_a de una 6750 donada y asi conservar tanto el smc como el keyvault de la suya original.
Extraer el cb de una nand 6750 donada y ejecutar
build.py 671.bin cb.6750.bin CDJasper xell-gggggg.bin
Ya me contareis
C:\Python27>python common\imgbuild\build.py 6751.bin cb.6750.bin
D common\xell\xell-gggggg.bin
* found flash image, unpacking...
ECC'ed - will unecc.
Found 2BL (build 6751) at 00008000
Found 4BL (build 8453) at 00011380
Found 5BL (build 1888) at 00016b00
* found (hopefully) decrypted CB
* found decrypted CD
* found XeLL binary, must be linked to 1c000000
* we found the following parts:
SMC: 2.3
CB_A: 6750
CB_B: missing
CD (image): 8453
CD (decrypted): 8453
* checking for proper 1BL key... ok
* checking if all files decrypted properly... ok
* checking required versions... ok
* this image will be valid *only* for: jasper
* patching SMC...
CRC32: 5b3aed00
patchset "Jasper, version 2.3" matches, 1 patch(es)
* zero-pairing...
* constructing new image...
* base size: 70000
* No separate recovery Xell available!
* Flash Layout:
0x00000000..0x000001ff (0x00000200 bytes) Header
0x00000200..0x00000fff (0x00000e00 bytes) Padding
0x00001000..0x00003fff (0x00003000 bytes) SMC
0x00004000..0x00007fff (0x00004000 bytes) Keyvault
0x00008000..0x00011a3f (0x00009a40 bytes) CB_A 6750
0x00011a40..0x00017a3f (0x00006000 bytes) CD 8453
0x00017a40..0x000bffff (0x000a85c0 bytes) Padding
0x000c0000..0x000fffff (0x00040000 bytes) Xell (backup)
0x00100000..0x0013ffff (0x00040000 bytes) Xell (main)
* Encoding ECC...
------------- Written into output/image_00000000.ecc
C:\Python27>
NeRvloS escribió:gracias blackcat, lo probaré cuando acabe mi última prueba xD
he dado con el programa 360_Multi_Builder_v0.2.rar que viene preparado para crear el xell de la 512 6751
te crea el xell solo con la nand, porque dice que usa una donada pero no te dice donde meterla y lo crea directamente.
ahora mismo estoy pasando a original y luego aplicaré el xell, para hcer el proceso desde 0.
según comentaba en el foro de xbox-scene la gente con esta placa ha conseguido arrancar el Xell con ese ECC y tienen problemas con el DASH! xD esta placa está cargada de sorpresas.
en un rato os cuento la experiencia. además he cambiado los cables del chip del punto A, B y F (matrix) a 40 cm, y desde el principio condensador de 472pf del punto F a masa.
EDITO: Aun sigo con la pantalla negra, y probado también lo que propone Blackcat y sigo con la pantalla negra y los ventiladores parecen que van a salir volandoC:\Python27>python common\imgbuild\build.py 6751.bin cb.6750.bin
D common\xell\xell-gggggg.bin
* found flash image, unpacking...
ECC'ed - will unecc.
Found 2BL (build 6751) at 00008000
Found 4BL (build 8453) at 00011380
Found 5BL (build 1888) at 00016b00
* found (hopefully) decrypted CB
* found decrypted CD
* found XeLL binary, must be linked to 1c000000
* we found the following parts:
SMC: 2.3
CB_A: 6750
CB_B: missing
CD (image): 8453
CD (decrypted): 8453
* checking for proper 1BL key... ok
* checking if all files decrypted properly... ok
* checking required versions... ok
* this image will be valid *only* for: jasper
* patching SMC...
CRC32: 5b3aed00
patchset "Jasper, version 2.3" matches, 1 patch(es)
* zero-pairing...
* constructing new image...
* base size: 70000
* No separate recovery Xell available!
* Flash Layout:
0x00000000..0x000001ff (0x00000200 bytes) Header
0x00000200..0x00000fff (0x00000e00 bytes) Padding
0x00001000..0x00003fff (0x00003000 bytes) SMC
0x00004000..0x00007fff (0x00004000 bytes) Keyvault
0x00008000..0x00011a3f (0x00009a40 bytes) CB_A 6750
0x00011a40..0x00017a3f (0x00006000 bytes) CD 8453
0x00017a40..0x000bffff (0x000a85c0 bytes) Padding
0x000c0000..0x000fffff (0x00040000 bytes) Xell (backup)
0x00100000..0x0013ffff (0x00040000 bytes) Xell (main)
* Encoding ECC...
------------- Written into output/image_00000000.ecc
C:\Python27>
[Update 6]
if you hear ticking more than once every few secs (i.e. 2-3 times a second) then you Pulled the trace off the circuit (to some extent) from the xbox that hooks up ft4r2 to c5r14 (i think?) and it's not a glitching problem, but a physical problem because the circuit is disconnected.
Here's a picture of a slim that f***ed up. I hooked up he c5r14 pad directly to ft4r2 after pulling off the trace in order to fix it.
http://i43.tinypic.com/4v04k2.jpg
btw all ugly/dodgy $#!t on the mobo is just hotglue that i had to melt to get to ft4r2 again. the board is not burnt, just traces pulled off Tongue
on the same note, im using the pad as an alternate soldering point for the cpu_rst cable from the cpld. it's easier to solder to the pad (after f***ing up the trace and probably even before as well)
[Update 5]
Something I forgot to mention, use stranded wire. 2-3 guys tested solid core with no success and stranded with immediate success. all my tests and instant boot slims used stranded wires
[Update 4]
It's likely that different cplds (homemade/branded) will require different cable length. while each different cpld has not been tested for an optimal length, it seems that the optimal length for matrix glitchers lies between 25-32 cms.
For all other cplds, it is recommended to start off with a 50cm cable, testing and cutting intervals of 1.5-2cm at a time until you get a stable/reliable/consistent boot.
[i'll consolidate test results this evening]
[Update 3]
Looks like tx updated their tx coolrunner thread to adopt similar fix for their slims a few hours
"The Wires bundle to the left is for slim. Includes the 50CM extra length for the CPU_RST line."
Tydye81 reckons 50cm fix need for splicing cable. We haven't tested that yet.
[Update 2]
<rf1911> jasper 16mb
<rf1911> 32cm long wire from cpurst
<rf1911> terminal at the end to dip pin
<rf1911> glitch immediate
<rf1911> cmod schema and gligli schema
Looks like this fix potentially works for phats as well! Others please test and report! Thanks!
[Update]
Every slim we have tested so far has glitched under 10 seconds on average after applying this fix. Even the ones that refused to glitch/stopped glitching showed improvement after trying this. Please post your results after trying this, we still don't fully understand why it works and could use your data.
In addition (or not see test results below) to 270pf capacitor, apply Size Matters Fix (SMF):
Simply Extend the wire that connects ft4r2 to Pad A on matrix to make length of wire between ft4r2 and glitch board/cpld a total of 25-32cm wire! At this point it seems like you need spliced wires (i.e. not one single wire of 28-30 cm but 2 wires connected together adding up to 25-32 cm - most likely something to do with resistance)
(There's a good chance this works with other cpld boards/glitchers and phats - see [Update 2] above)
That's all you need to do!! Boots consistently under 10secs!!
A new fix from the RGloader team
[Tests so far]
Ameel 2x slim - consistently successful using 270pf on matrix glitchers
Gadorach 1x slim - consistently successful using standard 220pf on matrix glitcher
dood 1xslim - consistently successful using matrix glitcher
mustache 1xslim - consistently successful using matrix glitcher
cjack 1xslim -successful using matrix glither
rf1911 1xjasper 16mb - consisently successful using cmod schema and gligli schema
iLLNESS 1xslim - boots better but not as good as others, had to use different cable length, using Seeedstudio/Dangerous Coolrunner
ZerOneX 1xjasper - consistently successful with 8sec average boot
Pacote-san 1xjasper CB6751 - fail
edsondario 1xslim - successful
fireworks 1xjasper16mb 6750 -fail
Pacote-san 1xjasper - successful - 6 consecutive boots to xell withing 2 seconds range using 33cm AWG30
galo911 1xslim - successful 3s to 15s
k0mpresd 1x picky slim - successful
watk 1xslim - consistently successful
morenomdz 1xjasper - fail
Neptune 1xslim - fail
bownsir 1x picky slim - consistently successful under 45s
playonlcd - fail on home-made cpld
xandura 1xslim - success?
rikimaer 2xjasper - fail
ptwitb 1xjasper - fail
eddie1990, 2xslim - fail using 30,32,50 cm on matrix 220pf
pacote-san 1xslim - consistently successful under 15s
ZerOneX 1xjasper - successful using 53cm
morenomdz 1xjasper 256 - successful 50% under 3 secs, 50% up to a minute (100% under a minute??)
pacote-san 1xslim - consistently successful (between instant to 30 secs)
lenselijer - successful between 20-30secs
Foccart 2xslim - successful using 50cm (1st 20-30secs, 2nd instant-10secs)
Ameel 2xslim - successful on matrix using single 40ish cm stranded wire + 270pf
Other people can test as follows:
1. Try similar cable length on other glitchers/cplds and see whether that works and report
2. Try similar cable length on non-slim xbox (i.e phat ones) on cpu_rst
Possible Theory/explanation of fix (offered by tydye):
<tydye81> the length of the wire
<tydye81> the signal sent to reset is 20ns
<tydye81> super small
<tydye81> so when the wire hits the solder joint it reflects
<tydye81> because of such a change in resistance
<tydye81> a little energy does get through, but not a lot
<tydye81> so it takes several tries to get it
<tydye81> sometimes several minutes if at all
<tydye81> if you calculate the waveform of a 20ns signal (50mhz) you come up with a harmonic of 35.2cm
<tydye81> change optimal length to 28
<tydye81> cause I think its gonna vary between boxes
<tydye81> and I think that would be a good middle range
[Original Post]
Hardware: Matrix glitcher with 270pf
SO I did my first slim. Glitches between 5-10seconds consistently.
I did my 2nd slim. Glitches beween 2-5 minutes randomly, and sometimes never (or rather cbf waiting more than 10 mins)
So what's the difference? What's the problem? Took me forever to figure it out - resoldered 100x, tested everything over and over: Length of wires!!!
I changed the wire connecing Ft4r2 from the back of console to A from SHORTEST POSSIBLE LENGTH of wire (~10cm) to ~32cm. Result? Slim now glitches consistently within 20 seconds!!!
Can anyone try this out and see if it works for them?
If that is indeed the FIX, then maybe just a resistor could fix it as well? Anyway, TEST AND REPORT!!
edit:
At this point i dont want to rewire anything and would rather just leave everything as is since it's consistently glitching under 10seconds.
So up to you guys to figure out whether length (resistance) or type of cable (resistance) makes a difference or whether it's length (whether signal bounces as tydye81 suggested) could be the issue.
edit 2: i rewired the extension with the better quality cable, and it boots consistently under 10 secs.
edit 3:
http://i44.tinypic.com/atu6v6.jpg
http://i41.tinypic.com/dy90dt.jpg
so i added the extension to test.
total length i tested was between 31.5 and 32.5 and it glitches under 10 seconds consistently.
tydye81 speculates 35.2 is the optimal length.
edit 5:
dood just reported extending the same cable on his slim glitched his xbox within 6secs. he's gonna do more test + cold boot
edit 6:
Gadorach's boot time after fix:
<Gadorach> 11
<Gadorach> 4
<Gadorach> 4
<Gadorach> 4
<Gadorach> 6
<Gadorach> 12
<Gadorach> 3
<Gadorach> 6
<Gadorach> 6
<Gadorach> 14
<Gadorach> 10
<Gadorach> 5
<Gadorach> 5
<Gadorach> 7
« Last Edit: November 04, 2011, 03:47:46 AM by ameel »
josej2011 escribió:Tengo una pregunta, puedo utilizar una nand donada para poder hacer el RGH?, es que al extraer mi nand aparecieron 8 bad block, y aunq los remape no confio en esa nand. Quisiera saber tambien si con el metodo que utilizo chankin82 puedo instalar el xell, teniendo mi nand original con bad block?
chrono56 escribió:Yo realize una jasper 512 con 6751 y perfecto, al principio dio problemas por usar un nandpro incompatible para la placa al momento de escribir, y despues por que vole el punto de cpu pll bypass, pero fue restaurar la pista, actualizar mi nandumper para q funcionara con el nandpro 2.0e, y a la primera, xell arrancando en menos de nada y dash en general en menos de 10 segundos (el tiemmpo mas largo que demoro en arrancar, lo normal son 5 segundos)
La unica solucion que encontre con esta consola fue hacerle el RGH, al igual q muchos con la nand original siempre 0022.
salu2
killgamesx300 escribió:chrono56 escribió:Yo realize una jasper 512 con 6751 y perfecto, al principio dio problemas por usar un nandpro incompatible para la placa al momento de escribir, y despues por que vole el punto de cpu pll bypass, pero fue restaurar la pista, actualizar mi nandumper para q funcionara con el nandpro 2.0e, y a la primera, xell arrancando en menos de nada y dash en general en menos de 10 segundos (el tiemmpo mas largo que demoro en arrancar, lo normal son 5 segundos)
La unica solucion que encontre con esta consola fue hacerle el RGH, al igual q muchos con la nand original siempre 0022.
salu2
Amigo disculpame si te pido mucho pero nesesito que me pases la nand hackeada que utilizaste para instalarle el RGH en tu jasper (yo tengo el mismo modelo que el tuyo cb6751 jasper 512 mb ) por favor , considera mi situacion , estoy en apuros , no tengo xbox desde el 24 /12/2011 , por el problema de que no me lo han podido instalar RGH , y el lector se le perdio la key la unica manera de extraersela es con RGH , por favor ayudame te doy mil gracias si me haces el favor y te cuento como me va , estoy preocupado por mi xbox por favor nesesito a alguien que me heche una mano , disculpa los errores ortogrficos
si me va bien te paso el gow3 o el mw3 , tu me dices..(tambien tengo el dead island) , todos en español ..tu me dises ok?
gaboxe escribió:Buenos días a la comunidad, he realizado RGH a mas de 50 consolas, entre jasper, zephyr, falcon y trinity, pero me ha tocado una jasper CB 6751 512 Mb y se me ha echo dificill.
Para empezar la extracción de la nand la realice sin problemas (2 veces y comparando) con el programa autogg 2.0.10 de BlackCat (gracias por este excelente programa) sin ningún error de extracción, genero la Nand Xell con una nand donada CB 6750 y flasheo.
Instalo el chip Coolrunner Reb B. Xell me arranca en tiempos de 2 seg a 1 min, copio la Cpu_key con la ip usando autoGG 2.0.10 de BlackCat. Todo marcha perfectamente.
Ahora creo la imagen con dash 14699 y coloco le doy a la opción Raw_flash para colocarla en un Pendrive.
Nuevamente arranco el xell en la Jasper sin problemas (aveces se tarda un poco), introduzco el pendrive y empieza el flasheo.
Se completa exitosamente y procedo a apagar la consola. Al encender pasan 3 cosas:
1. La consola arranca el dash y se congela la imagen en el inicio
2. Se queda pantalla negra pero gracias a la frecuencia del televisor me doy cuenta que arranca el dash.
3. No arranca el dash (pasa 1 vez cada 5)
En vista de que esto pasaba decidi colocarle su nand original, pero para mi sorpresa el resultado es el mismo, se congela en el dash en intervalos de tiempo distintos.
Decidi hacerle un poco de reflow (se que las jasper no sufren de esto pero ese error me parecio idento a cuando empiezan las luces de la muerte).
El resultado, el mismo error, en este momento al trengo con el RGH montado, para ver si alguien me puede ayudar ya que estoy apunto de pasarle un dremel a la consola
Gracias de antemano a quien me puede ayudar y espero que alguien le sirva esta información para arrancar el Xell con Jasper 512 CB 6751
Post: Si alguien cree que es problema de hardware escucho comentarios, si hay que cambiar una pieza u otra cosa!!