Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - devilicecream

Pages: [1] 2 3
1
Java / Re:Da jar a exe senza rivelare i sorgenti
« on: February 25, 2017, 01:07:56 AM »
You are not allowed to view links. Register or Login
Quando vado in pizzeria, la pizza la mangio dopo che è stata nel forno, non prima. Non la giudico in base a come il pizzaiolo ha messo gli ingredienti sulla massa cruda, ma dal sapore che ha.


Se compariamo lo sviluppo di codice al cucinare una pizza (con tutto il rispetto per i pizzaioli) sicuramente arriviamo alle conclusioni sbagliate. Giudicare il codice dal suo funzionamento (penso che questa sia l'analogia col sapore della pizza  :'( ) piuttosto che da come è stato scritto, ci ritroviamo poi con problemi di scalabilità, sia al livello di funzionalità che al livello di sviluppi aggiuntivi da fare sullo stesso programma. Per di più, eventuali bug o funzioni maligne verrebbero nascoste agli utenti, che di conseguenza avrebbero ancora meno interesse ad usare il tuo programma.


Se vuoi un'analogia più azzeccata: tu utilizzeresti un'auto che si accende e cammina per fare un viaggio di 1000km, senza assicurarti che il motore sia a posto, le ruote gonfie, i freni a posto e le sospensioni integre? E senza nemmeno poter controllare, perché chi l'ha prodotta ha nascosto tutte queste parti sotto un cofano che il proprietario non può aprire (e magari ci ha anche nascosto un gps tracker dentro)?

Io, personalmente, se installo un programma o una libreria pretendo di vederne il codice sorgente (e lavoro su Mac OS). Tuttalpiù faccio eccezioni quando il programma è sviluppato da aziende come Apple o Google, perché almeno so chi va a prendere i miei dati o chi denunciare qualora avessi problemi.

per g: nella pagina linkata da CrashTest, sezione 4.2, viene spiegato come funziona la compilazione. In short, la risposta è si. Ecco il link di nuovo: You are not allowed to view links. Register or Login

2
Java / Re:Da jar a exe senza rivelare i sorgenti
« on: February 23, 2017, 08:28:56 PM »
E quindi anche se il codice è incompleto quale sarebbe il problema ad esporlo? Se un utente del tuo programma è abbastanza in gamba da recuperare il codice originale dal jar, sarà anche abbastanza in gamba da capire che se era commentato non è da eseguire!
In più, non sono convinto che nei file .class vengano compilati anche i commenti!

3
Sicurezza Informatica / Re:Il significato di backup
« on: February 22, 2017, 04:04:38 AM »
Considerato che si tratta di seguire delle istruzioni, non mi abbatterei dicendo di non avere le competenze (seguire delle istruzioni non è poi così difficile!). D'altra parte però, sul forum dice chiaramente che le uniche versioni supportate sono la 520 e 525, in più senza connettività GSM o WiFi, senza audio e con il touchscreen da calibrare. Direi che almenochè non ti senti di brickare telefoni, che comunque è l'unica maniera per imparare davvero a flashare ROM, di evitare!


4
Java / Re:Da jar a exe senza rivelare i sorgenti
« on: February 22, 2017, 03:51:44 AM »
Java non è propriamente un linguaggio compilato, nè un linguaggio interpretato. Quello che succede quando passi da codice sorgente a eseguibile è che un compilatore Java (su Unix-like javac) compila i file .java in file .class, che altro non sono che la versione compilata in Java Bytecode del tuo codice sorgente. Una Java Virtual Machine (JVM) poi prende il Bytecode generato dalla compilazione e lo esegue o compilandolo in machine code (di solito nei sistemi embedded), oppure eseguendo direttamente le istruzioni dal Bytecode come se fosse uno script (compilazione JIT - Just In Time).
Il tuo file .jar altro non è che una raccolta di tutti i file .class contenenti Java Bytecode.
La ragione per cui non puoi nascondere il tuo codice in Java è perchè il Java Bytecode, dovendo essere abbastanza generico da poter essere interpretato facilmente dalle JVM indipendentemente dall'architettura hardware e dal sistema operativo, è facilmente decompilabile in codice Java. Questa è proprio la maniera in cui è stato ideato Java, e c'è poco da fare.
Esistono dei sistemi per "offuscare" il codice, i quali modificano i nomi delle variabili, delle classi e delle funzioni in maniera da rendere il codice illeggibile anche se decompilato, ma non è una soluzione definitiva, in quanto un attaccante esperto può risalire al codice sorgente studiando il codice decompilato.


Mettere una password al .exe piuttosto che al .jar non è una soluzione, in quanto renderesti illeggibile il file alla JVM che deve interpretare il Bytecode, e l'unica maniera per renderlo di nuovo utilizzabile sarebbe di togliergli la password.


Detto ciò, per quale motivo ci tieni tanto a nascondere il codice? C'è una proprietà intellettuale all'interno di cui vuoi riservarti i diritti facendo un brevetto? È un programma talmente unico nel suo funzionamento da volerlo proporre a livello commerciale? Se la risposta a una di queste domande è si, allora si potrebbe anche discutere di tenere il codice sorgente nascosto (e comunque, anche in questi casi, non è sempre una buona idea), altrimenti ti assicuro che tenere il codice nascosto è inutile e, anzi, controproducente!

5
La soluzione aggiornata è portabilissima! La libreria aggiuntiva (è hostata su bitbucket) consiste in pratica di due file, uno in C e uno in python. Volendo si può tirare giù ed utilizzarla dal source code, senza basarsi su pip per gestire la dipendenza.
Il fatto che ora sia tutto in un modulo python rende la soluzione stessa un "sottoprogramma": una volta installato il pacchetto in una env, basta importare la funzione main per eseguire i ping, o la classe NetworkProperties da sola per ottenere un oggetto che contiene tutte le informazioni sulle interfacce di rete  ;)

6
You are not allowed to view links. Register or Login
Per l'occasione ho fatto ping_network e netinfo:
You are not allowed to view links. Register or Login
Puoi prendere spunto o usarli aggiungendo il multiprocessing,
oppure inserendoli nel progetto EXPLOITED se vuoi.. fai te.
Li ho fatti anche per @devilicecream che adesso, per supportarci, minimo ci deve mettere una stelletta :)
e aprire un sacco di issue per i bugs  :-X


Aperto issue e pull request!  :P

7
Mi piace quello che hai fatto Dario, e infatti la stelletta te l'ho messa! Ci sono un po' di cose da migliorare però, ci sto dando un'occhiata sulla mia VM ubuntu ;)

8
Certo! Solo che mi pare siano già presi!

9
Eccomi! Io prenderei i progetti comuni e Javascript, che è rimasto senza mod :)

10
Concordo con Dario sul problema di verificare prima lo spazio di indirizzi su cui andare a fare il ping sweep.
Modificando leggermente il codice che ha postato proprio Dario dovrebbe essere semplice integrare questa funzionalità.


Per quanto riguarda la tua paura di mettersi a lavorare in concorrenza sulle stesse features, su github ci sono varie maniere per gestire la cosa. La mia preferita (e una delle più utilizzate nei grandi progetti open source) è questa:
 1. Chiunque identifichi una feature aggiuntiva o una falla, aggiunge una nuova issue (You are not allowed to view links. Register or Login).
 2. Se ne discute sul topic dedicato, quindi si sceglie una persona che ci lavora su, che diventa assignee della issue.
 3. L'assignee, e solo lui, forka l'intero repository e lavora sull'implementazione del bugfix/nuova feature. Tutte le comunicazioni riguardanti quel problema vengono fatte sul topic di quella issue su github.
 4. Quando ha finito, l'assignee fa una pull request sul repo principale, aggiungendo nel commento una reference alla issue originale.
 5. Se ci sono problemi nel merge automatico, o se si vogliono fare altre aggiunte, si ricomincia dalla 3. altrimenti si prosegue fa il merge della nuova feature/bugfix e si chiude la issue.


Ti apro una issue con il problema evidenziato da Dario, proviamo a seguire questo flow?

11
0.1a / Re:feedback, betatesters, qualcuno l'ha provata?
« on: February 03, 2017, 07:40:58 AM »
Devo ancora installarlo, ma posso solo provarla sul raspi B2! I B3 che ho non sono proprio miei...  ::)
Intanto propongo un'idea per la prossima versione, che potrebbe essere utile a scopi didattici.


Si potrebbe mettere a disposizione della gente che segue i vari corsi la possibilità di connettersi da remoto ai raspberry del lab tramite una web shell, in maniera tale che possano testare roba e/o fare esercizi in maniera super semplice (e sicura).


Non chiedetemi perché, ma ho già lavorato su un sistema che funziona più o meno così:


- All'utente viene dato username-password del raspi per fare login sulla shell.
- L'utente si registra su un portale/piattaforma web.
- I raspi hanno un servizio che comunica con il portale/piattaforma web attraverso internet (ovviamente).
- I raspi non hanno ip pubblico.
- L'utente si logga sulla piattaforma, e viene autorizzato a connettersi da remoto al raspi.
- L'utente va su una pagina web dalla quale verrà esposta una shell del raspi.
- Il raspi indicato riceve dal portale web una notifica della richiesta di connessione. Allegati alla richiesta ci sono una chiave privata RSA valida temporaneamente, e la porta su cui il portale esporrà la shell, scelta a random.
- Il raspi fa partire il server che espone la web shell.
- Il raspi apre un reverse SSH tunnel verso il portale web, dalla porta dove lui serve la web shell alla porta dove verrà servita dal portale web.
- Il raspi notifica il server che il tunnel SSH è stato aperto.
- L'utente viene reindirizzato verso la pagina dove ora viene servita la web shell del raspi.


Alla chiusura:
- Il portale web notifica il raspi che deve chiudere il tunnel SSH, ed elimina la chiave privata RSA usata per la connessione.
- Il raspi spegne il server che espone la web shell e chiude il tunnel SSH.
- Il raspi notifica il server che il tunnel è stato chiuso.


Ho trovato su github un bel progetto per una web shell, che viene già distribuito nei repository di alcune distro, per quanto sia più stabile e funzionale se buildato dal source.
Eccolo: You are not allowed to view links. Register or Login


Con una architettura di questo genere si evita di creare VPN, spesso instabili a causa di firewall o altri problemi nella rete, e si ha pieno controllo delle autorizzazioni degli utenti nell'accedere da remoto ai raspberry.


Che ne dite?

12
A chi non serve un capannone in russia dove coltivare patate per fare la vodka....

13
Sul mio vecchio ubuntu avevo un alias che lo accodava in automatico (altrimenti me lo dimentico sempre). Qui sul Applecoso mi limito a floodare di ctrl-t e poi mi faccio il calcolo. Esiste però pv compilato per Darwin, appena ho tempo mi riscriverò l'alias anche qui.

14
Tutorials - E-Books / Re:Pensare da Informatico con Python
« on: February 03, 2017, 06:27:26 AM »
Una delle cose interessanti di python è che ha bindings per praticamente quasi tutti i linguaggi più importanti! In pratica puoi scrivere del codice in C (ad esempio), e in maniera abbastanza semplice adattarlo per chiamare le funzioni dal codice python! Gran parte delle librerie che fanno operazioni intensive (ad esempio la famosa Pillow, che serve per manipolare le immagini) sono in realtà scritte in C, e poi adattate per essere utilizzate in python. Ma in realtà ogni volta che chiami una funzione viene eseguito il codice compilato in C!  ;)

15
Yep! argparse è la soluzione che preferisco quando devo fare roba che prende argomenti da linea di comando. Un po' macchinoso, ma funge bene  :)

Pages: [1] 2 3