FelixFrog
commented
10 months ago Ciao! Innanzitutto mi fa piacere sapere che c'è qualcuno di interessato a pdfgrabber per quanto riguarda il lato reverse engineering. Per sviluppare pdfgrabber mi sono occupato principalmente delle applicazioni android per vari motivi:
- Il bytecode DEX delle app android è decisamente più semplice e i decompilatori moderni sono in grado di ricostruire quasi completamente il codice sorgente Java delle app (alcuni sono in grado di creare direttamente i progetti per Android Studio).
- Il bytecode DEX contiene, per design, il nome delle funzioni. Alcune applicazioni ovviamente offuscano tali nomi, ma siccome è un'opzione "opt-in" su Android Studio, molti sviluppatori non lo fanno (se non sbaglio Zanichelli è fra questi ultimi).
- Android mette a disposizione delle librerie crittografiche standard di sistema. Questo semplifica di molto il lavoro degli sviluppatori e di conseguenza anche il lavoro di RE, poiché le funzioni crittografiche si riducono ad un paio di invocazioni a metodi di classi con nomi facili da riconoscere (e non offuscati, poiché appunto sono librerie di sistema).
- Siccome Android viene assunto come ambiente di esecuzione più sicuro che una applicazione web o un programma desktop, questo spesso fa sì che gli sviluppatori siano più riluttanti ad implementare SSL pinning o altre misure per evitare che gli utenti possano sniffare il traffico internet dell'app. Fortunatamente, grazie alla natura open*** di Android queste misure sono facilmente aggirabili.
Cerco dunque di evitare per quanto possibile di analizzare codice macchina di applicativi desktop o applicazioni web. Le prime (nel raro caso in cui non siano un semplice webview o app electron e ricadendo quindi nelle seconde) perché come avrai ben scoperto richiedono uno sforzo maggiore a causa di ottimizzazioni aggressive dei compilatori, offuscamento, e maggiore complessita in generale. Le seconde perché spesso forniscono dati di qualità minore (render in formato jpg dei pdf originali) in quanto percepite appunto più "vulnerabili" da parte degli sviluppatori, e perché permettono alle case editrici di aggiornarle quando preferiscono, rendendo gli script inutili in qualche mese. Al contrario, le app android richiedono una stabilità e una coerenza con una API che non può, per motivi tecnici, evolversi rapidamente, perché non è concepibile per un utente dover aggiornare un'app ogni volta che si vuole leggere un maledettissimo libro (e gli sviluppatori delle case editrici sono ben consapevoli che una buona fetta di questi utenti installa queste app su dispositivi decisamente poco potenti).
Per rispondere finalmente alla tua domanda (forse in modo un po' deludente) tutto ciò che ho fatto è stato:
- Ottenere l'APK dell'app di Booktab
- Aprirla in un decompilatore android (tipo jadx-gui)
- Cercare per le stringhe "AES", "Cipher", "Crypto", "Decrypt", ec...
- Individuare la routine di decriptazione
- Trovare dove un oggetto
javax.crypto.Cipherviene inizializzato (nel nostro cas con.getInstance('Blowfish/CBC/PKCS5Padding');
Se hai altre domande sarò ben felice di risponderti!
Miriamz1337
Stavo lavorando ad un progetto simile solo per booktab (volevo poter leggere i miei ebook senza dover utilizzare la loro app schifosa), sono abbastanza nuova al reverse engineering, quindi ho attaccato il processo con x64dbg, analizzato il flow, trovato la funzione che genera la chiave, e la funzione che si occupa di decifrare l'xhtml. Ho riscritto la funzione di generazione della chiave, e stavo riscrivendo la funzione per decifrare (la stavo riscrivendo istruzione per istruzione), quando dalla vostra repo ho notato che è semplicemente blowfish. Ora la mia domanda è: come avete determinato che fosse blowfish? pattern recognition? Oppure avete visto che decifrava in blocchi e quindi provato aes e blowfish con un processo puramente euristico? O ancora dato che nella versione browser di Zanichelli browser viene utilizzato blowfish avete optato direttamente per quello? Grazie mille :)