Ir para conteúdo

ncaio

Apoiadores
  • Total de itens

    21
  • Registro em

  • Última visita

Reputação

10 Good

1 Seguidor

Sobre ncaio

  1. O uso da tabela ASCII na ofuscação de palavras

    7797110101105114111333297321091111181051091011101169799971113210011132971141149712132102105991111173298111974632671111051159732100101321131171011093210697321151111021141011173210911710511611132101109321151041011081083211599114105112116326193
  2. Linux congela ao iniciar

    Você não acha melhor reinstalar ? Claro que não sei qual é o custo disso para você.
  3. Editor de texto VIM

    hello @Valeyard, Quando você se tornar um usuário Vim, sim. Provavelmente você precise utilizar algo a mais. Minha IDE de programação é o Vim e 'plugins' para facilitar na hora de programar/desenvolver. * http://coderoncode.com/tools/2017/04/16/vim-the-perfect-ide.html Se você não usa o Vim como IDE, usa como um administrador de sistemas operacionais ou para editar/criar/manipular arquivos eventuais, por exemplo, talvez não precise de Plugins. Mesmo sem plugins, o editor é bastante poderoso.
  4. Linguagem de programação GO

    Massa. O Tour é interessante. Compartilha conosco como foio sua experiência, primeiro contato com o Go =].
  5. Linguagem de programação GO

    Olá pessoal, abri este tópico para que a comunidade Mente Binária possa trocar ideias sobre Go. Links úteis: Go web page: https://golang.org Tour of Go: https://tour.golang.org/welcome/1 Writing, building, installing, and testing Go code:
  6. m_159801.jpg

  7. 9YHTIaE.png

  8. 162321.jpg

  9. 107198.png

  10. 158730.jpg

  11. Cara de tacho

    source:
  12. Lá no blog do Anchises

    https://anchisesbr.blogspot.com.br
  13. FALANDO SOBRE OOM

    # # # Ncaio - caiogore $! gma1l (..) com # FALANDO SOBRE OOM # REVISÃO 01 31/10/2017 - TXT AND FILES-> http://8bit.academy/doc/OOM/ # # John Von Neumann serrou o pulso e declarou: "Um computador é composto de três partes fundamentais: o processador, os dispositivos de entrada/saída e a memoria.". Ele mudou de forma radical o conceito de computadores em meados de 1930. Estamos falando de calculadoras. Infelizmente, a ideia de armazenar um programa em memória junto com a parte de dados, demorou a entrar em prática por falta de tecnologia para se construir dispositivos de memória. Enquanto isso, os processadores não pararam de evoluir. Isso talvez explique o motivo dos processadores estarem, de longe, mais evoluídos em comparação aos dispositivos de memória. Sistemas operacionais lidam elegantemente com essa diferença de velocidade entre dispositivos de memória primária e processadores. E este delay tem nome, se chama wait states. Bem, mas este assunto rende muito pano para manga. Dentro deste contexto, o assunto segurança não fica de fora. Este documento fala sobre um dos tópicos da filosofia de segurança Linux que é, inclusive, adotada pelo(a) Android: Ensures that user A does not exhaust user B's memory. https://source.android.com/security/overview/kernel-security Em resumo, sistemas operacionais multiusuários como o Linux, por exemplo, o que fazer para evitar que um usuário não monopolize todo o 'espaço' disponível de memória, que não comprometa o sistema operacional e/ou os outros demais utilizadores ? Sabemos que erros ocorridos no processo de desenvolvimento de uma aplicação podem resultar em um alto consumo de memória em sua execução, assim como intencionalmente ( ou não ), um usuário pode desencadear este consumo. Quando um processo ameaça o funcionamento de um computador que utiliza Linux como sistema operacional por causa de sua fome incontrolável de memória, um mecanismo chamado Out of Memory (OOM) Killer entra em ação. O OOM é um cão de guarda que observa a consumação de memória de um processo e o ataca quando ele passa dos limites. Isso significa que o Linux sempre diz sim quando um programa pede mais memória (malloc())! Com isso, ele consegue, ou tenta, executar mais programas. Estamos agora falando de over-commit de memória. Vamos aqui abrir um espaço para falarmos sobre memória virtual. Memória virtual é uma abstração da memória física que possibilita mecanismos de segurança, extensão e compartilhamento, por exemplo, de forma mais eficiente de quê o acesso direto. O over-commit no Linux vem ativo por padrão! Por isso, um pedido de espaço na memória 'nunca' é respondido como NULL. Isso é motivo de muita discussão na comunidade em geral e o que nos interessa no momento, é: * Por padrão, o valor da flag over-commit é zero no Kernel do Linux ( https://www.kernel.org/doc/Documentation/vm/overcommit-accounting ); * Se um aplicativo pede memória, o Linux responde positivamente; * E quando este pedido de memória perde o controle, o OOM killer entra em ação e assassina o processo. Claro que é um resumo genérico e existem algumas entrelinhas. No entanto, este é o conhecimento base para continuarmos a falar sobre o mecanismo OOM. LAB Para acompanhar estes procedimentos de forma prática, é recomendado o uso de uma máquina virtual com o sistema operacional Linux instalado. NÃO execute estes procedimentos fora da máquina virtual! Certifique que a flag de over-commit é zero. cat /proc/sys/vm/overcommit_memory 0 O valor esperado é zero. Como alterar este valor ? echo "0" > /proc/sys/vm/overcommit_memory Os vídeos aqui anexados, apresentam 4 telas de terminais que representam o mesmo host, onde: * Terminal superior esquerdo: É executada a criação de estrutura com o mkdir; * Terminal inferior esquerdo: Pontuação do OOM; * Terminal superior direito: A saída do comando free -m; * Terminal inferior direito: Tabela de processamento. Telas: http://8bit.academy/doc/OOM/img-6.png LAB 01 - NA VIDA REAL Vamos pegar um exemplo do dia a dia de um administrador para a construção de situações que envolvem memória. Chico do Pentest recebeu a seguinte missão: Criar uma estrutura de diretórios com características: Exemplo da estrutura de diretórios: http://8bit.academy/doc/OOM/lista-dir.txt São duas camadas de dez(10) diretórios (0 - 9) que, dentro deles, tem outra camada de dez diretórios. Chico tem um bom conhecimento em shell e utiliza para este procedimento, expansão de variáveis. Como ele criou estes dois níveis ? mkdir -p {0..9}/{0..9}/ De forma simples, Chico resolveu o problema proposto no laboratório 1 LAB 02 - FATIANDO O PROBLEMA Não demorou muito para a equipe de desenvolvimento descobrir que a estrutura de pastas solicitadas não atenderia aos requisitos do sistema. O chamado retornou para a fila de atendimento de Chico, solicitando a adição de mais quatro níveis. Contabilizando agora, seis níveis. Chico aceita o desafio e logo pensa em aproveitar a linha de comando anterior, adicionando a quantidade de níveis solicitada. E assim fez. mkdir -p {0..9}/{0..9}/{0..9}/{0..9}/{0..9}/{0..9}/ bash: /usr/bin/mkdir: Argument list too long Vídeo: http://8bit.academy/doc/OOM/6-levels.webm Temos aqui dois problemas: * Dez elevado a sexta potência, igual a 1 milhão de strings para serem carregadas na memória (10^6=1000000); * 1 milhão de strings é um valor muito alto de argumentos para um único comando mkdir. O Linux faz over-commit de memória, isso significa que o problema número um seria descartado do processo de resolução de problemas de Chico, se não houvesse memória suficiente e que isso fosse degradar o funcionamento do sistema operacional, ele já sabia que o cão e guarda OOM Killer entraria em ação. Esta é uma situação que muitos administradores já passaram ou passarão no decorrer de suas carreiras. E a recomendação para este caso é fatiar o seu problema. Chico agora tem duas situações: Utilizar FOR e realizar a criação unitária em 10^6 ciclos. O exemplo a seguir mostra como o problema 1 não impacta no sistema operacional utilizado. Ele foi capaz de carregar 1 milhão de strings na memória e passar uma por uma ao comando mkdir. for i in {0..9}/{0..9}/{0..9}/{0..9}/{0..9}/{0..9}/; do mkdir -p $i; done Utilizar o comando xargs. Este comando irá passar para o mkdir, por exemplo, apenas a quantidade de argumentos que ele suporta naquele momento. Em comparação a utilização do FOR, é de longe a solução mais recomendada. Chico também aprendeu: * Limitação de recursos é uma prática importante; * Aprendeu sobre o comando ulimit; * Aprendeu sobre ARG_MAX ( https://www.in-ulm.de/~mascheck/various/argmax/ ). PAUSA PARA O OOM A ideia de cão de guardar foi entendida por Chico. No entanto, ele precisou descobrir mais sobre o comportamento do OOM. Principalmente sobre a heurística que determina se um processo passou ou não dos limites. Em sua pesquisa, Chico chegou a seguinte conclusão sobre como a pontuação OOM é calculada. * O primeiro modelo publicado em 2009 não se mostrou efetivo. Já que saia matando qualquer processo e quando necessário, continuava a matar processo sem descrição de importância; * O modelo de 2010 é o que utilizamos hoje; * Existe uma proposta de melhoria para o modelo atual, publicado em 2013; * Cada processo tem sua pontuação; * A abstração fica em proc/<pid>/oom_score; * A pontuação é baseada na porcentagem de uso de memória RAM + SWAP ; * O valor 1000 significa 100% de uso da memória; * 0 significa 0% de uso da memória; * Para processo root, subtrair 3% da pontuação; * Existe como desativar um processo da ação matadora do OOM; * Existe como marcar um processo como alvo preferencial para o OOM; * Este arquivo é /proc/<pid>/oom_score_adj Links de referência: https://lwn.net/Articles/317814/ https://lwn.net/Articles/391222/ https://lwn.net/Articles/548180/ LAB 03 - O CURIOSO Chico resolveu seu problema anterior utilizando o FOR e aprendeu que poderia resolver de outra forma, com o xargs, por exemplo. Descontente e curioso, ele tem a ideia de mandar mais argumentos para o mkdir. Neste caso, ele enviou a criação de oito níveis. mkdir -p {0..9}/{0..9}/{0..9}/{0..9}/{0..9}/{0..9}/{0..9}/ Vídeo: http://8bit.academy/doc/OOM/08-levels.webm O vídeo de exemplo mostra que o gatilho Argument list too long não foi disparado. E com isso, o mkdir começou a pedir memória para armazenar as 10 ^ 8 = 100000000 strings. Que equivalem mais ou menos, contando com NULL e SLASHES -> 15 bytes, 15 * 100000000 = 1500000000 bytes ou 1.3 GigaByte. No canto superior direito ( free -m ) é possível observar o decremento da memória RAM E SWAP, enquanto no canto inferior esquerdo, a pontuação OOM só aumenta, até chegar ao ponto que o interpretador de comandos, no canto superior direito, ser assassinado pelo OOM. OBS: Chico utilizou uma sequência de comandos para esvaziar o CACHE da memória virtual. echo "3" > /proc/sys/vm/drop_caches Chico não para de se perguntar: Por qual motivo 10^6 argumentos geram um Argument list too long e 10^8, não ? LAB 04 - O REVOLTADO Chico desabilita o over-commit e chega a conclusão que é perigoso. Ele tem o receio que o seus programas sejam mortos antes de concluírem seus ciclos de execução. Sem over-commit, o processo é morto, por padrão, quando utiliza 50% da memória física. Vídeo: http://8bit.academy/doc/OOM/disable-overcommit.webm LAB 05 - O MORTO VIVO Para finalizar, Chico teve a brilhante ideia de executar o comando mkdir para a criação de uma estrutura de 8 níveis e desabilitar o OOM do processo executor. Vídeo: http://8bit.academy/doc/OOM/score-prio.webm E para sua surpresa, a pontuação não foi incrementada, o processo consumiu toda a memória RAM + SWAP e mesmo assim foi morto. Até então, tudo ocorreu bem, a não ser pelo fato de do suposto PID assassinado continuar na tabela de processamento com o status Z (zombie process). Depois dos laboratórios, Chico do Pentest aprendeu que tudo precisa de limites e que sempre deve levar o assunto de segurança de recursos a sério.
  14. Lab para o ataque KRACK (WPA2)

    Olha só, se preocupe em fazer o deauth. Pode ser com o airplay, jammer ou manual (desativa interface de rede do cliente e ativa novamente). No entanto, o lab vai ocupar seu adaptador de redes com o hostap, ou seja, talvez você precise de outro adaptador para injetar o detauth
×