Ir para conteúdo
  • Cadastre-se

cpuodzius

Membros
  • Total de itens

    8
  • Registro em

  • Última visita

Tudo que cpuodzius postou

  1. Se o host for dedicado a analise de malware, não vejo a utilização de dockers como uma má ideia. Além disso, essa não é a única maneira de utilizar docker durante sua análise.. você pode montar uma infra (e.g. servidor DNS, proxy, etc) que podem registrar coisas para você durante sua análise. Ou então, algo bem legal seria encapsular sua sandbox dentro de um container (e.g. docker-cuckoo, mas não testei esse projeto ainda 😞). Uma aparente limitação, que talvez alguém possa me esclarecer, é se é possível usar Docker no Windows para rodar um ambiente de usuário (i.e. Windows 7/8/10 e não um Windows Server da vida) que poderia ser acessado via RDP, por exemplo, para fazer análise. Imagine uma imagem docker dessa com FlareVM que mão na roda não seria...
  2. Legal o post e a discussão, well done! Só uma dúvida de carater preciosista, @Felipe.Silva. Se bem entendi, quando você diz "endereço raw", você está se referindo ao RVA (relative virtual address), seria isso? Aproveitando a deixa: @gzn, não vejo o porquê de linkar estaticamente e sem símbolos faria diferença na hora de achar a função main. Qual seria o impacto disso? Além disso, quando inclui a condição de ser modificado por um "protetor de mercado", você está interessado de achar a main do binário resultante ou do binário "original"? []s!
  3. Talvez disassemblers modernos consigam ligar com casos simples como esse (honestamente, não tentei verificar), mas o que está por trás desse exemplo é algo mais um pouco mais intrincado se resolver de maneira genérica. Trata-se do que é conhecido como predicado opaco. Predicados opacos são condições, nesse caso (2 != 3) que sempre levarão ao mesmo resultado. Se pensarmos, ao invés desse caso, por que não calcularmos x² + 2xy + y² = (x + y)²? Ou algo ainda menos evidente... fato é que predicados opacos são cada vez usados e um assunto "quente" para se pesquisar (ou pelo menos é a impressão que derivo do microcosmo que frequento, em que há pessoas que se dedicam exclusivamente a tentar resolver esse problema). Fiz uma leitura diagonal bem ligeira desse artigo e me parece ao menos descrever bem o problema. Prometo tentar lê-lo com mais calma quando tiver mais tempo e voltar para comentar. ✌️
  4. Classy! 😉 Para não dizer que não falei das flores, desenvolvendo um pouco o raciocínio por trás da questão 1 (i.e. comparar os bytes em hex), essa não me parece ser uma má ideia inicial (pelo menos a principio não vejo por que). A partir do endereço onde o hex difere, poderia-se procurar mais informações a respeito deste endereço (seção, etc.. como feito no artigo). Certamente é um caminho um pouco mais longo, mas não vem ao caso. Estou escrevendo tudo isso apenas para dizer que alguns visualizadores de hex, como o HxD, possuem uma função para isso. ✌️
  5. cpuodzius

    Portscan em Python

    O que a mensagem de erro leva a crer é que você está atingindo o limite de file descriptors (lembre-se que no Linux tudo é descripto por arquivos). A diferença entre fazer o scan na sua rede local e na Internet é a latência envolvida, portanto quando você realiza o scan na sua rede, rapidamente o SYN ACK (porta aberta) ou RST (porta fechada) e o socket é fechado, enquanto na Internet essa resposta tarda mais a demorar. No entanto, o que deve estar acontecendo é que a porta não está nem aberta nem fechada, mas sim, filtrada. Nesse caso você não vai receber nenhuma resposta e seu socket vai continuar aberto (alocando um file descriptor). Seu script não está tratando esse caso... o que aconselharia fazer é setar um timeout, depois do qual você considera a porta filtrada. Obs.: No Stackoverflow há uma referência que pode te ajudar a debugar a questão do file descriptor.
×
×
  • Criar Novo...