Logo Hardware.com.br
Demarchi_
Demarchi_ Membro Junior Registrado
76 Mensagens 0 Curtidas

Assembly - Manipulando Endereços de Memória

#1 Por Demarchi_ 23/10/2011 - 15:55
Boa Tarde.rindo_ate_agora.png

A estudar assembly, me apareceram algumas dúvidas das quais não encontrei resposta.
Vou citar um exemplo mais fácil para minha compreensão, corrigam se eu estiver errado.:nao_sei_de_nada:


Em um jogo de RPG qualquer, o dano do seu personagem é armazenado em algum lugar, este lugar seria um endereço de memória correto? Como faço para conseguir analisar os endereços de memória de um jogo e modifica-los? É assim que surgem os cheater de jogos, como cheater do Grand Chase, que aumenta o dano do personagem?

Existe algum programa específico para manipular endereços?
memoria boa jogo enderecos estudar assembly manipulando tarde rindoateagora
OS: Windows 7 / Debian Squeeze / Backtrack 5
Processador: AMD Phenom II x2 3.20 (x4 B50)
Memória: 2 GB DDR3 1066 Mhz Kingston
VGA: XFX ATI HD 5550 1 GB (low profile)
Fonte: Casemall 500WR
Monitor: SAMSUNG Sync 21"
Jogolos: adeus.gif Nenhum, só estudando
Fergo
Fergo Highlander Registrado
9.3K Mensagens 1.1K Curtidas
#16 Por Fergo
28/10/2011 - 21:38
Demarchi_ disse:


Exatamente.
No seu código, o algoritmo em si está entre 80483b5 e 80483d2. O resto é organização da pilha. Curioso notar também que ele está usando um endereço de memória para realizar a contagem de iterações (ebp-0x8) ao invés de um registrador. Talvez seja questão de otimização do compilador.
Site pessoal ● www.fergonez.net
Portfolio ● www.fbirck.com
Artigos ● Informática
Demarchi_
Demarchi_ Membro Junior Registrado
76 Mensagens 0 Curtidas
#17 Por Demarchi_
31/10/2011 - 10:17

80483b5: c7 45 f8 00 00 00 00 mov DWORD PTR [ebp-0x8],0x0


No exemplo acima irá mover 0x0 para ebp-0x8, no livro que estou lendo, tal instrução aparece assim



80483b5:    c7 45 f8 00 00 00 00     mov    DWORD PTR [ebp-4],0x0


Aparece como ebp-4 e não 0x8, seria alguma configuração na sintaxe, estou usando sintaxe intel. Pois no livro ele explica uma coisa, e eu seguindo os mesmos passos o mesmo programa, os resultados em assembly são diferentes, uma coisa que percebi, no livro ele vem com uma distribuição Linux, bootavel, não consigo subir ela no PC da assinatura, agora consigo no meu PC antigo, Atlhon xp 1.6, creio que deve ser alguma versão desatualizada do Kernel, talvez sejá por isso que eu tenho resultados diferentes? Pois meu kernel é atualizado, Não fiz os testes usando o LiveCD que vem junto, irei fazer e postar aqui.

Obrigado a todos.
OS: Windows 7 / Debian Squeeze / Backtrack 5
Processador: AMD Phenom II x2 3.20 (x4 B50)
Memória: 2 GB DDR3 1066 Mhz Kingston
VGA: XFX ATI HD 5550 1 GB (low profile)
Fonte: Casemall 500WR
Monitor: SAMSUNG Sync 21"
Jogolos: adeus.gif Nenhum, só estudando
Henry-Keys
Henry-Keys Geek Registrado
1.8K Mensagens 235 Curtidas
#21 Por Henry-Keys
24/10/2012 - 04:35
snowamigu disse:


Sim usando assembly inline você consegue, mas a forma como você usa assembly inline varia de compilador para compilador, ou seja, enquanto que no turboC, BCC (tds da Borland) você usa assembly inline com a sintaxe Intel, no GCC e suas variantes você usa uma sintaxe assembly muito feia e gostosa a AT&T.

Só que existe um porém, você não pode usar interrupções nos compiladores C de modo protegido como o MingW, VisualC++, etc.


O que eu posso fazer com assembly que a lingaugem C não faz ?


Gerar executáveis estremamente pequenos e velozes. Conhece o John Carmack, fundador da Id que foi a criadora do gênero FPS, ele usa asm inline em todos os jogos desenvolvidos pela Id, resultado = jogos com gráficos bonitos que não precisam de um PC de top pra rodar sem incômodos. anjinho.gif

Você pode também criar injectores de DLL's para alterar certos valores no espaço de memória de um jogo.
Comentários Bestas (StackOverflow) mostrando_dentes.png
Eliseu F A Jr
Eliseu F A J... Geek Registrado
776 Mensagens 354 Curtidas
#22 Por Eliseu F A J...
24/10/2012 - 09:28
Fergo disse:


Excelente artigo ( e raro ) para quem quer mexer com assembler.
Já programei com ASM Z80 e 6502. No tempo usavamos um programa chamado disassembler, mas programei pouca coisa era só mesmo pequenos testes para aprender a mexer.
No tempo da popularização do PC decada do 80, não acompanhei a evolução da linguagem para a linha intel 8088, mas não há muita diferente. De um processador para outro só mudam as regras, mas a lógica é a mesma.
O assembler não é tão fácil de manipular, por isso é chamada de linguagem de baixo nível.
▶ Home Page ▶ Plus Google ▶ Canal Youtube ▶ Superdownloads ▶ Twitter
ripongao
ripongao Veterano Registrado
755 Mensagens 94 Curtidas
#23 Por ripongao
24/10/2012 - 09:49
boas Senhor Eliseu;
Brinquei com Z80 durante um tempo, na época dos antigos hotbit,expert (mercado nacional), e videogames como master system. Bons tempos aquele.
Realmente um diferencial do idioma assembly é que estamos mais próximo da máquina. Fiquei um pouco receoso ao querer comentar que usando-se um disassembler poderemos analisar malwares, coisas que não conseguimos realizar em C.
Citar sobre convenções de chamadas, stdcall para win32, fastcall para win64, fastcall para linux64 (que é diferente da fastcall para win), ... .
Geralmente programadores em C jamais se perguntam:
"por que devo começar o programa com 'main'", ou ainda, "o que acontece com meu programa antes de chegar à função 'main'".
Sem contar manipulações estruturadas de erros característicos dos S.O.'s em questão. Outro fator é saber popular o processador que hoje esta mais canalizado, com o máximo de instruções possíveis para atingir melhor otimização e desempenho para realizar algo, e ainda estar por dentro de novas instruções e tecnologias. Tudo isso é invisivel aos olhos dos programadores de alto nível, e continuará invisível.
abraços.
Desliguei-me do fórum. Conta canelada.
Eliseu F A Jr
Eliseu F A J... Geek Registrado
776 Mensagens 354 Curtidas
#24 Por Eliseu F A J...
24/10/2012 - 11:33
ripongao disse:


Muito diferente daquele tempo em que muitas vezes eramos obrigado a aprender se quiséssemos extrair algum recurso extra do computador.
Hoje quase tudo é muito mais simplificado. Em poucos cliques resolvemos quase tudo.
Será que toda essa otimização está criando essa barreira aos olhos dos programadores de alto nível ?
▶ Home Page ▶ Plus Google ▶ Canal Youtube ▶ Superdownloads ▶ Twitter
ripongao
ripongao Veterano Registrado
755 Mensagens 94 Curtidas
#25 Por ripongao
24/10/2012 - 12:07
Creio que sim senhor;
naquele tempo não tinha tantas convenções e regras a serem seguidas, usávamos qualquer registro ao nosso bel prazer, hoje estamos limitados a usar determinados registros para alcançar a portabilidade ou devidas convenções.
Otimizar programas em assembly virou uma arte, antes otimizávamos por tamanho, hoje por tamanho e velocidade. Compiladores inserem muitos overheads (caput) no programa final, gerando arquivos enormes.
No 8088/86 tínhamos apenas os registros gerais, depois introduziram o co-processador para o interior do processador (fpu), atualmente, temos instruções mmx,xmm,avx,... que conseguem manipular vários bytes simultaneamente (em um pulso de clock), e existem pipelines (canalizações) de modo que temos que pensar em paralelismo ao programar. Regras ainda para alinhamento dos dados na memória, que na época do Z80 nem imaginávamos, pois trabalhávamos apenas com bytes de modo geral. A memória volátil entrou para dentro do processador (cache), temos que saber por alto quantos dados ou código nosso programa final terá para caber dentro das mesmas.
A barreira foi criada tanto pelos fabricantes dos S.O., como tambem a evolução dos processadores, e consequentemente pelos criadores das linguagens de programação. Se existisse apenas uma convenção de chamadas, então um programador pascal ou visual basic poderia facilmente usar bibliotecas de funções feitas por c e vice-versa. E em contrapartida, os desenvolvedores dos S.O's botaram os dedos no contexto e virou um zoológico.
Programadores de alto nível ao tratar divisões por zero (exceções) usam try,catch, e para portarem seus programas para digamos, do win32 para win64 mudam apenas uma linha de código e o compilador o trata. E existe diferença sobre manipulações estruturadas de erros que são diferentes nos S.O.'s citados.
O padrão 386 foi caracterizado por tratar pontos flutuantes usando-se a fpu, hoje para x86_64 usa-se instruções xmm para tal.
Uma vez me perguntei: porque será que não posso colocar acentos ou cedilhas em rótulos (label) ou nomes de funções? Porque não posso criar uma função chamada "função"?.
abraços.
Desliguei-me do fórum. Conta canelada.
© 1999-2024 Hardware.com.br. Todos os direitos reservados.
Imagem do Modal