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

[shaynox]

GoLink it's just a tool who is necessary to build any program, you can wrote some code like:

Code: [Select]

vmulss        ymm0, ymm1, ymm2

and build it through nasm, and execute it, but it will not work cause your program haven't header for your OS recognize that like program.

http://en.wikipedia.org/wiki/Portable_Executable

[Evlesoa]

Yeah, I understand what you mean for that. This part doesn't seem too complicated. Thanks

[shaynox]

No problem ^^

And be patient, in fact we learn asm everyday like me, and for begin to this world, you need long long time for understand this langage, personnaly I needed 2 years just for learn how it's work a little :p

Well I had made the biggest error of the year to begin to learn by C language, all is only abstraction for this langage, I hate that ^^

[Evlesoa]

Yes, exactly. It's so abstract to me that I don't know how to learn it! I see you had the same problem. I like abstraction if it can be understood in some way.

[shaynox]

sure ^^

and for the precedent program you given me, where you find it ? nasm give me a lot of error.

Code: [Select]


alloc(health,1024)
label(original) //reference
label(quit)
label(return)

health:
mov [ebx+00000480],#100

original:
//sub [ebx+00000480],eax

quit:
jmp return

"Tutorial-i386.exe"+24FFB:
jmp health
nop

return:
//blank

It's seem that look like disassembly code ...


PS: and so you want to learn assembly intel for Windows 32 or 64 bit ?

[Evlesoa]

It's disassembler, yes. Specifically Cheat Engine's, because that is the reason I got interested in assembly (its syntax looks interesting). It only works for the tutorial of cheat engine. Here's some documentation: http://wiki.cheatengine.org/index.php?title=Cheat_Engine:Auto_Assembler. But as I said, this code crashes for some reason.

As for learning, I'd like to do 32 bit before moving on to 64 bit. I'd learn 16 bit before learning 32 bit, but 16 bit isn't used anywhere. Gotta start from basics, right?

[shaynox]

Hmm no, concretely don't waste your time by begin to learn 32, jmp to x64 directly, my tip :p
Primary, cause when you would want to transform your code in x64 compatibly, you must re-write all data moving type into 64 bit.
Then while you are in x86, you have lesser register than in x64 mode (https://software.intel.com/sites/default/files/m/d/4/1/d/8/Introduction_to_x64_Assembly.pdf)

Exemple:

Code: [Select]

max 32-bit:
eax - ebx - ecx - edx

max 64-bit:
rax - rbx - rcx - rdx - r8 - r9 - r10 -r11 - r12 - r13 - r14 - r15

This program will never execute through nasm, exept those instruction:

Code: [Select]

health:

;sub [ebx+00000480],eax

jmp health
nop


[Evlesoa]

Isn't x64 harder, though? And less useful since most people are still using x86?

[shaynox]

Well like x64 mode existe since 2006 (http://en.wikipedia.org/wiki/X86-64#Intel_64), I don't know why people keep the old x86 mode, then x64 it's not much harder than x86 16 bit, just more complexe.

But help to get a better program, cause more register, able to transfer more data (vectorization AVX, qword instead dword), I just see only advantage compare to 32 bit and 16 bit.

And there is same story about SSE instruction (vectorization programming) , it exist since 1999, and programmer just begin to interest to those technologie actually -_-
I don't have source about that but I have read some topic about that, and look unity, it just begin to compile their program in x64 bit -_- it's crazy of misunderstanding.

So I have my own theory, like hardware is very very advance compare to software, it need of waiting a lot of year (10 year exemple ^^) for begin to make interest about it.



PS: If you want another debugger, go look for http://x64dbg.com , I think he's wonderful debugger (skin influence ? ) but even if it's beta it's still very good.

[Evlesoa]

Wow, thanks for the tool. Looks like Ollydbg.

Why is it taking so long for everyone to make the switch to x64? Or why is the interest only now coming up and not earlier? If it's relatively old tech (9 years ago), then that should mean it should be more widespread by now? Yes?

You sound like you really know what you're talking about and have a lot of experience with it.

[shaynox]

Well, all programmers need to know, new hardware technology are build everyday (thanks to intel engineer of CPU architecture ^^) like program, it's like sci-fi, I don't kidding, software programmer need a long time before use newer technologies.

And I have my own theory of why, cause simply because 95% of programmer code in higher level language, so they don't care about technology, cause they like to be in abstraction world :x.

Like I say, only assembler language can give you a full vision about all technology of any hardware, high level programmer are so dependent about the compiler software that they don't have knowledge about how memory work or .. (sorry I like troll ). And in other way high level language are just created for this, in the name of facility.

But still my theory, you can get other from other programmers.

Hmm, thanks for the compliment, I just know all that, cause I program everyday, but since some times I have bad habits, like I don't have job I program alone and all those entertainment love to disturb me like video games, movie, internet  :p

[Bryant Keller]

Wow, thanks for the tool. Looks like Ollydbg.

Why is it taking so long for everyone to make the switch to x64? Or why is the interest only now coming up and not earlier? If it's relatively old tech (9 years ago), then that should mean it should be more widespread by now? Yes?

You sound like you really know what you're talking about and have a lot of experience with it.

The reason it takes quite a bit of time for people to upgrade is because hardware costs money. Many companies will update their software on a daily or weekly basis, but hardware only gets updated every 10-15 years. Most companies don't have to buy just one computer, they have to buy hundreds. So as long as businesses are still using 32-bit platforms, there will be a need for 32-bit programming. Give it another 5-6 years and you won't find anyone outside of the embedded design market using 32-bit systems.


As for the original topic, and I don't mean to contradict anyone, but the best way to learn assembly isn't to just randomly work with assembly code. That's really just a good way to develop bad habits and can actually slow down your progress.

The best way to learn any type of programming is to learn the fundamentals of software design. 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. To do this, you don't use a programming language, you use flowcharts. When you get into the habit of creating a flowchart that describes a solution, you then break the problem of development into much smaller blocks of code which makes translating those blocks to whatever language you want as easy as checking your reference manual for that particular language/architecture. You should also get into the habit of creating data-flow diagrams. This is a type of flowchart that will describe where information is coming from and where it should go. In your game cheat example earlier, this would be the flowchart which shows the interprocess communication between your cheat and the game, as well as what memory locations in the game need to be modified for the desired results.

This style of program design & development is known as top-down design and has been used quite successfully by programmers since the 70s. It allows you to think of the problem to solve in an abstract manner so that you can use any programming language you wish for the implementation. There are other (arguably better) methodologies such as Object-Oriented design and Event-Driven design, but unless you are working with very high level languages, these can add a great deal of complexity to your code which is beyond the grasp of most beginners.

Here are a few links I hope you'll find useful.

• Information on Flowcharts
• Information on Data-Flow Diagrams

[Evlesoa]

Gotcha.

And for flow charts, I remember this. I remember doing this for C++ in order to create solutions for problems. I actually did reinstall Visual C++ Express just today, which is what I'll be re-learning now. I will try to learn assembly on a very basic level, where I can't do anything with it alone but can try to incorporate it into my C++ programs instead since I'll be working with memory for my beginnings.

Lol @ Shaynox. Thanks for the info, and I know how such distractions get in the way. It's quite true, yes. I have the same problem!

[shaynox]

Hello,

@Bryant Keller: No, no worry you, I just said my own experience and conclusion I have, about it.

And for the question about how to learn programming, but like we are in assembler forum, it will be fine to stay on this level, you talk about c - c++ - OOP :p that's just my opinion.

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

[Evlesoa]

What I mean is that I don't have any idea of how to work with a flow chart and assembly. I mention C++ because I know it (visual studio) allows for integration of assembly. In any case, I need to learn assembly for that use. My problem is that I want to manipulate memory, and my solution is to build something that can alter said memory. But I still got no clue on how to start, so I'll have to work with another language before I can use assembly. Unless someone else has some better ideas...