Categoria: debugging

Una cosa che sapevo e una che ho scoperto

debugging•by bosh•Posted 6 Aprile 20206 Aprile 2020•0 Comment(s)

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.

Dagli all’untore

debugging•by bosh•Posted 22 Marzo 202022 Marzo 2020•0 Comment(s)
Alla primavera non frega nulla dei nostri problemi.

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.

Hacking YI Dome / YI Home Ip camera – 4° Puntata

debugging•by bosh•Posted 9 Marzo 20199 Marzo 2019•0 Comment(s)

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?

Hacking YI Dome / YI Home Ip camera – Seconda puntata

debugging•by bosh•Posted 24 Febbraio 201923 Febbraio 2019•0 Comment(s)

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.

Hacking YI Dome / YI Home Ip camera – Prima puntata

debugging•by bosh•Posted 23 Febbraio 201923 Febbraio 2019•0 Comment(s)

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.

Per arricchire la statistica

debugging•by bosh•Posted 8 Giugno 2010•0 Comment(s)

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.