Mentre rido ancora per l'ultima barzelletta trovata pochi minuti fa in rete, vi racconto di un problema che ho dovuto affrontare ieri. Partiamo con ordine: scenario è un sistema di autenticazione online a cui è iscritta una ditta per cui lavoro; esso fornisce una comune applet java per autenticarsi sul server, per poi accedere sul dominio principale nelle aree di pubblicazione dei dati. Dall'applet si fa un comune POST su https con upload di file di certificato + inserimento password. Il server risponde con alcuni cookies di sessione grazie ai quali si riesce ad accedere ai dati.
Ora: l'idea era di accedere all'area protetta con un script, che salva i dati, li formatta in un modo più intelligente per poi usarli all'interno delle nostre applicazioni. Ovviamente, essendo clienti, si potrebbe cercare di contattare la ditta e chiedere della API per accedere in modo diverso; questo in teoria, ma in pratica le persone preposte sono allegramente in vacanza, per cui si cercano strade alternative sicuramente più stimolanti.
Ovviamente si parte dal decompilatore java JAD. L'applet è decisamente complessa, formata da diversi package ed il tutto è "offuscato". Per cui mi trovo a dover capire cos'è la classe a dentro il package j. Davvero una rottura, tanto più che il decompilato è ben lontanto dall'essere perfetto, e si hanno diversi errori, per cui non posso neanche cercare di sistemare un po' i nomi da eclipse con il refactor, perchè il progetto non compila. E la cosa si fa lunga.
Il POST viene effettutato dall'applet su https, quindi non mi sono d'aiuto nè HTTPLiveHeader (vediamo solo la riposta del server, che setta alcuni cookie) nè wireshark (perchè tutto crittato) . Devo quindi passare da java.
La prima idea è di cercare di sostituire a runtime la classe che gestisce le connessioni https, e redirigere lo stream anche su file o su stdout, in modo da vedere nella javaconsole del browser cosa cazzo sta inviando l'applet, per cercare poi di replicarlo in uno script.
Il problema è che dovremmo capire bene come viene lanciata la console e inserire lì dentro il codice per caricare le nostre classi. Allora io ed il mio collega compagno di tante avventure decidiamo di sostituire direttamente la classe che gestisce https nella libreria ufficiale di sun. Cerchiamo il jar, lo scompattiamo, prendiamo la classe (appartentente al package sun.net.www , quindi proprietario) e la decompiliamo con JAD. Il risultato è sicuramente migliore che con l'applet, ed il codice è leggibile e compilabile.
Aggiungiamo un paio di brutali System.out e via. Ricompiliamo, rimettiamo nel jar e riavviamo firefox. Questo procedimento è stato eseguito diverse volte su diverse classi, ma alla fine ce l'abbiamo fatta: ecco sulla java console comparire un po' di dati interessanti. Per capire che.. il tutto è crittato anche a livello applicativo! Ovviamente la trasformazione di quello che spedisce è presente nel codice del decompilato, per cui magari appena ho tempo cerco di reversare il tutto..
Nessun commento:
Posta un commento