Hai risolto un bel problema … si ma poi me ne restano MILLE …
La canzone estiva ideale per chi debugga. Link. (Ma serve davvero?)
Categoria: debugging (Pagina 2 di 11)
Un problema abbastanza comune: io non riesco a mantenere l’attenzione su quello che sto facendo mentre ci sono voci di altre persone. Sentire parlare qualcuno automaticamente sposta parte della mia attenzione da quello che sto facendo a quello che sento anche se non sono io il desiderio del messaggio.
In una certa misura credo che capiti a tutti, a chi più a chi meno. Per me è più.
E inevitabilmente accade anche con la musica.
Una cosa che sapevo è che si possono usare i noise generator per offuscare il parlato e isolarsi. MyNoise ne ha una collezione enorme e personalizzabile.
Una cosa che non conoscevo, e che sto apprezzando molto, sono le stazioni LoFi Hip Hop. Ne scegli una e la fai andare per ore. Fantastico.
Un ulteriore consiglio non richiesto: per ascolti prolungati è meglio un paio di cuffie grandi, vecchia maniera, piuttosto che gli auricolari in-ear, se poi sono dotate di cancellazione attiva del rumore l’effetto isolamento è ancora migliore.
Probabilmente mi ha fatto male rileggere i Promessi Sposi di recente, e constatare che a distanza di 2 secoli dalla scrittura, e 4 dai supposti eventi narrati poco è cambiato. L’unica cosa che vedo di differente è che la Medicina è una scienza un po più matura e che ha dei dati oggettivi da produrre e capacita analitica sul male.
La peste prima è stata sottovalutata e sminuita dalla autorità, poi chi assisteva i malati è stato lasciato a se stesso, poi in tutta fretta si sono individuati luoghi in cui mettere i malati e alla fine molti di quelli che assistevano i malati si sono ammalati a loro volta. Alla fine si è salvato chi è stato isolato e chi fortunatamente ne è uscito con le sue forze. Gran parte degli sforzi tardivi delle autorità hanno fatto più male che bene.
Ma il punto è che la ggente (con due g) ancora cerca l’untore. Per semplicità: avere un nemico visibile ti mette in pace con i tuoi pochi neuroni. Prima il cinese, poi il passeggiatore di cani, ultimamente si è eletto a categoria untrice il runner. Probabilmente non sarà l’ultima categoria. E perché non il corriere o la cassiera? Vedremo. Non sono tempi noiosi.
Solo non affidatevi all’astrologia, e tenete acceso il cervello. Le soluzioni semplici non esistono. Le soluzioni estreme sono sempre un estremo sbaglio.
Diversamente da quanto detto nella puntata precedente mi sono concentrato sul verificare l’algoritmo di codifica della password, realizzando un programmino allo scopo:
package net.b0sh.yiCameraClient.test;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.security.InvalidKeyException;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Base64;
public class EncryptionTest {
public static void main(String[] params) {
String toBoFound = "OMESSO";
String cleanPassword = "OMESSO";
byte[] secret = "secret".getBytes();
if (digest(cleanPassword, "SHA-256").equals(toBoFound)) {
System.out.println("success");
}
if (digest(cleanPassword, "SHA-1").equals(toBoFound)) {
System.out.println("success");
}
if (digest(cleanPassword, "MD5").equals(toBoFound)) {
System.out.println("success");
}
if (hmac(cleanPassword,"HmacSHA256",secret).equals(toBoFound)) {
System.out.println("success");
}
}
private static String digest(String password, String alg) {
try {
MessageDigest md = MessageDigest.getInstance(alg);
byte[] bytes = md.digest(password.getBytes());
System.out.println(alg + " Bytes " + new String(bytes));
System.out.println(alg + " Base64 " + new String(Base64.getEncoder().encode(bytes)));
return new String(Base64.getEncoder().encode(bytes));
} catch (NoSuchAlgorithmException e) {
System.out.println("NoSuchAlgorithmException");
return "";
}
}
private static String hmac(String password, String alg, byte[] secret) {
try {
SecretKeySpec keySpec = new SecretKeySpec(secret, alg);
Mac mac = Mac.getInstance(alg);
mac.init(keySpec);
mac.update(password.getBytes());
byte[] bytes = mac.doFinal();
System.out.println(alg + " Bytes " + new String(bytes));
System.out.println(alg + " Base64 " + new String(Base64.getEncoder().encode(bytes)));
return new String(Base64.getEncoder().encode(bytes));
} catch (NoSuchAlgorithmException e) {
return "";
} catch (InvalidKeyException i) {
return "";
}
}
}
Avendo definitiva conferma che l’algoritmo utilizzato è HMAC SHA256, quindi un hash “salato” con un segreto. Il problema quindi resta individuare il segreto. HashCat pare supportare il bruteforce del sale dell’HmacSHA256. Qualcuno ha qualche PetaFLOP da prestarmi?
Premessa: dopo 2 mesi di totale mancanza di notifiche push sull’applicazione per cellulare, motivazione principale per la quale ho iniziato questo progettino, dal primo marzo sono tornate a funzionare. Ovvio. Ma comunque ho iniziato, vediamo dove si riesce ad arrivare.
Login
L’applicazione, durante tutto il dialogo col server setta i seguenti headers
x-xiaoyi-appVersion: windows;10;0
User-Agent: YIHomePCClient/1.0.0.0_201811201000 (Windows 10.0)
Connection: Keep-Alive
Accept-Encoding: gzip
Accept-Language: it-IT,en,*
E per prima cosa fa una chiamata GET all’endpont: https://api.eu.xiaoyi.com/v4/users/login con parametri :
- seq = 1
- account= <nome account>
- password= <la password codificata con algoritmo sconosciuto>
- dev_id= <null>
- dev_name=windows
- dev_type=10.0
- dev_os_version=Windows
Il primo obbiettivo è quindi capire come viene codificata la password. A prima vista serve un URL decode ( https://www.urldecoder.org/ ) e si ottiene quella che sembra essere una stringa in base64. Piccolo problema: decodificando il base64 non ottengo la password che mi aspetto. Anzi si ottiene una stringa più lunga, forte indizio di una effettiva codifica o hashing.
La lunghezza, di 16 byte, sembra compatibile con l’hash in MD5 ed esclude algoritmi di hashing più recenti (SHA*), ma il risultato dell’hash della mia password non è uguale al dato che mi ritrovo. Che ci abbiano aggiunto del sale?
Purtroppo anche una ricerca nell’archivio di MD5Online non ha dato risultato.
Il risultato della chiamata (al momento comunque inutile) è un JSON:
{
“code”:”20000″,
“data”:{
“birthday”:””,
“token_secret”:”<token1>”,
“img”:””,
“flag”:true,
“name”:”simoneb0sh”,
“mobile”:””,
“last_name”:””,
“userid”:<useridnumerico>,
“first_name”:””,
“account”:”<nomeaccount>”,
“email”:”<emailaccount>”,
“token”:”<token2>”
}
}
Nella prossima puntata qualche prova per vedere come diverse password vengono codificate e se la codifica cambia nel tempo, indice di una “salatura” variabile in funzione di data e ora.
Se la codifica invece rimanesse stabile, pur non sapendo come funziona si potrebbe ignorare il problema e andare avanti comunque, anche se l’utilizzo del client che si andrebbe a realizzare sarebbe molto più complesso.
Per intercettare e decodificare al volo il traffico HTTPS servono una serie di strumenti un pò più border-line per realizzare quello che si chiama attacco Man In The Middle, ovvero il più grosso buco nel sistema che dovrebbe farvi sentire sicuri su internet. Il problema è noto da anni, si è fatto molto per mitigarlo, ma avendo accesso da amministratore al computer della vittima (che in questo caso è me stesso) è ancora possibile decifrare tutto in tempo reale.
Il principio di base è che una comunicazione cifrata dal client A al server B non è comprensibile da nessun altro al di fuori di A e B, ma se inseriamo l’attaccante M e al client A facciamo credere che M sia il server e al server B facciamo credere che M sia il client il canale sicuro si interrompe e M è in grado di leggere in chiaro sia le interrogazioni di A che le risposte di B.
MITMProxy svolge il ruolo di M alla perfezione, ma è un proxy con un certificato crittografico selfsigned, che quindi l’applicazione che dobbiamo analizzare dovrebbe usare di sua spontanea volontà e permettere di ignorare l’evidente problema del certificato selfsigned. Ovviamente non è cosi (oggi, nel 2019, qualche anno fà c’era molta meno attenzione).
Per quest’ultimo problema c’è nella documentazione del progetto la strategia di risoluzione. In buona sostanza bisogna installare nel truststore del computer il certificato finto ponendolo alla stesso livello di affidabilità di una certification authority nota. L’operatività cambia per browser e sistema operativo ma è tutto spiegato sul sito.
Poi per “costringere” l’applicazione ad usare il proxy, ora ritenuto affidabile, bisogna trasformalo in un transparent-proxy, cosa abbastanza facile in sistemi linux, ma non prevista su windows. Si risolve con Proxifier che permette di scegliere quale traffico debba passare attraverso il proxy e quale no.
Premessa: YI, spinoff di XIAOMI, fa delle belle telecamere IP, le vende ad un prezzo accettabile e le app sono (erano?) meglio di molte cinesate più anonime.
Il problema è che è un sistema chiuso. Per salvare i filmati in un posto diverso dalla microsd bisogna usare il cloud loro, non è prevista nessuna connettività a sistemi esterni non loro.
Mi sono detto… che problema c’è… l’applicazione di controllo userà una manciata di API rest, le studio, ci faccio un piccolo client e ci faccio quello che voglio.
Per prima cosa ho verificato la cosa facesse l’applicazione, usando Wireshark. E’ stato facile identificare il principale candidato per una analisi più approfondita: l’host api.eu.xiaoyi.com riceve un pò di chiamate https.
Solo che intercettare e decodificare il traffico httpS non è propriamente banale. La S starebbe li ad indicare che non potresti farlo.
Carissima Ispirer vorrei segnalarti che la sanificazione dell’input va fatta anche quando questo non viene direttamente dall’utente ma da anche da servizi esterni come un whois.
Qualcuno potrebbe voler temporaneamente rinominare l’ente che mi offre al momento la connessione in Universita’); Drop table aisp_locations;
Il problema dell’autenticazione biometrica è che è come dire la tua password a tutti quelli che incontri… Non stupiamoci poi se…
Basta una foto in alta definizione per sbloccare Samsung Galaxy Note 8
Sorgente: Note 8: riconoscimento facciale bypassato (come su Galaxy S8) – VIDEO
Ho fatto il test del nytimes, dopo aver letto il post su Il Post.
Pare che la mia abilità di filtrare distrazioni sia buona. Nonostate il mio odio verso le distrazioni e il mio sentirmi particolarmente vulnerabile ad esse. Probabilmente c’è di peggio.
Quanto al multitasking soffro un pò di context switching ma tuttosommato i risultati non sono male. Anche se questo secondo test mi ha richiesto decisamente maggiore concentrazione. Forse perche io associo pari a vocale mentre nel test un solo pulsante descriveva sia vocale che dispari mentre l’altro stava per consonante e pari.
In definitiva comunque pare che io non sia un multitasker. Anche se IMHO le performance personali possono essere molto influenzate dalla condizione mentale del momento. Ovvero la mattina potrei essere ancora meno multitasker (o con più capacità di concentrazione…) di quanto sono alle 20:51 di sera.
E questo sembra voler dire che non ho riprogrammato il mio cervello per gestire più stimoli contemporaneamente (e di gerstirli tutti male IMHO), come qualcuno sospetta che stia avvenendo in una parte della popolazione sovraesposta alla rete e alla multimedialità. Nonostante la mia indiscutibile sovraesposizione alla rete.
Comunque se è vero che si allena il multitasking è vero anche che si allena la capacità di concentrazione, e che non sono due cose in contrapposizione. Esistono situazioni in cui è richiesta capacità di focalizzazione e situazioni dove è premiante il multitasking, mentre in questi test il multitasking è trattato come il “prodotto di scarto” della condizione di non avere capacità di concentrazione. Che con tutto il rispetto per i ricercatori di Stanford, mi pare una semplificazione non trascurabile.