Is there really no way to learn asm from a beginner's level?

[shaynox]

Do you want always modify variable of other programs ?

Cause it that case, windows will don't let you to do that :p (memory protection)

Else if you want to swim in that huge space, hmm begin to ... just display memory, you can begin to test if you can print the first case of RAM (0x0000_0000__0000_0000) :p

[Evlesoa]

If you say that I can't, then explain this video below? I want to be able to create a menu so that I can modify visual effects, for example. Let's say I want to be able to get that "under water diving" screen to be on for me even when my character isn't water-diving. Or let's say I want to be able to get the visual effect of making myself look cool (like changing my model). All of this is just variables in memory. I think it would be nice to make something like this: https://www.youtube.com/watch?v=Sc6Lt2jWAiY

Assembly can do that, right? High level languages can, for sure, but assembly? How? That's what I want to learn and be able to do. And eventually move to more advanced stuff.

[shaynox]

hmm, you still would love to take the dark side of the force :p

Hmm so ok let's go I don't have any knowledge, but I will try to help you to start.

First you need to explore/analyze RAM's memory (http://mh-nexus.de/en/hxd/), then you will need to modify correct value of game's target, after you can create an hook, for target the rip register in your own program.

For make an hook, you need to make, hmm, theoretically, insert a call    (your_program) into game RAM's space.

So like I don't really want to try that or in long long future, I will let you how to to that, but take care when Windows put any program in RAM, it will split your program into two or more part (I'm little noob in OS architecture even if I begin to write my own :p).

This split make many part, like I know there are data part and code part, data part is modifiable but code part is unmodifiable, you can try it by do this with nasm (windows x64):

[shaynox]

And I have a other question for help me to build my new topic "Factorization of instructions block" if you want :p

What do you think about that transformation:

Source:

Code: [Select]

mov [instance         ], rcx
mov [previous_instance], rdx
mov [cmd_line         ], r8
mov [cmd_show         ], r9d

Dest:

Code: [Select]

_mov {[instance], rcx }, {[previous_instance], rdx}, {[cmd_line], r8}, {[cmd_show], r9d}

Is it easier to read ? yeah I would like to put ( ) instead { }, but nasm don't let me to do this :p

[Bryant Keller]

Remote code injection has been done in a few different ways. The most common method is by writing a stub that loads the program as a child process under debugging and manipulation the child processes memory. This style of code injection requires the developer to familiarize themselves with the debugging API's available on their system. The other method is by hijacking a DLL that the program uses in order to modify the memory map from within the program at the moment the DLL is loaded.

The first method is definitely worth learning to do because it's the basis for learning to create your own debuggers, which is a great project! The second isn't quite as useful because it's an attempt to subvert the executing program and could potentially be flagged as malware (which isn't a good thing).

To preform the first method you should learn about the Windows Debugging API. These functions can be called from assembly once you are familiar with the platforms calling conventions.

The only problem of Flow Diagrams, it's if we begin to get used to those kind of system, we'll get disgusting about assembler language, cause there so much abstraction that we lost notion of register/pointer/MMIO/PMIO/... . I don't say it's not a good idea for start, but it's not needed to stay learn long long time with that system to risk to be attracted to other language instead assembler :p

I disagree. If I was to tell a novice to write a program to convert all lowercase ASCII characters in a string to uppercase, they might find that problem a daunting task. However, if I was to tell the same novice to implement the attached flowchart in assembly, it's not unreasonable to expect them to come up with something like:

Code: [Select]

;; toupper - convert lowercase characters to uppercase.
;; @param esi Address of string.
;; @return String in ESI is altered.

toupper:
;; Start of procedure
;; Load next byte from string
next_byte:
LODSB

;; Does byte equal zero?
CMP al, 0

;; If so, goto done.
JZ done

;; Is byte greater than 'a'?
CMP al, 'a'

;; If not, goto next byte.
JL next_byte

;; Is byte less than 'z'?
CMP al, 'z'

;; If not, goto next byte.
JG next_byte

;; Subtract 32 from byte.
SUB AL, 32

;; Write byte back to string.
MOV [esi - 1], al

;; Goto next byte.
JMP next_byte

;; Return from procedure.
done: RET
Notice how each of the smaller steps were easier to implement than the much grander task. By learning (from the start) to break down your algorithms into smaller parts, you simplify the process of writing low level code.

[Evlesoa]

Thanks for all of your replies, once again.

Yeah, hijacking a dll I think is a bit like a sorry excuse for something when there's a better way of doing it. I would prefer to familiarize myself with it first, if given the option. I know everyone tells me that one should learn Windows API stuff. And if I learn it, how will I use it? How will I know that I am using it correctly?

Then... I'm not even sure how to write a stub that loads something as a debugger for a child process. This makes me want to ask: how did you guys begin learning this? what did you do to practice? what was the first thing you made? and what did you read for resources?

As a matter of fact, Shaynox, that did make it a bit easier to understand. Thanks for the example.

And Bryant, I know what you're talking about in regards to flow charts. It's quite clear, actually, and very logical. I also understand what the code is trying to do, yet I doubt I can write the same thing. I guess it's just I don't understand memory too well. Unlike assembly, unfortunately, there are many tutorials for this in other programming languages. It's kind of weird... you'd think the base would get most attention, but no... it's the higher level stuff that gets so much attention.

Thanks for the links, too. I've bookmarked and will read them as I have free time.

[shaynox]

Hi,

And if you want you can play with the stack, so let's explain how OS work a little (with my knowledge):

First Windows is mutli-taksing system, and for do that, it needed to execute all program by run each instruction of all program.

Those program so are execute instruction after instruction, it's call Task-State Segment (TSS) I guess (cf chap 7 multi tasking http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf).

And for execute those program without hurt other program, it needed to store the context of program in the stack (rsp).

Then when you run your program, Windows put this on ram, then call the entry of your program after save the return address of other program in rsp, like a classic call instruction.

Like you know or will, function store local variable in stack by subtract rsp for store all data used + the return address (8 byte for x64 and 4 byte for x86), before call the function.

So you can play wit this rsp, for jump/analyze the previous program, and why not previous of previous program for found your target.

After it's theoretical, just test this code and why not display those data:

Code: [Select]

start:
xor rax, rax
hack_mem:
inc rax
mov qword [rsp + rax],  0xdeadbeefdeadbeef
jmp hack_mem

 

[Bryant Keller]

I know everyone tells me that one should learn Windows API stuff. And if I learn it, how will I use it? How will I know that I am using it correctly?

The API is the "Application Programming Interface" and it's a predefined set of routines, data types, and equates that allow you to interface with that particular system. For example, the Windows API is contains everything a programmer needs to write software that runs on Windows. The POSIX API contains everything a programmer needs to write software that runs on UNIX (POSIX Compliant) systems. Each of these API's also include a large amount of documentation (Most have examples written in popular high level languages but the concepts transfer to assembly as well).

Then... I'm not even sure how to write a stub that loads something as a debugger for a child process. This makes me want to ask: how did you guys begin learning this? what did you do to practice? what was the first thing you made? and what did you read for resources?

I've been a programmer for a long time, so you're probably not going to learn in much the same manner as I did. But when I first started to use Windows (sometime in 2003) I began by grabbing a copy of the Windows API reference manual and set out to develop a simple text editor. As I familiarized myself with all the basic controls and dialogs, I then extended the text editor to include build support and a snippets manager. These things gave me a lot of experience with interprocess communication. At that point I started reading up on the Windows Debugging API (that I posted earlier) and used that to provide basic debugging support to my editor. After that, I hit up Iczelion's website and learned about the PE/EXE layout and played around with driver development using the Windows Driver API. Of course I probably couldn't do most of that stuff anymore since I've not even used a Windows computer since sometime around 2007-2008.

Also note, that the calling conventions document I linked you to above will explain how to actually invoke the routines contained in those API's. So you should probably acquaint yourself with that.

And Bryant, I know what you're talking about in regards to flow charts. It's quite clear, actually, and very logical. I also understand what the code is trying to do, yet I doubt I can write the same thing. I guess it's just I don't understand memory too well. Unlike assembly, unfortunately, there are many tutorials for this in other programming languages. It's kind of weird... you'd think the base would get most attention, but no... it's the higher level stuff that gets so much attention.

Thanks for the links, too. I've bookmarked and will read them as I have free time.

One of the best assembly tutorials I've seen in quite some time actually belongs to one of the regulars on this forum (avcaballero). His website has a tutorial which walks the reader though a very large set of examples. Some of his documents are not translated to English yet, but there is more than enough to get you started. You should check it out.

[Evlesoa]

@shaynox
This is similar to all the languages that I've looked at, because they all run on windows, of course. Thanks for giving me the details to it. Useful information in general. I'll think of this when I do memory-related stuff.

@Bryant
Hmm. Ok. I did know what API stands for, because I used to go to various tech conventions, but wasn't sure what it did. Just thought it was like "SLI" for all programs in some manner or another (because it interacts).

I guess I don't have any questions left for now except for one. How did you start developing a text editor? You, I think it was, who said that you need a solution to a problem? In this case, what problem are you facing when you set out to program the text editor? Or is it as simple as "I don't have any software to write stuff in?"

I'm going to look up some stuff on youtube and do some reading!

[shaynox]

Hello, I have a compilation of tool for you:

- http://wqaxs36.perso.sfr.fr/Project/Computer_Science/nasm/10.TOOLS/Programmers_tools.zip

Enjoy.

[Evlesoa]

woo, cool! Thanks shaynox!!

[Bryant Keller]

I guess I don't have any questions left for now except for one. How did you start developing a text editor? You, I think it was, who said that you need a solution to a problem? In this case, what problem are you facing when you set out to program the text editor? Or is it as simple as "I don't have any software to write stuff in?"

What I said was:

The reason for programming is to IMPLEMENT a solution to a problem. So in order to learn to program effectively, you must first learn to DESIGN a solution.

My problem was a lack of familiarity with the Windows API. The solution was a text editor which allowed me to ease my way through various user controls, dialogs, and into more complex things like custom controls for syntax highlighting. However, the statement "I don't have any software to write stuff in" kinda also applied since at the time my only development tools were NASM, ALINK, Windows Notepad and some .bat scripts.

The suggestion to focus more on learning to design your software was based around the idea of teaching yourself to systematically break down complex tasks into tasks which will be much easier to implement. By having the tasks broken down from the beginning, you'll be able to focus in on implementation details without worrying about the larger task at hand, once each of the smaller tasks are completed (if the complex task was well defined) the implementation as a whole should "Just Work". At least that's the theory. In practice however, there are always points in which software bugs can present themselves in your work. That's why the best programmers aren't the ones who write great code, rather the ones who can effectively debug the bad code.

[Evlesoa]

Ah, I see. Dang.

So you basically already knew how to do a lot of stuff already. Seems like I got a lot to learn. I got another question, then, because you may know it.

When it comes to implementing assembly into, say, visual studio (into C++), what's the syntax of it? Let's say I just want to learn how to manipulate memory values that I've defined in C++ using nasm rather than program everything from scratch IN nasm (that seems too overwhelming for me at moment), do I need to still look at x86 intel architecture? Or is there something else I can do? My primary objective is to be able to read and understand syntax. Any suggestions on that? That would also mean that whatever I make can be used cross platform, right? Because if I use nasm, I wouldn't be able to just transfer it to linux (have the code compile on linux) if it's AMD?

Is there assembly for amd processors? What's different?

[Bryant Keller]

When it comes to implementing assembly into, say, visual studio (into C++), what's the syntax of it? Let's say I just want to learn how to manipulate memory values that I've defined in C++ using nasm rather than program everything from scratch IN nasm (that seems too overwhelming for me at moment), do I need to still look at x86 intel architecture? Or is there something else I can do? My primary objective is to be able to read and understand syntax. Any suggestions on that?

I would avoid trying to interface with C++ code from NASM until you become more familiar with NASM itself. The problem isn't NASM or the Intel architecture, rather it's a problem with C++. The C++ programming language produces some seriously ugly output that is very hard for most beginners to understand, let alone make use of. This is a result of a "feature" of C++ known as "Name Mangling" that allows support for function overloading and namespaces among other things. What makes it more difficult is that each implementation of C++ (Visual C++, GNU C++, etc.) all handle this "Name Mangling" feature differently since the language only requires the ability be present, but doesn't impose any requirement on how it should be implemented. 

That would also mean that whatever I make can be used cross platform, right? Because if I use nasm, I wouldn't be able to just transfer it to linux (have the code compile on linux) if it's AMD?

Code which interface with external API's are going to be specific to that API. However, there are plenty of portable API's out there. Good examples of this are the Standard C Library, the OpenGL Library, and the OpenMP Library. Using portable libraries like these will allow you to make use of features of any given system without the need for worrying about the exact implementation details of that particular system. These libraries also, usually, have some form of overhead since they are developed in higher level languages and require the processor to execute through multiple layers of abstraction before reaching what would be a direct invocation from a system dependent application.

If you are focused on portable development, I would suggest using NASMX and stick to examples that use the Standard C Library for peripheral (screen, disk, network, etc) I/O. This should give you the ability to build and run code on any system that NASM & NASMX already support.

Is there assembly for amd processors? What's different?

Intel and AMD are just microprocessor vendors. Both Intel and AMD make 80x86 microprocessors... of course they also both make ARM microprocessors, and various Berkeley RISC microprocessors. NASM is an 80x86 assembler, so it generates code compatible with all 80x86 processors no matter what vendor makes them.

[Evlesoa]

Oh, that's odd. Why would they do that...

I have decided to take C (because of its being a standard) and assembly in school for next semester's classes (I'm majoring in language, though, ha). That should be fun. Thanks for sharing. I will steer clear of anything that is poorly implemented so as to not make my learning experience miserable.