Jump to content

unc4nny

Membros
  • Posts

    29
  • Joined

  • Last visited

  • Country

    Brazil

Everything posted by unc4nny

  1. Oi. Estou procurando integrantes (dois) para o CTF da trendmicro. Não precisa ser experiente ou hackudão trevoso, nem eu nem meu colega somos! Queremos participar pela experiência somente 🙂
  2. brabo o artigo, bem completo, explicou mto bem o que eh, por q fazer, e como fazer. Os links q tu colocou sao brabos tamem
  3. Oi. Talvez voce ja tenha se deparado com algumas amostras de Malware em que ele acessa o PEB para depois acessar a export table de alguma Dll e resolver uma funcao em runtime, evitando deixar strings no arquivo compilado para dificultar nossas vidas. Acredito que o nome dessa tecnica seja "Resolucao dinamica da IAT" (@Fernando Mercês se eu tiver falando abobrinha mim disgurpe pfvo D:). Nao pretendo escrever um artigo sobre como funciona isso, ja que eu provavelmente nao sei o suficiente, masss... Eu escrevi um Proof of Concept (PoC) e coloquei ele no meu GitHub. Segue alguns prints que eu tirei durante a execucao dele: A funcao LoadLibraryA sendo carregada e posteriormente chamada: Conteudo no registrador eax: Conteudo na pilha (note o argumento sendo passado) Visao no Ghidra: O codigo fonte esta disponivel no meu repositorio. Se voce tem interesse em dar uma olhada, talvez ajude voce a reconhecer esses padroes mais rapido na proxima vez que voce for analisar um malware. Essa documentacao visual do Corkami tambem eh muito util. Eu ainda estou trabalhando no codigo, eu pretendo deixar ele muito bem documentado e legivel, ja que eu ainda acho que a documentacao sobre esse assunto ainda eh meio escassa. Eventualmente, eu ainda pretendo fazer de um modo que nao deixe uma string sequer no programa. Mas se voce quer algo que funciona logo, mesmo que nao muito bem documentado (na minha opiniao podia ter mais comentarios, mas como dizem... bons codigos falam por si mesmo), existe o lazy_importer. Eu fui obrigado a usar as definicoes de struct do codigo dele, ja que havia se passado uma semana e eu nao fazia idea do porque estava dando Acess Violation 0x000005. Ainda nao descobri o porque, mas nao havia muita diferenca entre as definicoes dele e minha, enfim... (mas aprendi sobre o reinterpret_cast lendo o codigo dele).
  4. Putz vdd eu tinha esquecido completamente do tracing!!! Vlw mano vou usar isso aqui! :P Outra coisa, vc sabe se tem como colocar break points em todas as calls no x64dbg? Acho q eu vou fazer isso tamem
  5. Oi. Estou analisando um malware e consegui realizar o unpack do que eu imagino que seja o payload. Nao sei em quantas etapas o malware eh dividido pois esse foi o primeiro payload que eu conesgui extrair do malware ate agora. O payload eh um shellcode que foi copiado para um endereco de memoria que foi alocado utilizando o VirtualAlloc, depois eh somado 0x42b7 ao endereco base, e antes de retornar, esse endereco eh colocado na stack. Para fins de ilustracao: eax = VirtualAlloc() eax = copy(eax, shellcode) eax=eax+0x42b7 push eax ret Entao o endereco de retorno da funcao atual eh sobreescrito para esse novo offset. Mas oq realmente importa aqui eh o fato que esse shellcode esta extremamente obfuscado: O autor do malware colocou varios codigos inuteis no programa, por exemplo o js, e eu nao sei se tem mais. O que eu gostaria de saber eh se existe algum metodo para otimizar meu tempo e evitar de fazer o stepi de todo o codigo? Pq o shell code ficou bem grande (talvez seja coisa da quantidade de obfuscacao utilizada). Obrigado desde ja!
  6. 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
  7. @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!
  8. 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!!!
  9. 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?
  10. 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!!
  11. 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?
  12. 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!!
  13. 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!
  14. 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
  15. 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!
  16. Faz sentido mano. Deu pra dar uma esclarecida agora, brigadao cara
  17. 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
  18. 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!
  19. 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!
  20. 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!
  21. Entao, tentei fazer o exercicio que o Fernando deixou pra gente na aula 0 do AMO. Acabou que eu nao cheguei exatamente em um resultado, mas eu acho que cheguei perto. Entao aqui vai minha 'nao-solucao' (O sistema que eu uso eh Manjaro Linux, soh por via das duvidas): A primeira coisa que eu fiz, foi voltar pra VM e abrir o arquivo com o pestudio mais uma vez, soh pra dar mais uma olhada na tabela de strings que o pestudio formou. Nela eu achei algumas coisas interessantes: Uma sequencia de caracteres que representa os caracteres da base64 (A-Z, a-z, 0-9, + e /) e duas "stringonas". Uma delas eh aquela que ele mostrou no video, de tamando 1128, e outra de tamanho 368. Alem de strings em russo e alguns sites. Okay, fiquem com essa informacao da string de caracteres em base64 em mente, vai ser importante (talvez) la pra frente. Mas como o desafio era entender a stringona, eu foquei nisso. A primeira coisa que eu tentei fazer foi decodificar a string: Esse foi o resultado. Nao ajudou muita coisa entao eu tentei ver que tipo de arquivo ele eh: Okay, aparentemente eh uma stream de bytes, dumpando esse arquivo eu obtive: Isso tambem nao ajudou em nada. Entao eu peguei a outra "stringona" e fiz a mesma coisa, pulando pra parte do dump, ela ficou desse jeito: Tambem nao ajudou em muita coisa, mas nessa a gnt ve uma sequencia de caracter conhecida: 'RSA1', um criptosystem bem conhecido. Mas o objetivo eh a outra stringona. Entao ele tem duas strings (que eu saiba) codificadas em base64, e uma outra string com caracteres de base64, me parece razoavel pensar que ele vai decriptar essas strings dentro do programa, usando uma implementacao de decriptador caseira. Com essas informacoes e suposicoes, eu pulei pro ghidra pra tentar ver onde essas strings sao usadas: Procurei strings com no minimo tamanho 63, para ver se encontrava onde os caracteres base64 sao usados, que provavelmente seria o decoder dele: Infelizmente, ghidra nao conseguiu achar a string dos caracteres base64, mas achou as outras 2 stringonas. Entao, peguei a maior e fui ver onde ela era usada: Vemos que o ghidra identificou que a string eh utilizada em 6 ocasioes diferentes, vamos ver entao. Todas as 6 vezes sao na mesma funcao, apelidade pelo ghidra de FUN_004013F2. Essa eh uma das vezes que ele usa ela: Ele pega o tamanho da string, faz um calculo maluco que eu nao entendi o motivo com ele, cujo resultado deu 846. Pega o HANDLE para a heap do processo. Que chamou a funcao, que no caso eu imagino que seja o proprio ransomware. Aloca um bloco de tamanho 846 na heap do processo. A seguir, ele de novo faz o calculo do tamanho da stringona, mas usa ele com outro proposito: Ele chama a funcao que o ghidra apelidou de FUN_0040133e, passando como primeiro argumento a stringona, e como segundo o tamanho da string, entrando na funcao: Esse eh o resultado do decompiler do ghira. Nao entendi muita coisa dessa funcao, pra ser sincero, quando tem muita manipulacao de bit na funcao eu geralmente soh ignoro kkkkk. Mas algumas coisas nessa funcao chamaram minha atencao. Primeiro que eu ja estava esperando que essa stringona fosse chamada em uma funcao desse estilo. Pois como ja foi dito, eu esperava que ele decodificasse ela dentro do codigo. Entao eu fui na internet procurar por algumas implementacoes de um decoder base64: Nao vou falar que eh 100% igual, mas existem semelhancas muito grandes. Entao eu continuei a explorar com a suposicao que aquele era o decoder dele. Mas soh tem um problema, ele nao usa nenhum tipo de retorno, e o ghidra nao especifica se ele esta usando de fato um literal de string ou um endereco de memoria. Entao eu parti pra analisar as instrucoes e ver o que elas me dizem Antes de passar pras instrucoes, notem que depois que ele chama o 'decoder' ele faz faz mais uma vez aquele calculo doido com o tamanho da stringona e chama uma funcao da API do windows, CryptDecrypt: Eu poderia ver o que eh este DAT_0040F968. Mas isso vai alem do escopo do exercicio. Eu ate tentei, mas assim como esse exercicio, eu cheguei numa resposta mais ou menos hehehe Aqui esta a sequencia de instrucoes ate o CryptDecrypt: Aqui, percebi que realmente, aparentemente ele nao utiliza o resultado da funcao que eu estava chamando de decoder, e que ate agora ainda acredito que seja, pois ela eh usada mais uma vez em um contexto similar, no que eu acredito que seja a outra stringona, mas isso vai alem do escopo do exercicio. Voltando para CryptDecrypt, os argumentos passado para ela sao: Segundo a API do windows, essa funcao decripta dados que foram previamente encriptados usando a funcao CryptEncrypt, que inclusive eh o contexto que eu me referi onde a outra stringona eh usada, com a funcao que eu acredito que seja o decoder. Essa eh a assinatura da funcao, entao, fazendo a cross-reference com a assinatura e com os parametros que foram passados pra chamar a funcao, da esquerda pra direita: DAT_0040F968 = hKey (Um HANDLE para a chave que sera usada para decriptacao, esse HANDLE foi gerado pela funcao CryptImportKey, pelo que eu pude perceber a outra stringona tambem sera usada nessa funcao. Acredito que a outra stringona na verdade seja usada para encriptar, e essa para decriptar.) 0 = hHash (Um HANDLE para um objeto hash, o valor eh zero entao provavelmente eh um ponteiro nulo) 1 = Final (Um valor booleano que indica se esta eh a ultima secao de blocos a ser decriptada, o valor eh 1 entao ela eh a ultima ou a unica) 0 = dwFlags (Nao ha flags, entao nao precisamos nos preocupar, mas isso seria imagino que algumas opcoes adicionais para a decriptacao) pbData = pbData (Na verdade, como podemos ver la em cima, esse eh o valor do bloco alocado de heap do processo. Segundo a API do windows, esse valor deve ser um ponteiro para o buffer que contem os dados a serem decriptados. Depois que a decriptacao eh realizada, o plain text eh colocado nesse buffer ) pbwDataLen = pbwDataLen (Eh o valor daquele calculo doido que eu nao entendi direito com o tamanho da stringona maior. Segundo a API, isso eh o tamanho do buffer a ser decriptado, que no caso ja vimos que eh 846). Entao eh isso. Essa eh a minha "nao-solucao". Nao cheguei a entender completamente (na vdd acho que n entendi foi nada kkkk) o motivo dessa stringona, seria ela apenas uma tecnica de defense-evasion ou ela tem mais algum outro motivo que eu nao consegui captar? Ajuda o maluco que ta doente aki kkkkk Atualizacao: Aparentemente 846 eh o tamando da stream de bytes que representa a stringona decodada. Entao parece justo eu assumir que esse calcula na verdade eh uma otimizacao do compilador ou o ghidra nao conseguiu interpretar isso como uma chamada de funcao? Ou talvez realmente seja algum tipo de calculo que ja existe, vou dar uma pesquisada sobre
  22. Faz tempo que eu vi o CERO, to aproveitando o tempo livre da quarentena pra re-assistir kkkkkk. Mas eu acho que fala sim, se eu nao me engano foi no seu video que aprendi sobre isso pela primeira vez, dai eu fui dar uma pesquisada sobre, mas faz tempo tambem, esses ultimos semestres foram foda, tive que focar quase que 100% na facul e deixei isso de lado, dai to voltando aos poucos. Esse cara aqui da um gas legal nessa parte de linkadores se vc tiver interessado (acho que sao 20 posts): https://www.airs.com/blog/archives/38 Vou dar uma olhada nesse livro tambem, vlw irmao! Eh noissss, manda muito
  23. Muito boa a explicacao, deu pra dar uma clareada absurda. Soh mais algumas duvidas: Pq a .got.plt precisa da permissao de escrita, alem da leitura? Seria por causa da relocacao em runtime, ou eu to viajando? Bixo, esse arquivo parece mto interessante, vou pesquisar sobre ele, parece o tipo de coisa que eu preciso saber sobre. Tem alguma leitura que vc possa me direcionar sobre ele? mto obg, mano, ajudou bagarai!!
  24. Opa! To atrasado aqui mano, mas eu nao sei se eu to viajando, mas qual a diferenca entre o layout da memoria virtual de um executavel e as secoes ELF? Eles parecem ser 2 coisas diferentes, mas parecem ser muito similares. Eu to viajando?
×
×
  • Create New...