Create Native iOS and Android Apps with JavaScript
Open source framework for building truly native mobile apps with Angular, Vue.js, TypeScript, or JavaScript.
Sorgente: Native mobile apps with Angular, Vue.js, TypeScript, JavaScript – NativeScript
Proudly debugging the system since 1981
Create Native iOS and Android Apps with JavaScript
Open source framework for building truly native mobile apps with Angular, Vue.js, TypeScript, or JavaScript.
Sorgente: Native mobile apps with Angular, Vue.js, TypeScript, JavaScript – NativeScript
AutoVer is a configurable automatic or real time backup and personal versioning system. It can be used as a simple real time backup or as a more complex, but transparent version control system (like a realtime incremental backup). The beauty of this system is that once you set it up (which is extremely simple) it does everything. No remembering to backup or to check in or check out files. Every time you save a file it is copied to your backup folder, drive or FTP server. You can include and exclude certain files and browse the backups with the Backup Explorer.
Great for backing up (or one way synchronising) your work or home documents to flash memory or saving every change you make to your source code or image files.
A lightweight powerful flow control component enabling reliability and monitoring for microservices. (????????????? Java ?) – alibaba/Sentinel
As distributed systems become increasingly popular, the reliability between services is becoming more important than ever before. Sentinel takes “flow” as breakthrough point, and works on multiple fields including flow control, circuit breaking and system adaptive protection, to guarantee reliability of microservices.
Sentinel has the following features:
- Rich applicable scenarios: Sentinel has been wildly used in Alibaba, and has covered almost all the core-scenarios in Double-11 (11.11) Shopping Festivals in the past 10 years, such as “Second Kill” which needs to limit burst flow traffic to meet the system capacity, message peak clipping and valley fills, circuit breaking for unreliable downstream services, cluster flow control, etc. […]
Sorgente: alibaba/Sentinel
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 :
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.
Volevo pubblicare un video su youtube che fosse la velocizzazione di uno acquisto dalla dashcam, portandolo dalla durata di 9 minuti a 1 minuto e 30 secondi.
Gli strumenti utilizzati sono AVIDEMUX e AUDACITY.
Per velocizzare la traccia video bisogna impostare un output del video in formato a scelta, a questo punto sarà possibile impostare i filtri. Il primo filtro ( Change FPS ) velocizza il video aumentando i frame per secondo, mentre il secondo ricampiona il video all’FPS desiderato. Cosi le impostazione mostrate si ottiene un video velocizzato 6 volte ( 30×6 -> 180fps ) ma che mantiene in output i 30 fps
AVIDEMUX non offre molti filtri per l’audio. Diciamo quasi nessuno. Per cui meglio esportare la traccia audio (Audio -> Salva traccia) e rielaborarla con AUDACITY. Con l’effetto “Cambia tempo e intonazione” è possibile velocizzare l’audio come è stato fatto precedentemente con il video e salvare il risultato.
Ottenuta la traccia audio coerente con il video si può effettuare una sostituzione in AVIDEMUX sostituendo appunto l’audio originale con quello velocizzato ottenuto precedentemente (AUDIO -> Seleziona traccia audio ) e salvare il risultato.
Gli ammortizzatori del bagaglio sono un componente soggetto ad usura, dopo un pò di anni perdono la pressione del gas interno e non fanno più il loro lavoro con la conseguenza che il bagaglio della macchina tende a cadere sulla testa dello sfortunato proprietario.
Il procedimento di sostituzione è simile per tutte le auto, ma foto, link e codici sono specifici per la BMW Z4.
Per prima cosa procurarsi il pezzo sostitutivo. Usare uno shop online, se sapete il codice del pezzo, è il modo migliore per risparmiare anche il 70%. Il codice del pezzo (part number) per tutte le Z4 sia E85 (roadster) che E86 (coupè) è 51247016186. Ad oggi è ancora disponibile su Amazon il pezzo che ho comprato io https://www.amazon.it/gp/product/B07H7FZ9YX/
Entrati in possesso del pezzo di ricambio è utile avere la collaborazione di qualcuno che tenga sollevato il bagagliaio.
L’aggancio in alto e in basso è realizzato con una clip metallica, e si sgancia inserendo sotto un cacciavite a taglio in modo che la clip metallica resti sollevata rispetto alla testa dell’ammortizzatore. Questo procedimento va fatto sia per sganciare i vecchi ammortizzatori, sia per agganciare i nuovi.
Tolto il cacciavite la clip torna al suo posto e l’aggancio è fissato.
Tutto fatto !
© 2025 b0sh.net
Tema di Anders Noren — Su ↑