Con lo spopolare dei bios AMI Aptio, è diventato molto più semplice fare piccole modifiche mirate, in quanto si è assistito ad una sorta di standardizzazione. Questi BIOS sono organizzati in moduli, e questi moduli possono essere rimpiazzati senza grande sforzo.

Ma se volessimo crearne noi uno, o modificarlo? L’esigenza è lecita, soprattutto se quelli creati dal costruttore fanno schifo (un esempio? qui).

Oggi ci occuperemo del DSDT. Ci servono: Aptio MMTool, IASL, e un hex editor.

Individuiamo innanzitutto il modulo giusto: è riconoscibile perché, dopo l’header, a 0x25, troviamo la dicitura DSDT (0x44, 0x55, 0x44, 0x54). Nel caso di ASUS, questo modulo contiene due DSDT diversi. Non ho investigato, ma suppongo sia perché uno viene utilizzato quando l’optimus è attivo, e l’altro quando la GPU è disabilitata. Normalmente non si può disabilitare l’optimus, ma col bios unlock (maggiori informazioni qui) è possibile. In questo bios il modulo giusto ha indice 0x30, e non ha nome.

Dopo il magic “DSDT”, a 0x29, troviamo 4 byte che indicano la dimensione del listato, nel mio caso 69446 bytes (0x46, 0x0f, 0x01, 0x00). Nel nostro caso, quindi, estraiamo da 0x25 a 0x25+0x10f46. (L’altro listato inizia invece a 0x12475, stessa procedura)

Il file ora estratto può essere modificato con IASL o con un editor apposito. Dopo averlo ricompilato, è molto probabile che la dimensione sia diversa dall’originale. L’importante è che non sia maggiore, perché quei famosi 4 byte fanno testo sulla dimensione. Andiamo quindi a sovrascrivere nel modulo il listato ricompilato, avendo cura di sostituire i byte, ma di lasciare li quelli che avanzano in modo che la dimensione del modulo rimanga uguale.

Finito questo, bisogna correggere il checksum del modulo a 0x11. Potete farlo tramite questo algoritmo:

public static uint Checksum(byte[] module)
{
    uint num = 0;
    for(int i = 0x18; i < module.Length; i++)
    {
        num += module[i];
    }
    return (uint)(-num & 0xff);
}

Ora reinserite il modulo con MMTool.

Bene! Il nuovo BIOS col DSDT modificato è pronto!

Scrivo questo post per rimpiazzare il sito creato diverso tempo fa su altervista e per in qualche modo reclamarne la “paternità”.

La ragion d’essere del suddetto sito viene fuori dal fatto che ASUS per molti notebook usciti prima dell’avvento di Windows 8 ha creato una implementazione delle hotkeys che va in conflitto con quella nativa implementata in W8 e successivi. Questo rende di fatto molte delle hotkeys inutilizzabili.

Il mio vecchio notebook, un N53SV, ricadeva in questa schiera di “sfigatelli”. Siccome non sono una persona che si rassegna, ho deciso di ovviare da me. Nel corso del tempo e a grande richiesta, sono riuscito a tirar fuori dalla lista anche altri modelli. Se siete fortunati, il vostro sarà uno di questi:

N73SVAS_W8.zip
N53SNAS_W8.zip
U36SDAS_W8.zip
N53SVAS_W8.zip
U30SdAS_W8.zip

L’installazione è semplice:

1. se non l’avete già fatto, aggiornate all’ultimo bios ufficiale
2. disinstallate ATKACPI
3. scaricate e mettete il bios decompresso in una penna formattata in fat32
4. riavviate nel bios, scegliete “start easy flash”, cercate il file e date conferma
5. installate questa versione di ATKACPI (va bene una qualsiasi, basta sia compatibile con windows 8)

Tutto fatto. Semplice, no?

Il risultato finale sarà questo:

Voci in Advanced aggiunte e tab Chipset sbloccato

NOTA: Queste operazioni se fatte nel modo sbagliato possono causare la morte prematura (e probabilmente anche permanente) del notebook. Non mi assumo nessuna responsabilità per quello che le vostre manacce possono combinare.

Ora passiamo all’Art Attack:

Partiamo dal BIOS originale. Tutte le modifiche qui descritte sono state fatte sulla versione 208 originale, ma non quella disponibile dal sito. Mi spiego: quella che si può scaricare dal sito asus è incapsulata (ha 2KB in più di dati) che noi non vogliamo; quindi se non siete già sulla 208 prima aggiornate, e poi estraete dalla memoria flash il bios senza capsula.

afuwinx64 dump.rom /O

Fatevi furbi e salvate questo file; semmai dovrete mandare in garanzia il notebook infatti vi conviene rimettercelo…

Siccome far uscire il tab chipset è un discorso a parte, preoccupiamoci prima di sbloccare le voci mancanti in advanced e boot. Questa operazione è abbastanza semplice, basta aprire il dump in amibcp e cambiare il campo “Access/Use” in “USER”. Fatelo con tutti gli elementi sotto Advanced e sotto Boot.
Quando avete finito, salvate il file e chiudete amibcp.

Ora tocca al tab chipset. Questo tab contiene impostazioni pericolose, quali overclock e impostazioni dello schermo, ma molto utili. Il tab chipset è nascosto nel codice, quindi dovremo modificare il modulo che contiene l’interfaccia di configurazione. Sembra infatti che vi sia un array di bool che indica quali tab sono sbloccati e quali no. nel nostro bios i valori sono: {true,true,false,true,true,true}.
Si, avete capito bene: il false qui sopra è proprio il tab chipset.

Il modulo in questione si chiama “Setup”, e possiamo estrarlo con MMTool. Cerchiamo questo array con un hex editor e cambiamo il false con un true, poi rimpiazziamo il modulo modificato dentro l’immagine del bios.

Salviamo il nuovo file e dopo aver preso coraggio, flashiamolo con afuwinx64 new.rom /gun.

Il flash richiederà un paio di minuti. Sebbene io l’abbia rifatto una decina di volte durante i miei esperimenti e che sia andato sempre a buon fine, non me la sento di dirvi che questa è una procedura sicura.

A buon intenditor.

Di una cosa però non riuscivo a capacitarmi: che le hotkey (i tasti fn, per capirci) non funzionassero a dovere con windows 8 (e successivi).

il perché di questo è presto detto: queste sono state implementate coi piedi (non diciamo parolacce va) nel DSDT, non tenendo in considerazione che l’OS potesse volersele gestire da sé.

questo ovviamente genera varie complicazioni che, alla pressione delle suddette hotkey. impediscono effettivamente di attuare il comando impartito.

Ho pubblicato il bios patchato qui.

Grazie asus per aver ignorato le richieste d’aiuto di chi possiede questo piccolo pezzo d’arte.

Sono una persona molto interessata alla tecnologia, a come funziona, e soprattutto a come aggiustarla quando si rompe.

Il mio primo post riguarda un DVR, cinese, senza nome. Chi ne ha avuto a che fare riconoscerà il nome Naway.

Bene, tutto ok, finché arrivò android 4.2: questo nuovo major update di android porta, oltre alle migliorie, un cambiamento nella gestione dei ByteBuffer. Per farla breve, c’è molta probabilità che un programma che non abbia implementato correttamente i ByteBuffer ora crashi, perché android ora li avanza da solo, e quindi una applicazione che credeva che tale ByteBuffer fosse sempre in posizione 0 (tranne se modificato esplicitamente) ora se lo ritrova in posizione finale.

Ciò porta al lancio di una RuntimeException, che può essere risolto semplicemente facendo il rewind del buffer prima di riutilizzarlo.

Tada, tutto funziona di nuovo.

Naway+