Como interceptar arquivos temporários criados por um programa? [duplicado]

Question

TL; DR : Eu sei que um programa cria e exclui arquivos em /tmp . Como posso interceptá-los para exame?

Contexto :

Há um arquivo .jar específico, no qual não confio; por alguma razão, seu código-fonte contém um método ftm e tem capacidade de fazer conexões, o que é evidente a partir de syscalls relacionados à rede na saída de strace (e quando eu quero dizer conexão, não me refiro a soquetes de domínio unix, é AF_INET6 ). Eu examinei com o Wireshark e não vi conexões TCP ou UDP de saída durante o uso.

No entanto, eu ainda não confio muito. Da saída de strace , vi que está criando arquivos temporários em /tmp e, em seguida, os exclui. Existe uma maneira de interceptar esses arquivos para examinar seu conteúdo?

    

Answer 1

Melhor ainda, se você quiser fazer engenharia reversa de um binário de Java nefasto, em vez de tentar interceptar arquivos, descompile o arquivo .jar do suspeito.

Para isso, você pode usar o CFR - outro decompilador de java

CFR will decompile modern Java features - up to and including much of Java 9, but is written entirely in Java 6, so will work anywhere

To use, simply run the specific version jar, with the class name(s) you want to decompile (either as a path to a class file, or as a fully qualified classname on your classpath). (--help to list arguments).

Alternately, to decompile an entire jar, simply provide the jar path, and if you want to emit files (which you probably do!) add --outputdir /tmp/putithere

Não há falta de alternativas, no entanto, o projeto CFR parece estar bem mantido, tendo uma atualização de 2018.

Disclaimer: Eu não fiz engenharia reversa para binários Java / JAR desde 2005

    

Answer 2

Observação : solução aprimorada postada em uma pergunta duplicada

A partir da leitura de Como acessar o arquivo temporário logo após a criação? Eu tive a ideia de usar inotify e criar um link físico para o arquivo em si. Isso, obviamente, é uma condição de corrida, já que o arquivo pode ser desvinculado antes que o link físico seja criado. No entanto, consegui recuperar os dados no arquivo temporário que o aplicativo está criando. Aqui está um pequeno pipeline juntos na aba do terminal A, com a aba do terminal B executando o comando real:

inotifywait -m -r /tmp/hsperfdata_xie/ 2>&1 | 
while IFS= read -r line; do 

    awk '$2 == "CREATE"{system("ln /tmp/hsperfdata_xie/"$3" /tmp/BACKUP")}' <<< "$line"
    echo "$line" # unnecessary, only if you want to know what's inotify is writing
done

As 3 desvantagens são:

• condição de corrida (explicada acima)
• eu juntei awk muito rapidamente para um arquivo específico; mas um comando awk mais geral e flexível que analisa inotifywatch output e associa pathnames $1 com nomes de arquivos em $3 teria que gastar um pouco de tempo para analisar as linhas, sprintf() everything para variável e passar para system() , que pode voltar ao ponto anterior - quando a análise é feita, não há nenhum arquivo para vincular.
• requer duas guias de terminal, embora seja possível colocar todo o pipeline em segundo plano. Uma maneira mais inteligente seria ter um script Python completo com subprocessos bifurcados e realmente usar os módulos inotify do Python (o que talvez seja algo que eu faça no futuro).

Quanto ao arquivo em questão, ele aparece como uma forma de dados binários, com 0...sun.rt._sync_Inflations e 0...sun.rt._sync_Deflations strings recorrentes (o que pode estar relacionado a Java multithreading ). Mas para o propósito desta questão, é irrelevante - nós já temos. A única coisa que eu queria é obter o arquivo em si.