[3DS] Gateway-3DS - Erste funktionierende 3DS Flashcart

Jump to last post
Natürlich, das Ganze ist mehr Theorie als Realität, aber warum sonst sollten die das machen? Die meisten Leute, die eine GW o.Ä. kaufen würden, haben bereits eine. D.h. der theoretische Gewinn durch weitere Arbeit durch Updates ist gering im Vergleich zu dem was sie schon haben, trotzdem arbeitet das GW-Team weiter an neuen Features und fordert die Leute auf, unbedingt die aktuelle 2.0b2 zu nutzen.
Höchst dubios...
 
Vllt machen sie das aber auch nur, um neue Kunden anzuwerben?
Wenn die Konkurenz mehr Features bietet, wird niemand die GW kaufen..
 
Erster 3DS entbrickt und der eMMC lock ist damit auch bestätigt. Wer jetzt noch am Brick-Code zweifelt, der muss ein absoluter hardcore Fanboy sein :p

You do not have permission to view link please Anmelden or Registrieren
 
Oder an Magie glauben ;)

So wie ich das verstanden habe, wurde ein NAND-Backup benötigt, welches nicht durch die GW erstellt wurde. D.h. man könnte längst nicht allen Betroffenen helfen, richtig?
 
So lange du die NAND.bin gesichert hast, ist alles fein. Alle ohne NAND.bin sind leider am Ar*** mit dieser Methode.
 
Aber es gibt doch zwei verschiedene NAND-Backups; einmal das durch die Gateway und einmal das durch Aufschrauben und Löten. Würden beide funktionieren?
 
Hab das auch schon getestet, beide Varianten sind identisch, kannst sogar den Dump vom emuNand auf die Konsole braten.;)
 
Ok, dass es somit einen Weg zurück gibt ohne beim GW-Team zu betteln klingt schon mal gut. Allerdings bräuchte man schon einiges an Zubehör und Grundkenntnissen, ich hoffe es wird in nächster Zeit ein verständliches Tut dazu geben. Ein absoluter Laie wie ich würde während des Versuches wahrscheinlich noch mehr kaputt machen...
 
Makito schrieb:
Ok, dass es somit einen Weg zurück gibt ohne beim GW-Team zu betteln klingt schon mal gut. Allerdings bräuchte man schon einiges an Zubehör und Grundkenntnissen, ich hoffe es wird in nächster Zeit ein verständliches Tut dazu geben. Ein absoluter Laie wie ich würde während des Versuches wahrscheinlich noch mehr kaputt machen...
Zum Vergrößern anklicken....

Naja, Arduino + SD Card Shield um die Spannung zu reduzieren, bzw RasPi und halt was zum löten. Und wie bereits im Thread auf GBAtemp gesagt wurde, es werden sicherlich einige einen entsprechenden Service dazu anbieten.
 
Für die, die ich kenne und die sowieso meinen real Name haben, würde ich den 3DS entbricken, für andere leider nicht, da ich nur äußerst ungern meine persöhnlichen Daten hergebe.

Sorry.
 
profi200 schrieb:
Für die, die ich kenne und die sowieso meinen real Name haben, würde ich den 3DS entbricken, für andere leider nicht, da ich nur äußerst ungern meine persöhnlichen Daten hergebe.

Sorry.
Zum Vergrößern anklicken....

Ich denke mal, das werden auch noch einige andere machen. Ich hab auch selbst schon mit dem Gedanken gespielt, das anzubieten. Möchte zu diesem Zeitpunkt aber erstmal abwarten und schauen; ich hab auch keinen RasPi zur Hand und noch nicht an einem 3DS rumgelötet. Ich werd das jetzt alles erstmal als Anlass nehmen, wieder auf 2.0b2 umzusteigen. Und wenn dann mein 3DS unbrauchbar wird, schau ich, ob ich beim fixen irgendwelche größeren Probleme habe. Falls nicht könnte man schon über solch einen Service nachdenken.
 
Mal ne andere Idee aus dem gbatemp bzgl. der Bricks:
Das GW-Team wollte eine Art Update-Schutz implementieren, entschied sich am Ende wegen der Instabilität (und auftretenden Bricks) dagegen. Könnte es sein, dass diese vermeintliche AP-Vorkehrung ein Überbleibsel dieses Features ist?
 
Nein, weil man den Schreibschutz auch ohne lock aktivieren kann und warum machen die sich sonst den Aufwand das Passwort per AES Engine zu erstellen?

Wenn der Schreibschutz aktiv ist, wird die Firmware übrigens nicht korrekt booten und mit nem blackscreen oder einem "Ein Fehler ist aufgetreten..." Bildschirm hängen bleiben, weil die Firmware Schreibzugriff braucht. Sieht man gut daran, dass NAND Dumps nach jedem neustart andere Hashes haben.
 
Mal was anderes, wird man mit dieser Lötmethode theoretisch auch einen 3DS downgraden können, wenn kein Nand-Backup vorhanden ist?
Das wäre eher ein Service der mich interessiert ;)
 
tach ihr ex gb'ler.


Für die technisch Interessierten noch n zusätzliches kleines Indiz für den GW Scheiterhaufen (exklusiv und nur hier).

Code:
Expand Collapse Copy 
(S)afe run (Querry only) | (F)orce erase (Dangerous!) | (V)iew Register | (D)edication | (Q)uit
F

WARNING: This will (if it works) permanently erase the NAND!

Enter H (big h) to continue.
H
EMMC: resetting controller
EMMC: control0: 00000000, control1: 00000000, control2: 00000000
EMMC: capabilities: 0000000000000000
EMMC: checking for an inserted card
EMMC: status: 01ff0000
EMMC: setting clock rate
EMMC: base_clock: 250000000, target_rate: 400000, divisor: 00000200, actual_clock: 244140, ret: 00000080
EMMC: control0: 00000000, control1: 000f0083
EMMC: enabling SD clock
CMD0: idle
sd_issue_command: issuing command CMD0
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x00000000
CMD1: (arg0) init and querry OCR
sd_issue_command: issuing command CMD1
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x00FF8080
init loop: reissue CMD1 untill out of idlesd_issue_command: issuing command CMD1
iteration 1
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x80FF8080
CMD2: CID and id mode
sd_issue_command: issuing command CMD2
CMD3: assign RCA and standby mode
sd_issue_command: issuing command CMD3
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x02000500
SD_init: CMD3 response: 02000500
SD_init: RCA: beef
CMD9: get CSD
sd_issue_command: issuing command CMD9
RESPONSE:-----------------------------------
RESP3: 0x00900F00
RESP2: 0x320F5903
RESP1: 0xB9FFFF87
RESP0: 0xFF964050
SD_init: card CSD: 00900f00320f5903b9ffff87ff964050
CMD7: switch to transfer mode
sd_issue_command: issuing command CMD7
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x02000700
CMD13: get status register
sd_issue_command: issuing command CMD13
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x02000900
CMD16: setting blocklength to 1
sd_issue_command: issuing command CMD16
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x02000900
sd_issue_command: issuing command CMD42
SD_send_int: block 0 transfer complete
SD_send_int: error occured whilst waiting for transfer complete interrupt
SD_init: error sending CMD42, error = 00100000. Giving up.
(S)afe run (Querry only) | (F)orce erase (Dangerous!) | (V)iew Register | (D)edication | (Q)uit
S

EMMC: resetting controller
EMMC: control0: 00000000, control1: 00000000, control2: 00000000
EMMC: capabilities: 0000000000000000
EMMC: checking for an inserted card
EMMC: status: 01ff0006
EMMC: setting clock rate
EMMC: base_clock: 250000000, target_rate: 400000, divisor: 00000200, actual_clock: 244140, ret: 00000080
EMMC: control0: 00000000, control1: 000f0083
EMMC: enabling SD clock
CMD0: idle
sd_issue_command: issuing command CMD0
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x00000000
CMD1: (arg0) init and querry OCR
sd_issue_command: issuing command CMD1
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x00FF8080
init loop: reissue CMD1 untill out of idlesd_issue_command: issuing command CMD1
iteration 1
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x80FF8080
CMD2: CID and id mode
sd_issue_command: issuing command CMD2
CMD3: assign RCA and standby mode
sd_issue_command: issuing command CMD3
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x00000500
SD_init: CMD3 response: 00000500
SD_init: RCA: beef
CMD9: get CSD
sd_issue_command: issuing command CMD9
RESPONSE:-----------------------------------
RESP3: 0x00900F00
RESP2: 0x320F5903
RESP1: 0xB9FFFF87
RESP0: 0xFF964040
SD_init: card CSD: 00900f00320f5903b9ffff87ff964040
CMD7: switch to transfer mode
sd_issue_command: issuing command CMD7
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x00000700
CMD13: get status register
sd_issue_command: issuing command CMD13
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x00000900
CMD16: setting blocklength to 1
sd_issue_command: issuing command CMD16
RESPONSE:-----------------------------------
RESP3: 0x00000000
RESP2: 0x00000000
RESP1: 0x00000000
RESP0: 0x00000900
(S)afe run (Querry only) | (F)orce erase (Dangerous!) | (V)iew Register | (D)edication | (Q)uit

Der geneigte Leser beachte dabei die öfter in der oberen Hälfte im Byte ganz links der meisten RESP0 stehende 02 welche anzeigt dass in diesen Nachrichten das Bit 25 gesetzt ist. Dies ist nach dem erfolgreichen durchführen des Befehls 42 (das mit den falschen Fehlerausgaben vergessen wir jetzt mal, ok?) in der unteren Hälfte nicht mehr der Fall.

Bei diesen Nachrichten handelt es sich um Statusmeldungen die ein (e)MMC device immer dann schickt wenn es nichts wichtigeres zu sagen hat.
Ein blick in die Spezifikationen verrät uns:

Bit 25 | CARD_IS_LOCKED | “0” = card unlocked “1” = card locked | When set, signals that the card is locked by the host
Zum Vergrößern anklicken....

Sargnägel, heute günstig in der Familienpackung.

p.s.: ich bin in keinster weise 1337, highskillzor oder sonnst so n mumpitz: Wenn ich was löte kommt meist der magische blaue Rauch raus (selbst wenn ich nur Kupferlitzen verzinne), von mehr assembler als n bissi NOP und ner handvoll conditional jumps krieg ich Kopfschmerzen und wenn ich was zerlege bleiben nach dem zusammenbauen immer Teile über (oft sogar welche die recht wichtig wären).

Aber ich hab Spaß dabei.

Und wenn ihr glaubt, dass euch so etwas auch Spaß machen könnte, beschäftigt euch damit.

p.p.s.: das ganze war ein R4I brick, was das ganze direkt viel befriedigender macht (GW hätte das ja nicht gefixt, weil "like a book" und so).
 
Das ist nett, dass du hier vorbeischaust :) Ich hoffe das ist Beweis genug. Schließlich macht der NAND das nicht von selbst und aus Spaß. Es gibt leider immernoch Verfechter, die unbedingt den Code sehen wollen und dabei können sie nichts damit anfangen. ichfly hat den Code so beschrieben: "Der sieht aus, als wenn der aus einem RNG kommt" (RNG ist eine engliche Abkürzung und heißt Zufallszahlengenerator). Den kann man nur verstehen, wenn man alles hat und alles werden wir nicht veröffentlichen, denn es hilft den Clone Herstellern.
 
Woher kommt eigentlich die fixe Idee, Normatt wäre der Programmier der/des Clone Teams?
 
Das weis ich leider auch nicht. Wahrscheinlich hat das Timing gepasst, wo er seinen Region free Patch rausgehauen hat und nun zeigen sie mit dem Finger auf ihn. Dabei macht das aber eigentlich kaum Sinn. Warum sollte er, wenn wir mal davon ausgehen würden, dass es wahr ist, sowas veröffentlichen?

Diese ganze Mafia Scheiße und andere beschuldigen geht mir auf den Keks.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben