Jump to content

unc4nny

Membros
  • Content Count

    22
  • Joined

  • Last visited

  • Country

    Brazil

Community Reputation

6 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Oi. Esse dias eu ouvi falar do banker trojan que vai pelo nome de IcedId. Saiu bastante noticias sobre ele na epoca e entao eu peguei uma sample e fui tentar brincar com ela. O malware aparentemente tem 2 stages de unpacking, o primeiro, depois de muito google-fu e leitura, eu consegui passar. Agora o segundo eu to com mais dificuldades. O primeiro estagio do unpacking me devolveu um arquivo PE, entao eu abri ele no PE estudio e um indicators diz o seguinte: 1525,The file contains another file,type: unknown, location: overlay, offset: 0x00019C00,1 Depois, eu fui dar uma olhada nesse offset dentro do arquivo, e nao achei nada, nao soh isso, mas o arquivo nao tem import table. Depois de uma pesquisada eu vi que existe uma parada chamada Dynamic Library Resolution, onde um malware faz a resolucao da import table em tempo de execucao. Talvez seja ate o q esta acontecendo aqui, mas como eu sei eh isso que esta acontecendo e nao eu que fiz cagada? Enfim, o PEBear diz que as secoes do binario estao dispostas dessa forma: Eu nao consegui achar nada dumpando o binario. Em disco o offset indicado pelo pestudio eh o final da .reloc, entao acho que nao eh la que eu preciso olhar. O PEBear tambem diz que em memoria, a secao .data comeca no offset 0x3000, mas tem tamanho 0x18800, entao eu imagino que o arquivo que eu estou procurando deva estar la. O problema eh que a secao nao aparece no binario em disco, ja que a secao nao existe nele, e eu nao to conseguindo achar no binario em memoria. Alguem tem uma ideia boa por onde comecar? Se alguem quiser o hash da sample, avisa, eu nao sei se eu posso postar aqui auiasuiduas
  2. @Fernando Mercês usei a parada do message breakpoint, mto massa mano! Vou ver se acho um crackme em GUI pra tentar usar de novo, junto com o tracing :c. Valeuuuu!
  3. Ahhh po, faz sentido, por isso que o debugger tava caindo na user32.dll do nada mesmo dando step over, talvez ele interprete o callback como uma chamada de funcao no mesmo modulo? Dei uma lida aqui na documentacao das funcoes que estao sendo chamadas no inicio do codigo e acho que entendi o que ta acontecendo. Tambem vou dar uma lida nesse link que vc postou, parece bem interessante! Pior que eu cheguei a tentar fazer isso mas nao dava certo, eu acho que eh porque o codigo fica loopando na WinMain ate receber o input? Ou talvez eu estivesse fazendo errado (o mais provavel asuidasuih). O que funcionou pra mim foi colocar um breakpoint de escrita na secao .data e passar o registro (eu chutei que o buffer onde eles seriam copiados fossem variaveis globais ja q eu n cheguei a ver nenhum buffer sendo inicializado no disass), e funcionou aausdasuihdh Vlw mano!!!
  4. Oi. Estou tentando utilizar um truque que foi mostrado na palestra Debugging Tricks na MBConf v1 (onde o cara mostra como fazer o tracing do programa), no crackme do cruehead utilizado pelo Fernando nas aulas do CERO, porem nao esta dando 100% certo; o que eu estou fazendo: Botao direito -> Trace Record -> Start Run Trace Depois vou em: Trace -> Trace Record -> Trace over into trace record E depois clico em Animate Over. Ele funciona inicialmente, o problema eh quando eu insiro as credenciais que o crackme pede, ao inves de continuar a animar e fazer o tracing, ele simplesmente pula pra mensagem de erro, entao as unicas intrucoes que o x64dbg highlighta sao essas: Que eh basicamente o inicio da main thread ate a parte que eu clico em register, e ele nao mostra o caminho que o codigo toma depois de eu inserir as credenciais. O que eu gostaria que acontecesse eh que ele highlightasse tudo que ocorre depois que eu insiro as credenciais. Voces sabem se eh possivel fazer isso?
  5. Rapaz eu tava pra conseguir um projeto no NERDS com Magnos mas o coronga acabou com o esquema uiahsuiahsduias... Mas ele ta me ajudando bastante, ele eh brabo mesmo, manja muito e parece que ta sempre disposto a ajudar. Cara... isso seria incrivel!!! Esse semestre eu estaria entrando no setimo periodo (com ainda algumas materias de matematica pra tras kkk), nao sei oq vai acontecer pq a UFES suspendeu ensino a distancia, entao eh provavel que esse semestre va pro ralo. TOPPPP. Se for rolar mesmo eu com certeza estarei la!!! Eu tenho um amigo que esta estudando junto comigo InfoSec e a gnt tem se ajudado bastante, ele curte mais a parte de Web, vou arrastar ele pra la tambem, vlw mano, vc eh brabo!!
  6. Maycon, eu estava lendo seu blog, e vi que vc falou que seu TCC foi focado em InfoSec. Eu faco C-Comp na UFES tambem e tambem queria que meu TCC fosse nessa area. Eu curto muito a parte de exploracao de binarios e tava pensando que talvez pudesse ser algo sobre isso, eu espero que eu aprenda mto mais coisa ate o final da facul para que eu possa expandir minhas opcoes kkkkk). Vc teria alguma dica mano?
  7. Cara, muito obrigado mil vezes!!! Depois que eu enviei a pergunta eu achei esse inline assembly e nao tava conseguindo fazer funcionar nem a pau. Ops, eh vdd, my bad. Cara mto obrigado!!
  8. Oi. No livro Practical Reverse Engineering, o autor mostra um trecho de codigo asm. Numa parte do codigo, tem a seguinte sequencia de instrucoes: Pesquisando eu vi que o sidt eh uma instrucao que carrega o Interrupt Descriptor Table no endereco especificado, e ele esta comparando para ver se o base address do IDT esta no range especificado no codigo (8003f400h-80047400h). Isso eh uma tecnica para ver se o programa esta rodando em maquina virtual. A duvida vem aqui: Na hora que o cara vai explicar (decompilar o codigo) ele faz da seguinte maneira: typedef struct _IDTR { DWORD base; SHORT limit; } IDTR, *PIDTR; BOOL __stdcall DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved){ IDTR idtr; __sidt(&idtr); if (idtr.base > 0x08003f40 && idtr.base < 0x80047400) return FALSE; } Minha duvida eh justamente no __sidt(&idtr); Fui tentar reproduzir um codigo similar aqui na minha VM, mas da erro de compilacao. Estou usando o Dev-C++ Segue o codigo: #include <windows.h> #include <stdio.h> typedef struct _IDTR{ DWORD base; SHORT limit; } IDTR, *PIDTR; int main(){ IDTR idtr; __sidt(&idtr); printf( "Base: %d\r\nLimit: %d\r\n", idtr.base, idtr.limit ); return 0; } O erro sendo gerado eh: undefined reference to __sidt. To lendo a documentacao do __asm no site da microsoft mas ate agora nao achei nada que me ajudou. Alguem pode me dar uma luz? Eu quero escrever o Interrupt Descriptor Table em alguma variavel que eu consiga ler, ou ate mesmo ler o IDTR em si. Obrigado desde ja! EDIT: Eu esqueci de escrever o #include <intrin.h> que supostamente eh o headerfile onde __sidt esta definido, mas esta incluso!
  9. Cara, acho que entendi tudo o que voce disse (eu espero haha), explicou muito bem. O que realmente me bugou foi o uso do edi como acesso ao indice do vetor, eh isso mesmo que ta acontecendo? Pq eu achava que o acesso nesses segmentos era feito por SEGMENTO:OFFSET, ai esse [ edi * 4 ] me bugou muito, pq que o asm esta usando essa sintaxe? Na minha cabeca seria assim: ds:[0x100011a + edi * 4] <- isso faz sentido? Eh a primeira vez que eu vejo essa sintaxe. Mto obrigado mano vc eh brabissimo
  10. Oi. Estou lendo o livro practical reverse engineering, e nele, o autor fala sobre otimizacao de switch-case statements usando jump tables. Aqui esta o Assembly e a representacao em Pseudo-C do autor: Eu realmente nao to entendendo muito bem o que esta acontecendo: O que a linha 03 no codigo ASM quer dizer? No sentido em que, eu acho que entendo mais ou menos o que "ds:offset" significa mas nao entendi o motivo/significado desse [edi*4], principalmente comparando com a linha 01. Se nela o codigo compara edi com 5, como que ele esta usando o operador de acesso a memoria em [edi*4]? Como que o autor fez essa conversao de asm para pseudo-c? Ele compara edi com 5, e se edi for maior ele pula para a linha 16, que segundo o pseudo-c dele eh o 'default', se for menor ou igual, ele faz uma maracutaia que eu nao entendi muito bem. Tambem nao entendi como que no switch-case dele ele conseguiu achar 6 comparacoes (De 0-5)? Outra coisa eh esses saltos incondicionais para loc_10001145, mas no pseudo-c dele o endereco nem aparece. Resumo: O que o asm esta fazendo a partir da linha 03 ate a linha 24? E como que o autor sabe que ele esta comparando com 0, 1 ... 5? Espero ter explicado minha duvida certinho, hehe. Obrigado desde ja!
  11. Faz sentido mano. Deu pra dar uma esclarecida agora, brigadao cara
  12. Opa, foi mal.Minha duvida eh, como que funciona o casting da funcao para uma string? Isso parece meio esoterico, pelo menos na minha cabeca ashduiahsduih
  13. Oi. Me pediram pra formular minha duvida melhor no video que o Fernando fez de CRC. Bixo, eu achava que entendia de C, mas o jeito que esse CRC funciona me bugou um pouquinho. Depois de pensar um pouco eu ate consigo ver oq esta acontecendo, mas eu nao sei se eh isso que esta acontecendo bool checa(char *nome, int serial) { int serial_correto = 0; while (*nome) serial_correto += *nome++; return (serial == serial_correto); } int main(void) { char nome[50]; int serial; uint32_t crc = crc32((unsigned char *)checa, 63); O unico jeito que eu vejo de isso funcionar do jeito que parece que esta funcionando eh se ele pegar todos os bytes que representam essa funcao: 000000000000129b <checa>: 129b: 55 push rbp 129c: 48 89 e5 mov rbp,rsp 129f: 48 89 7d e8 mov QWORD PTR [rbp-0x18],rdi 12a3: 89 75 e4 mov DWORD PTR [rbp-0x1c],esi 12a6: c7 45 fc 00 00 00 00 mov DWORD PTR [rbp-0x4],0x0 12ad: eb 15 jmp 12c4 <checa+0x29> 12af: 48 8b 45 e8 mov rax,QWORD PTR [rbp-0x18] 12b3: 48 8d 50 01 lea rdx,[rax+0x1] 12b7: 48 89 55 e8 mov QWORD PTR [rbp-0x18],rdx 12bb: 0f b6 00 movzx eax,BYTE PTR [rax] 12be: 0f be c0 movsx eax,al 12c1: 01 45 fc add DWORD PTR [rbp-0x4],eax 12c4: 48 8b 45 e8 mov rax,QWORD PTR [rbp-0x18] 12c8: 0f b6 00 movzx eax,BYTE PTR [rax] 12cb: 84 c0 test al,al 12cd: 75 e0 jne 12af <checa+0x14> 12cf: 8b 45 e4 mov eax,DWORD PTR [rbp-0x1c] 12d2: 3b 45 fc cmp eax,DWORD PTR [rbp-0x4] 12d5: 0f 94 c0 sete al 12d8: 5d pop rbp 12d9: c3 ret 0x55, 0x48, 0x89, 0xe5... etc, castar para char*, e fazer o calculo. Eh assim que funciona mesmo? Se eu estiver errado (O que eh bem provavel kkk) alguem me ajuda ai! Obg desde ja!
  14. Oi. Estou tentando resolver um desafio de pwn, e o desafio eh basicamente realizar um buffer overflow. Contanto, o binario esta com praticamente todas as opcoes de seguranca ativas: Eles dao o codigo fonte do arquivo para nos estudarmos: Pelo oq eu pude observar do codigo, eu preciso escrever o suficiente na variavel overflowme para que ele sobrescreva o valor do parametro key. Mas o binario esta com a opcao de canary ativada. Lendo por ai eu descobri que existem dois jeitos de lidar com o canary: fazendo leaking e brute forcing. Aparentemente o brute forcing eh para situacoes que o proprio binario faca forks dentro de si mesmo para executar um possivel parametro q eu passei pra ele (servidores pro exemplo). Entao soh me sobra a opcao de leaking, isso se eu estiver correto. Alguem consegue me ajudar? Obg desde ja!
  15. Oi. Se eu nao me engano eh por regra da linguagem. Primeiro eh bom notar que um ponteiro NAO eh um array, e um array NAO eh um ponteiro. Se nao estou enganado, {1, 2, 3} nao eh exatamente um array de inteiros, mas sim uma lista de inicializadores. Isso pode ser usado para inicializar um array de inteiros, mas nao um ponteiro, por exemplo: int a[] = {1, 2, 3}; Por baixo dos panos, isso esta na verdade: Reservando um espaco de sizeof(int) * 3 na stack Colocando cada valor em a[0]...a[2] indivudualmente. Por ex: a[0]=1; a[1]=2... Para voce fazer algo semelhante ao que vc quer fazer, vc pode usar compound literals. int *a = (int []){1,2,3}; Neste trexo vc esta criando uma lista anonima de inteiros, e depois designando um ponteiro para a primeira posicao dessa lista, atravez do array decay. Acho que usei alguns termos mais avancados nessa explicacao, mas o que eu estou tentando dizer eh: Isso nao eh possivel pois eh regra da linguagem! Espero ter ajudado!
×
×
  • Create New...