HOAB

Le problème :

Quand on est chez le client, il arrive qu'on doive transférer des fichiers dans un environnement "sécurisé". Il existe parfois des solutions de transfert :

• espace de partage sécurisé (permet de logguer les transferts)
• clé usb chiffrée

Et puis de temps en temps c'est galère (la clé n'est pas là, le transfert n'est pas accessible, ...) et votre fichier doit arriver chez le client. Or les .sh, .jar, .zip, .exe, sont mal vu... Normal. Les dropbox wetransfer, et autre FTP bannis, le partage WIFI bloqué, les fichiers scannés...

Pour autant la plupart des sites sont autorisés pour le travail (normal aussi).
 

Solution :

Il vous faut :

• une habilitation sur un poste client (sinon pourquoi voudriez-vous envoyer des fichiers ?)
• un espace disponible sur internet

Utilisez ce petit programme :

• côté pile : on rajoute du bruit avant le fichier à télécharger. On met ce fichier sur un espace internet
• côté face : on télécharge le fichier depuis cet espace neutre, on enlève le bruit

Si c'est un vrai virus, l'antivirus le verra lors de l'écriture du fichier sans bruit (enfin, on peut l'espérer). LE fichier n'est pas exécutable sans le "unhide", donc il faut une action humaine pour ça, donc ça limite parfaitement les risques.

Ca limite les risques, parce que si vous arrivez à faire exécuter ça à quelqu'un (transfert, compilation, téléchargement, unhide, exécution) alors vous avez largement les moyens de faire autre chose de mieux au niveau piratage.... social hacking.

Quand à savoir pourquoi on ne peut pas télécharger un fichier mais quand même l'exécuter, ça....

Ca dépanne de temps en temps.

package com.hidefile;

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.nio.channels.Channels;
import java.nio.channels.ReadableByteChannel;

import static java.lang.System.exit;

public class Hider {
    private static final byte[] bytes = "unelongueclepourquelesantivirusenaitmarrederegarder".getBytes();

    public static void hide(String filename) {
        try {
            String destFilename = filename + ".mdfy";
            ReadableByteChannel rbc = Channels.newChannel(new FileInputStream(filename));
            FileOutputStream fos = new FileOutputStream(destFilename, false);
            fos.write(bytes);
            fos.getChannel().transferFrom(rbc, bytes.length, Long.MAX_VALUE);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public static void unhide(String filename) {
        try {
            String destFilename = filename.replace(".mdfy", "");
            FileInputStream fis = new FileInputStream(filename);
            ReadableByteChannel rbc = Channels.newChannel(fis);
            FileOutputStream fos = new FileOutputStream(destFilename, false);
            System.out.println("bytes.length = " + bytes.length);
            fis.skip(bytes.length);
            fos.getChannel().transferFrom(rbc, 0, Long.MAX_VALUE);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public static void main(String... args) {
        if (args.length != 2) {
            System.err.println("Bad arguments : --hide|-h|--unhide|-u ");
            exit(1);
        }

        if (args[0].equals("-u") || args[0].equals("--unhide") ) {
            unhide(args[1]);
        }
        else {
            hide(args[1]);
        }
    }


}

Astuce, les extensions sont importantes : .png passe mieux que .jar.mdfy

Au pire, le bruit peut être un header PNG :

private static final byte[] bytes = new byte[]{(byte) 137,80,78,71,13,10,26,10};

Bien sur c'est en total non-conformité avec la charte d'utilisation de votre poste en général.

Le problème :

Avec une stack JHipster, spring-boot n'affiche pas les ressources statiques en mode développement.

Ddonc par exemple pas de index.html...

Pour autant si on lance la commande avec le war serverless (cf spring-boot-maven-plugin), ça fonctionne.

Je suis sous Intellij, à l'évidence quelque chose manque dans le lancement de la tâche Intellij spring-boot

L'architecture est mavenisé donc le root contexte est sous : src/main/webapp

Cependant spring-boot semble chercher ses ressources ailleurs : cf la documentation

Par quelle magie spring-boot doit-il trouver ses ressources dans src/main/webapp ??

Solution :

Beaucoup de recherches, de debug et autre (il y a un peu de spring-secu dans le lot). Au final les services jhipster classiques (health, dump, etc...) fonctionnent mais toujours pas de ressources statiques.

Vérification :

• de la tâche de lancement Intellij, elle semble correcte.
• des classpaths (on met src/main/webapp dans le classpath, on l'enlève) 
• des paramètres de lancement (profil Spring et autre)

Au final la mise en debug m'a permis de trouver un log perdu parmi les autres :

Tiens donc le Tomcat embarqué de spring-boot a ses propres chemins de recherches... (pas tout à fait décrit dans la doc Spring ci-dessus).

Breakpoint, watch, et paf, le chemin vers src/main/webapp en absolu n'est pas le bon.

Tout ça parce que le répertoire de travail de ma tâche spring-boot sous Intellij n'était pas fixé. Comment Intellij détermine cette valeur ? Mystère. En mettant donc le répertoire de travail égal au répertoire qui contient le src/main/webapp, tout roule (ici le répertoire de travail serait : /home/user/projets/monprojet/webportal.

On retrouve le log :

Eclairé aussi par ce lien

Problème :

Faire des threadumps un peu assisté pour Java sous Windows. Normalement, il faut :

• repérer le pid
• appeler jstack sur le pid
• stocker le résultat dans un fichier unique

Mais j'avais besoin d'un script oneshot que les utilisateurs puissent lancer facilement et plusieurs fois

Solution :

Merci aux différentes ressources du net, voici un petit script rapide :

@echo off

SET JAVA_HOME=c:\Program Files\Java\jdk1.7.0_51\
SET OUTPUT_DIR=c:\temp\lzg_threaddumps
SET COMMAND_TO_CHECK=java.exe

setlocal enableextensions
if not exist "%OUTPUT_DIR%" md "%OUTPUT_DIR%"
endlocal

for /f "tokens=2" %%F in ('tasklist /nh /fi "imagename eq %COMMAND_TO_CHECK%"') do (


    SET DEST_FILE="%OUTPUT_DIR%\%%F_%date:~-4,4%%date:~-7,2%%date:~-10,2%_%time:~-11,2%%time:~-8,2%%time:~-5,2%%time:~-2,2%.txt"
    @echo Dumping %%F to file %DEST_FILE%
    rem echo "%JAVA_HOME%\bin\jstack.exe" %%F
    "%JAVA_HOME%\bin\jstack.exe" %%F > %DEST_FILE%
)

Problem :

I have two thread groups that must be synchronized. I want to use

java.util.concurrent.CountDownLatch

to achieve this.

I read (here, or here) how to synchronize JMeter thread groups (you have to use properties and not variables). Properties can be access in :

• bsh sampler : bsh.shared.<property name>
• jsr223 sample : props.put(<property name>)
• the org/apache/jmeter/util/JMeterUtils.class is the source of these properties.

I add to my test plan an initial element in bsh, jsr223 to create the latch. But when I get the latch in the thread groups, I always had different instance of my shared latch.

Solution :

Easy when we know.

I made the mistake to add the piece of code in a Pre-Processor

• Test Plan
  • PreProcessor BSH : init latch
  • Thread Group 1
    • Sampler BSH : wait for latch
  • Thread Group 2
    • Sampler BSH : count down latch

In this case, the PreProcessor is run before each thread initialization. I run X times the preprocess sample.

Correct test plan :

• Test Plan
  • Set up Thread Group
    • Sampler BSH : init latch
  • Thread Group 1
    • Sampler BSH : wait for latch
  • Thread Group 2
    • Sampler BSH : count down latch

The setup Thread Group is run before the others thread groups (these ones are parallel until you say not to do)

Le problème :

I know that many post have been written on the subject, but has I do not had a quick solution. Here is some few more information.

When connecting to webex from Linux, I had no sharing.

Solution :

First I used Firefox 64 and JVM 64. It doesn't work. Whatever I read on the net (from this link, or there).

So :

1. Install i386 architecture
2. install firefox32 (< 52.x otherwise Java is not working for now)
3. create a separate profile
4. install missing packages... (when starting firefox32)
5. install 32bits JVM
6. create a link to the JVM plugin in the new profile
7. remove any shared plugin (for example JVM 64bits plugin in shared plugins library) : use plugins directory in profile

This is a quick & dirty, I'll try to update it after.

Useful tips :

• about:plugins in firefox
  • if the 32bits plugins is not there, or the JVM64 is still there, don't go further, correct this
• http://java.com/verify/
• remove webex directory : ~/.webex
• install missing packages for webex (ldd tips)
• sometimes it can be long when you are behind a proxy