[résolu] Slim Clignote Indéfiniement --> Aucun Signal Video

[Sarkaron]

Moi ce qui m'avait bloqué c'etait le fichier ecc, buggé, en le créant avec python nikel

Modifié 31 octobre 2011 par Sarkaron

[Bibar]

Ouf, j'ai enfin réussi... pas très stable ce hack encore...

Merci pour le coup de main !

[xvassor]

Même problème le Hack ne veut pas prendre la main.

J'ai fais une slim 4go qui a marché du 1er coup, boot en moins de 30 secondes chaques fois

mais cette 2eme slim est recalcitrante ...

J'ai remarqué que le PD du CB2 etait NULL !!! Est ce bien normal ?

Ci joint les Infos

J'ai fais 2 dumps identiques donc je ne pense pas qu'ils soivent tous les deux nazes avec un spi flasher custom qui a toujours marché nickel.

Le ventillo est relancé dirons nous toutes les 5 secondes donc le CPLD et la NAND sont correctement flashés

Montage vérifié 10x (connection, soudures, continuité)

Il me reste deux pistes:

- Soit le code du CB 9188 est différent des autres ce qui expliquerait que la tempo n'est plus en phase donc glitch impossible a réaliser.

- Soit c'est cette histoire de longeur de fils mais la on ne parle pas d'optimisation du temps de boot mais bien de disfonctionnement !

J'utilise une capa de 220pf (pas de 270pf sous la main) car la 220pf marchait bien sur la 1ere slim.... avec le meme CPLD que gligli (version US non chinoise)

Vcc et masse en fils normal mono brin (diametre des trous des connecteurs servant a la lecture de la nand) et le reste en kynar

AVEZ VOUS DEJA EU un PD (Pairing Data) avec une valeur vide (NULL je pense)

Merci pour votre aide

Modifié 3 novembre 2011 par xvassor

[Bibar]

- Soit le code du CB 9188 est différent des autres ce qui expliquerait que la tempo n'est plus en phase donc glitch impossible a réaliser.

Pas impossible, j'ai un CB 9188 également.

- Soit c'est cette histoire de longeur de fils mais la on ne parle pas d'optimisation du temps de boot mais bien de disfonctionnement !

Oui effectivement, regarde mon premier poste, je l'ai édité, et avant impossible de booter.

[acide0]

Moi la slim que j'ai sous la main n'a jamais voulu booter et je n'en suis pas a ma premiere donc je crois qu'il y a des consoles que cela ne fonctionne pas pour une raison x,y avec le temps on devrait avoir nos réponse.

[bugess]

tu as verifié si le cb-9188.bin est dans l'archive ??du soft utilisé pour preparer rton fichier hacké

Modifié 3 novembre 2011 par bugess

[acide0]

tu as verifié si le cb-9188.bin est dans l'archive ??du soft utilisé pour preparer rton fichier hacké

Y a le cba_9198 et le cbb_9198.

[xvassor]

tu as verifié si le cb-9188.bin est dans l'archive ??du soft utilisé pour preparer rton fichier hacké

Si on parle de l'archive de gligli "reset-glitch-hack-v1.1" et non de ggbuild "ggbuild-0.33b"

non le CB n'est pas fournie seul le CD est fournie.

En revanche j'ai bien après le build du hack gligli dans mon "output" folder deux fichiers "CB_A.bin" et "CB_B.bin" qui ont étés extraits de ma nand d'origine (ainsi que le SMC.bin).

J'ai déjà réalisé avec succès le Reset Glitch Loader sur une autre Slim peut etre que si je reprend son CB ca pourrait marcher ?

Modifié 4 novembre 2011 par xvassor

[xvassor]

[xvassor]

J'ai fais deux diff entre le RGL de la slim qui marche et celle qui ne marche pas:

Les deux log du build du gg glitch sont 100% identique

le diff des 2 SMC.bin:

Offset , NOK, OK

00000000: E6 1E

00000001: 92 B1

00000002: 1B 80

00000003: 4E B9

ici j'ai E6921B4E au debut du smc.bin de la slim qui ne boot pas sur le xell

ci quelqu'un sait a quoi correspond ses 4 premiers octets je suis preneur !

le diff du CB_A

00000010: F0 AC

00000011: BC 9B

00000012: 38 88

00000013: C5 8B

00000014: E1 25

00000015: 0E 9E

00000016: 29 74

00000017: 4B B8

00000018: DE A1

00000019: 37 7A

0000001A: 82 2C

0000001B: 97 69

0000001C: E7 65

0000001D: D8 30

0000001E: 1C 6A

0000001F: 12 44

qui veut dire que le HMAC salt (used for decrypting the loader) est different sur les 2 CB_A pourquoi pas ....

par contre mes deux CB_B sont bien different de l'offset 10 jusqu'a la fin

mais ca c'est normal car le CB_B present dans le output folder est en mode crypté (sauf erreur de ma part ?)

et si je me rappel bien il l'est a l'aide de la cle CPU (CB_B is RC4 crypted, the key comes from the CPU key)

comme c'est le CB_A qui est glitché et non le CB_B donc a ce que je peux comprendre tout est normal

j'ai bien le même CB_A seul mon CB_B est crypté différemment donc le timing du hack devrait etre bon .

Bon c'est le montage qui doit merder ou c'est la carte mere qui est legerement differente ?

par contre j'ai le Pairing data du CB_2 qui est non renseigné (champ vide) donc null je pense,

comme j'ai jamais vu ça ailleurs je m'inquiète sur la cette version de CB_2 !!!

log.txt

Modifié 4 novembre 2011 par xvassor