Mii QR-code: het FFL-formaat en offset 0x04
Scan een Mii QR-code met de gewone telefoonscanner en je krijgt een scherm vol wartaal. Scan dezelfde code op een 3DS en er arriveert een compleet personage ā gezicht, naam, gestalte ā plus een onzichtbare reeks regels over wie hem mag kopiĆ«ren, delen en bewerken. Dat gat tussen twee ervaringen is een klein stukje binaire ingenieurskunst, en de reden dat onze Mii QR-ontgrendelaar bestaat. Deze gids loopt het formaat langs de weg die het hulpmiddel werkelijk neemt: de QR-laag, het FFL-datablok, de permissievelden op offsets als 0x01 en 0x04, en de precieze redenen waarom een console "Deze Mii kan niet worden bewerkt" meldt. Elke uitspraak hier komt uit dezelfde decoder die in onze tool draait ā niets is uit een wiki overgeschreven.
Eerste verrassing: een Mii QR-code is geen tekst
De meeste codes die je dagelijks scant, dragen platte tekst: een url, een wifi-wachtwoord, een menukaart. Een Mii QR-code niet. Hij draagt een byte-mode-payload: een rauw blok binaire data dat alleen zin heeft voor een console die het formaat kent. Als de telefoonscanner hem leest, probeert hij die bytes in welke codering dan ook als tekst te duiden, struikelt halverwege en spuugt de brij uit die je vast al eens gezien hebt.
Het technische verschil huist in de QR-specificatie zelf. Een code kan data in meerdere modi vervoeren ā numeriek, alfanumeriek, byte en kanji. Tekst reist in alfanumeriek of byte mode met een UTF-8-payload; een Mii gebruikt ook byte mode, maar zijn payload is helemaal geen tekst. Onze decoder leest de code met jsQR en pakt de rauwe binaryData-array in plaats van de gedecodeerde tekenreeks. Dat is het belangrijkste implementatiedetail van allemaal: op het moment dat je een Mii QR-code als tekenreeks behandelt, heb je hem al geruĆÆneerd.
Bij het terugschrijven wacht dezelfde val, nu op zijn kop. Een generator die voor url's gebouwd is, codeert binaire data graag via een tekstlaag opnieuw en ramt ze kapot zonder een woord. Daarom laat onze encoder de buffer in byte mode passeren, met een vaste QR-versie en foutcorrectieniveau, op maat zodat een 3DS-camera de code van een telefoonscherm betrouwbaar kan lezen. Binair in, binair uit: de payload raakt nooit een tekenreeks.
FFL: de gezichtsbibliotheek achter elke Mii
De data in de code beschrijft de Mii in het FFL-formaat (Face Library) ā de karakterweergavebibliotheek die Nintendo over zijn consoles heen deelt, publiek gedocumenteerd door de community, en de grondslag van dezelfde Mii-data die Wii-, 3DS-, Wii-U- en Switch-spellen consumeren. FFL bewaart een Mii als compacte structuur: identiteitsvelden als naam en geslacht, een reeks uiterlijk-velden voor gezichtstrekken, gestalte en kleuren, en een klein blok permissievlaggen dat bepaalt wat andermans console met het personage mag doen.
Twee eigenschappen van het formaat vormen de basis voor de rest van deze gids. EĆ©n: het is stabiel over consolegeneraties heen ā een Mii QR-code uit het 3DS-tijdperk scant nog op een Wii U, en Switch-spellen consumeren dezelfde onderliggende data; een eenmalig geschreven formatgids blijft dus lang bruikbaar. Twee: het is slaaf van posities ā elk veld ligt op een vaste offset vanaf het begin van het blok, en die offsets schuiven per generatie lichtjes. EĆ©n offset missen en je krijgt geen ietwat eigenaardige Mii, maar een Mii die niet eens scant. Die strengheid verklaart tegelijk waarom het formaat consolewisselingen ongeschonden doorstaat: games vinden het niet opnieuw uit, ze leggen hun karakterdata bij dezelfde bibliotheek neer.
De kop, veld voor veld
Voordat er ook maar iets wijzigt, parseert de tool de eerste bytes van het blok en toont een voorproefje. Dit zijn de kopvelden die het formaat definieert, en wat elk ervan bestuurt:
| Offset | Veld | Inhoud |
|---|---|---|
0x00 | Versiebyte | Welke Mii-data-generatie het blok gebruikt |
0x01 | Optievlaggen | Bit 0 draagt de vlag kopiƫren toestaan; de overige bits dekken de grofvlag en de regioblokkering af |
0x02ā0x03 | Slotkop | Op welke Mii Maker-pagina en in welke slot de Mii is bewaard |
0x04ā0x0B | Systeem-ID | Acht bytes die de bezittende console identificeren ā het veld dat de bewerkingscontrole raadpleegt, en dat onze unlock-pass herschrijft |
0x18 | Geslacht & persoonlijke bits | De geslachtsbit, plus geboortedatum en lievelingskleur |
0x1Aā0x2D | Naam | Tot 10 tekens in UTF-16, null-beĆ«indigd |
0x30 | Deelvlag | Bit 0 hier is de schakelaar delen verbieden (bron: de Mii-formaatdocumentatie op 3dbrew) |
Het naamveld verdient een aparte vermelding, want daar struikelt handmatig bewerken het vaakst. 'Tien tekens' betekent niet 'tien bytes': in UTF-16 kost elk teken twee bytes, ongebruikte posities worden met nullen gevuld, en de decoder stopt bij de eerste nul. Schrijf de naam in UTF-8 en een Japanse of Duitse naam wordt wartaal op de console; vergeet de null-beƫindiger en de naam vreet wat erachter komt op.
Alles na de kop is de Mii zelf: tientallen uiterlijk-velden ā gezichtsvorm, haar, ogen, wenkbrauwen, neus, mond, bril, lengte, bouw en lievelingskleuren ā elk gepakt in precieze bits. De tool leest net genoeg om een voorbeeld te tekenen en raakt daarna opzettelijk niets meer aan: een unlock die ook maar ƩƩn gezichtspixel verzet, is een unlock waar je niet op kunt vertrouwen.
Waarom gescande Mii's "deze Mii kan niet worden bewerkt" zeggen
Het permissiesysteem bestaat omdat de Mii QR-code een deelmechanisme is en Nintendo de maker heeft laten beslissen hoe ver dat delen reikt. Wanneer een Mii op een console wordt gemaakt, zet zijn FFL-data de keuze van de maker als vlaggen in het blok. Scant een andere console die QR, dan arriveert de Mii als ontvangen: de console behandelt de oorspronkelijke maker als auteur, leest de vlaggen en voert ze letterlijk uit:
- KopiĆ«ren toestaan ā sloot de maker het kopiĆ«ren af, dan staat de ontvangende console niet toe dat de Mii wordt gedupliceerd of elders bewaard.
- Delen verbieden ā met delen uit komt er geen nieuwe QR uit deze Mii voor de volgende persoon.
- Bewerken ā een ontvangen Mii is op de ontvangende console nooit bewerkbaar, hoe de andere twee vlaggen ook staan. Het bewerkingsrecht hoort bij de console waar de Mii geboren is. Dezelfde eigendomslogica stuurt de standaardwaarden van persoonlijkheid en stem aan; onze stem-synthetiseringgids haalt die uit elkaar.
De derde regel is degene die verbaast. Je kunt een Mii scannen, bewonderen, in games gebruiken ā maar op het moment dat je hem in de editor probeert te openen, weigert de console: "Deze Mii kan niet worden bewerkt." Dat is geen defect; het zijn de vlaggen, scrupuleus trouw aan wat hun maker vroeg.
Er is ƩƩn officiƫle omweg, en die werkt alleen als de maker kopiƫren toestond: op de 3DS kopieer je de Mii naar je eigen Mii Maker en bouw je hem onderdeel voor onderdeel na. De nagebouwde Mii is geboren op jouw console, volledig van jou en volledig bewerkbaar. Het nadeel: voor alles voorbij een snelle retouche is het een karwei, en zodra het kopiƫren zelf op slot zit, valt de route weg. Die kloof tussen 'officieel mogelijk' en 'praktisch bruikbaar' is precies het terrein van elke unlock-tool.
Wat onze ontgrendelaar verandert ā en wat hij nooit raakt
Met de veldkaart voor ogen is de unlock-bewerking bewust klein: de tool leest de payload en herschrijft de eerste byte van het System-ID op 0x04 ā de eigendomsidentiteit waaraan een console toetst of een ontvangen Mii bewerkt mag worden ā, zodat de Mii niet meer aan een vreemde eigenaar koppelt. Wil je de Mii hernoemen, dan herschrijft hij het naamveld in correcte UTF-16 in dezelfde pass. Daarna codeert hij het blok om tot een frisse byte-mode-QR. Alle overige bytes passeren ƩƩn voor ƩƩn, onaangeroerd.
De hercodeerstap weegt zwaarder dan hij klinkt. De nieuwe QR ontstaat in byte mode, met vaste versie en foutcorrectieniveau M, getekend op een maat die is afgestemd zodat een 3DS-camera hem van een telefoonscherm leest. Met verkeerde QR-instellingen kan de code er kraaknet uitzien en toch weigeren bij exact de console waar je hem op richt: foutcorrectieniveaus ruilen scanrobuustheid tegen datacapaciteit, en de Mii-payload kruipt dicht tegen de grens ā die keuze is geen cosmetica.
De hele rondreis speelt zich in je browser af. De payload wordt uit het bestand dat je neerzet gedecodeerd, in het geheugen gehouden, aangepast en teruggetekend; de sessiegeschiedenis slaapt in de IndexedDB van je eigen browser. Geen server ertussenin ā en dat is meer dan privacy-gemak: het betekent dat de route waarmee de tool heimelijk een kopie van iemands Mii zou achterhouden, inclusief die van jou, niet bestaat.
Van 3DS naar Switch: camera's, QR-codes en toegangssleutels
Het grootste deel van de hedendaagse verwarring rond Mii-delen verklaart zich uit de hardwaregeschiedenis. De 3DS had twee camera's, en daar was het scannen van een QR een ingebakken gebaar van het toestel zelf: Mii Maker, Tomodachi Life, Miitopia en StreetPass aten er allemaal van. Switch haalde de camera's helemaal weg: zijn Mii Maker kan een Mii-QR van 3DS of Wii U nog steeds lezen ā in theorie, want er is geen camera die hem leest. Wat Switch behield, zijn de FFL-data zelf; daarom blijft de formaatkennis uit deze gids geldig. Wat verhuisde, is de deellaag.
Voor Miitopia op Switch verving Nintendo de QR-codes door een systeem van toegangssleutels: een korte code die een Mii uit een onlinedienst laadt, en een tweede sleutel om je eigen Mii te publiceren. Switch 2 zet dit voort. Toegangssleutels lossen het camera-loze probleem elegant op, erven dezelfde permissiefilosofie ā een gedownloade Mii is andermans werk ā en werken alleen in games die de dienst ondersteunen.
De praktische brug tussen beide tijdperken loopt over het 3DS-formaat: pak een Mii QR-code, open de vlaggen als ze dicht zijn, en breng hem naar de Mii Maker op Switch via een van de wegen waarmee spelers de ontbrekende camera omzeilen ā geĆ«muleerd scannen op een gemodde console, of de ontgrendelde Mii op het oog nabouwen vanuit de gedecodeerde preview. Zit de Mii eenmaal op Switch, dan draait zijn data native en wordt hij geaccepteerd overal waar Switch Mii's ondersteunt, van Tomodachi Life: Living the Dream tot Miitopia. En omdat het persoonlijkheidssysteem op dezelfde Mii-data rijdt, geldt alles uit onze Tomodachi Life MBTI-mapping ongewijzigd voor het getransplanteerde personage.
Waarom handmatig bewerken met een hex-editor meestal faalt
Nu je de kaart kent, prikkelt het om de tool over te slaan en bytes rechtstreeks in een hex-editor om te draaien. Daar wachten drie faalmodi, en alle drie zijn ze stom: het bestand meldt nooit wat er scheef ging.
- 1Andere generatie, andere offsets. Veldposities schuiven tussen de Wii-, 3DS- en Switch-generaties van het formaat. Een patch op de verkeerde indeling bewerkt de verkeerde bytes ā en de eerste slachtoffers zijn doorgaans de uiterlijk-velden die je nooit wilde raken.
- 2De tekenreeksval. Hex-editors denken standaard in tekst. Je opent de payload, bewerkt de naam als ASCII, slaat op ā en het UTF-16-naamveld is bij ontwerp verschoven, met de bytes erachter als puin.
- 3De hercodeerval. Na de bytebewerking resteert nog de QR. Url-gerichte generatoren coderen via een tekstlaag en verpulveren binaire payloads; alleen een byte-mode-encoder met de juiste versie en het juiste niveau levert een code af die een console accepteert.
Een speciale tool bestaat precies om die drie fouten principieel onmogelijk te maken: vaste offsets, byte mode in en uit, en een naamveld geschreven met de juiste codering en opvulling. Dat is de volledige reden waarom onze ontgrendelaar een pagina is en geen voetnoot in documentatie.
Vragen die mensen over Mii QR-codes hebben
Is het ontgrendelen van een Mii QR-code legaal en veilig?
Wat veiligheid betreft, werkt de mechaniek voor je mee: de unlock herschrijft alleen de permissiebytes en laat het uiterlijk-blok onaangeroerd ā een aangepaste code scant dus óf als dezelfde Mii met nieuwe rechten, óf helemaal niet; er is geen stille derde weg. Wat legaliteit betreft: het formaat is door de community gedocumenteerd, de tool werkt op Mii-data die je al bezit, en wat daarna komt gehoorzaamt aan dezelfde regels als elke fanactiviteit ā respecteer de oorspronkelijke maker en geef andermans personage niet uit voor je eigen werk. Nintendo's houding tegenover aangepaste Mii-data is dezelfde als tegenover de rest van het bestandssysteem van de console: gebied zonder officiĆ«le ondersteuning, het oordeel is aan jou.
Werkt het ook met Mii's uit Miitopia en Smash Bros.?
Ja. Miitopia en Super Smash Bros. Ultimate consumeren dezelfde FFL-formaat-Mii-data als Tomodachi Life en de 3DS-Mii Maker; een voor het ene spel gemaakte QR scant dus in de andere, op consoles die QR-invoer aannemen. Het formaat is de gemeenschappelijke taal; de games zijn slechts andere luisteraars.
Mijn console scant de ontgrendelde code niet ā waarom?
Negen van de tien keer is het optica, geen data. Zet de schermhelderheid op maximaal, houd de console op de afstand waar de QR het beeld vult zonder onscherp te worden, maak de lens schoon en vermijd de reflectie van plafonnlampen. Weigert hij nóg, genereer dan opnieuw: een screenshot van een QR kan compressie-artefacten meedragen die de decodering breken. De juiste gewoonte is het oorspronkelijk gerenderde beeld bewaren.
Ziet de ontgrendelde Mii er in games anders uit?
Nee. Het uiterlijk-blok passeert byte voor byte: gezicht, haar, kleuren, lengte, naam en steminstellingen arriveren precies zoals de maker ze zette. De zichtbare veranderingen zijn degene die je vraagt, zoals een nieuwe naam. Ziet een Mii er na de scan anders uit, dan heeft ergens onderweg het QR-beeld zelf geleden: genereer opnieuw en scan opnieuw voordat je de data de schuld geeft.
Kan ik een Mii direct op de Switch bewerken?
Een ontvangen Mii, nee. De Mii Maker op Switch bewerkt Mii's die op die console zijn gemaakt; elke Mii die van buiten komt ā via toegangssleutel of scan ā blijft vergrendeld ter bescherming van de auteur, precies zoals op de 3DS. De weg naar een bewerkbare kopie loopt wederom via het formaat: ontgrendel de originele QR zodat hij als lokaal en bewerkbaar wordt herkend, en breng hem daarna via het middel dat jouw opstelling toelaat naar de Switch.
En het nieuwe Mii-systeem van Switch 2?
Switch 2 zet de toegangssleutelbenadering voor Miitopia voort, en de onderliggende Mii-data blijft uit dezelfde FFL-lijn. De QR als fysiek deelmedium hoort bij de consoles met camera ā 3DS en Wii U ā en precies daarom blijft het begrijpen van het formaat zijn waarde behouden: de data die die codes vervoerden is dezelfde data die je Switch-games vandaag consumeren.
Kan ik de oorspronkelijke permissies herstellen?
Bewaar het originele QR-beeld ā de unlock overschrijft nooit je bronbestand, hij maakt een nieuwe code met opengeklapte vlaggen. Wil je ooit de beperkingen terug, dan draagt het origineel de instellingen van de maker nog steeds en scant hij precies zo weer. Wat niet kan: een Mii die al op een console woont opnieuw op slot zetten. Het bewerkingsrecht dat jouw console eenmaal via een ontgrendelde scan kreeg, blijft voor altijd bij die Mii horen. Die asymmetrie is goed om te weten voordat je iets ontgrendelt dat een vriend je leende.
Probeer het zelf
Het snelst wordt het formaat tastbaar als je de tool een eigen Mii voert en ziet hoe de velden opduiken:
- Mii QR-ontgrendelaar ā zet een code neer, zie naam en permissievlaggen gedecodeerd en genereer een bewerkbare code opnieuw.
- Mii-creator ā bouw een Mii van nul, met live FFL-rendering en export.
- Mii Ogen-editor ā een gerichte editor voor de oogvormen die de uitdrukking van een Mii bepalen.
- Stemlab ā hoor hoe Tomodachi Life een persoonlijkheid in een gesynthetiseerde stem omzet.