KSuRoot

⚠️ Nota bene: le policy di scheduling dei modelli del produttore "blue factory" sono piuttosto rigide; durante l'elevazione dei privilegi i processi figli vengono facilmente recuperati dal sistema. Si consiglia di attivare prima "Interrompi limitazione processi figli" nelle "Opzioni sviluppatore" e poi eseguire l'elevazione dei privilegi: il tasso di successo sarà più alto.

Strumento di elevazione dei privilegi KernelSU con un solo clic basato sulla vulnerabilità del kernel CVE-2026-43499 (GhostLock).

Questo branch prende come modello KSuRoot, sincronizza completamente gli aggiornamenti della linea principale di Root-My-Galaxy v0.2.6 e, su questa base, aggiunge la costruzione del payload, il payload del produttore integrato e un'intera interfaccia utente in vetro liquido.

Mod di hmascs · versione 4.1.2 · Apache-2.0 Repository: https://github.com/hmascs/KSuRoot

---

Cosa cambia nella 4.1.2

Novità di questo ciclo (4.1.2): leggere dall'immagine l'offset del marker di vr.ko

vr.ko contrassegna i task provenienti dall'app; quell'offset ha due varianti, 0x04 / 0x06, ed è cotto nel payload in fase di compilazione, non è patchabile. Cosa ancora più fastidiosa: due copie di vr.ko sulla stessa macchina ne hanno una ciascuna (nel vendor_boot dello Y300 Pro+ ce ne sono due, con srcversion identico) — scegliere quella sbagliata si manifesta come "byte cancellati erroneamente, marker non rimosso, processi figli comunque uccisi", mentre nei log è tutto normale.

Ora la soluzione blue factory ti chiederà di fornire un vendor_boot.img: l'app legge da quella copia effettivamente caricata di lib/modules/vr.ko l'offset reale della macchina, e poi riscrive il payload. Le quattro librerie incluse/autocostruite (libbaseline_6_1 / libbaseline_6_12 / libbs / libionstack) sono tutte vincolate al proprio profilo; se scegli quella sbagliata vieni fermato sul posto dal gate a zero riscontri, invece di ricevere un artefatto copiato tale e quale.

Inoltre è stata aggiunta la funzione "Importa pacchetto di flash completo": selezioni direttamente lo zip OTA o il tgz fastboot che hai scaricato, e lui estrae da solo boot e vendor_boot, senza che tu debba prima decomprimere né estrarre manualmente.

⚠️ Il pacchetto completo deve essere copiato interamente nella cache dell'app per poter essere letto in modo casuale (la directory centrale dello ZIP è in coda al pacchetto, e l'uri di SAF non può diventare un File). Se lo spazio non è sufficiente viene rifiutato sul posto; al termine dell'estrazione la cache viene immediatamente eliminata.

4.1.2 = 4.1.0 + 19 commit. Questi commit erano originariamente fermi sul branch fix/baseline-routing, ora sono stati uniti in main. Il pacchetto di installazione 4.1.0 già pubblicato non li contiene — ognuna delle voci seguenti è stata corretta solo dopo.

Fallimenti silenziosi corretti

#	Difetto	Conseguenza
1	VR_TAG_A_OFF della 6.1 impostato a 0x06 (in pratica dovrebbe essere 0x04)	Sulle macchine blue factory 6.1 il marker non viene cancellato nemmeno un byte, mentre l'autotest riporta successo. Si manifesta come "dopo il successo dell'elevazione il processo figlio viene subito ucciso", senza che si capisca che è questa la causa
2	La localizzazione della tabella degli offset di kallsyms usava il modulo negativo (traduzione letterale della semantica Python)	Fallimento totale su kernel 6.4+, l'indirizzo base viene preso da un blocco di testo ASCII
3	Il criterio della tabella degli offset guardava solo "i primi tre elementi monotoni"	Quasi zero potere discriminante (qualsiasi posizione nella tabella è monotona); è stato modificato per controllare la forma della tabella
4	BASELINE_6_12.imageBase impostato all'indirizzo base di destinazione	Tutti i punti di costruzione in forma di indirizzo assoluto sono stati saltati (39 punti → 9 punti)
5	Quando i simboli non sono allineati si azzera solo l'artefatto, ma gate resta Proceed	blocked=false e artefatto 0 B, l'interfaccia non mostra il riquadro di blocco
6	Il fallback di FopsSlot non è mai stato utilizzato	Se la tabella non viene trovata si rinuncia direttamente, senza ripiegare sul simbolo di riserva

Funzionalità completate

• 6.12 finalmente funzionante: ashmem in 6.12 è diventato un'implementazione Rust, i nomi dei simboli sono tutti mangled → modificato per leggere a runtime dallo slot fops di miscdevice (TARGET_ASHMEM_FOPS_UNSYMBOLED)
• 6.1 / 6.12 utilizzabili sia con la soluzione generica sia con quella blue factory (quattro combinazioni con 16 / 16 / 13 / 13 profili ciascuna), l'elenco è nell'archivio 07-文档/6.1-6.12-双方案清单.md
• Offset del marker di vr.ko misurato macchina per macchina: 6.1 = 0x04, 6.6 / 6.12 = 0x06 (il vr.ko nel firmware del produttore su tre macchine reali)
• La ricetta di costruzione del payload segue il repository (载荷构建/): in precedenza nel repository c'erano 15 punti che facevano riferimento a una directory inesistente

★ Riscontrato su macchina reale: sulla 6.1 i 26 offset non ne è stato modificato nemmeno uno, e il pacchetto viene comunque prodotto

Il risultato dell'esecuzione della build su X100 Pro (6.1.145) è:

偏移解析: 28 / 28 项
需要改写: 26 项 · 校验通过: 0 项
该动态库未引用 26 项偏移

Non è "non c'è niente da modificare", è "queste due cose non sono un set unico". La causa principale è che le due strade indipendenti hanno preso direzioni diverse:

Cosa scegliere	In base a cosa scegliere	Selezionato su 6.1.145
Libreria di base	Famiglia di struct (F6_1)	libbaseline_6_1.so (valore precedente da baseline-6.1-tokay/target.h)
Profilo	Routing a tre livelli (stringa del kernel)	up-6-1-145-… (valore precedente da offsets.h di GhostLock)

Il metodo di patching consiste nel «prendere il valore precedente dal profilo e cercare il letterale nel .so». I due set di valori precedenti non hanno alcuna intersezione, quindi nessuno dei 26 elementi corrisponde, e il risultato equivale a una copia identica della libreria di base.

Perché il gate rigido originale non l'ha bloccato: il criterio di hasFailures è changed && !ok && !absent —— absent è esplicitamente escluso. Quella motivazione ("le vecchie versioni del .so potrebbero non avere il percorso di codice corrispondente") vale per chiavi individuali, ma non vale per "tutte le chiavi sono absent".

Due correzioni:

1. Libreria e profilo forzati alla stessa origine: le baseline della famiglia auto-compilata (libbaseline_6_1.so / libbaseline_6_12.so) devono essere abbinate al proprio profilo (baseline-6-1-tokay / baseline-6-12-honor), i profili upstream up-* si applicano solo al .so upstream. Aggiunto BaselineLibraries.profileIdForLibrary().
2. Gate rigido a zero corrispondenze: se nemmeno una specifica di offset corrisponde a un sito, il packaging si ferma (quella della base non conta —— anche se non corrisponde mai, spesso cambia comunque, e maschererebbe il fatto che "nessun offset è stato modificato"). A tal fine è stato aggiunto il campo kind a SpecOutcome.

I casi di regressione sono in BaselineLibraryPairingTest (4 casi), uno dei quali asserisce direttamente che i due set di valori precedenti non hanno intersezione —— trasformando "perché è obbligatorio l'abbinamento" in un fatto eseguibile.

Librerie dinamiche: la categoria di problemi "cliccato ma non succede nulla" dopo l'importazione