/g/ - Technology

install openbsd

[Make a Post]
[X]





Assembly なのにもうす No.9234 [D][U][F][S][L][A][C] >>9235
File: 343c2820e636d7bd523ab70a31b1b4d7de41119fb883972215cebb70d510bcb0.png (dl) (536.20 KiB)
I was randomly watching some of Terry's videos the other day, i think it was a video about TempleOS kernel or compiler, anyway i couldn't understand much cause i don't know assembly :(
I'd like to fix this deficiency of mine, where do i start?

Nanonymous No.9235 [D] >>9238 >>9240
>>9234
https://nanochanqwrwtmamtnhkfwbbcducc4i62ciss4byo6f3an5qdkhjngid.onion/Media/9a32bfcd3cd2f25d0d9bacf57b3cdf3d21e52d5b42622dd3a26b09e5848ceab2.pdf

Nanonymous No.9236 [D][U][F] >>9238 >>9240
File: 050015a23f70c763a8dc4a0b9effe1adf563f865e271c13be7ac0225604e576e.pdf (dl) (2.19 MiB)
Why do you want to know assembly? For debugging, reverse engineering, embedded develompent, etc?

Nanonymous No.9238 [D] >>9240
>>9235
>>9236
>pdf
Dont click on it anon

なのにもうす No.9240 [D][U][F] >>9241
File: 641b899c5c4c0c25d41732cf510c54bbf099af3586d4143c46fe19fa072a0953.gif (dl) (1.09 MiB)
>>9235
Seems like a good book to start with, i'll read it thanks fren.

>>9236
PDF seems really focused on developing on Windows which is not really my first choice for these kind of things, i'll still give it a look after the other one.
>Why do you want to know assembly?
Well knowing how to do reverse engineering would be cool, but my real reason is just educational, i want to be able to read assembly and undestand programs written in assembly, also i want to get a better undestanding at the low level computing, i think that i got too much used at using high level programming languages and don't really know what i am doing.

>>9238
>pdf
>Dont click on it anon
Too late!!!
I think i am getting hackswsda#*#(sidha29380isjdi&*(@#*$jksjdk

Nanonymous No.9241 [D] >>9249
>>9240
>i want to be able to read assembly and undestand programs written in assembly
One trouble is that there are many instructions in x86, and just knowing enough to write programs won't get you very far in reading them. I took an introductory course on assembly (and shell and make... it was a grab bag), but can't really read the output of a c compiler any better than before. A very helpful resource for this is godbolt. You can see which lines of c match up with which lines of assembly, so you can tell what they do. I've used this to understand complex optimizations of my code before.

Nanonymous No.9243 [D] >>9247
Try learning an easier asembly first. Like baste z80 or virgin 6501. I think it'll help when you learn more complex assembly like x86.

Nanonymous No.9245 [D]
Don't overstate the complexity of writing completely functional (albeit, not necessarily optimized) x86 assembly language. While messy, it can be learned by any beginner willing to dip into the deep end of the proverbial swimming pool.

You can certainly get by with free resources and used, out of print books. But if I were to learn assembly language again, I'd sign up for this course after setting up a virtual machine to sandbox in: https://www.xorpd.net/pages/x86_adventures.html

Nanonymous No.9246 [D]
I did learn asm many years ago, and have found it to be not very useful. I've written a few programs for smartcards in their assemply languaga, and I've optimized a few C functions, and that's basically it. The usefulness of writing asm code is very limited.

If OP wants to learn ASM just for educational purposes, I'd suggest to first get a good grasp of C, and then learn to write inline-asm to optimize some C code. I don't have any books for that, though, since I haven't been using both languages for at least a decade.

Nanonymous No.9247 [D]
>>9243
z80 is i386-compatible too

Nanonymous No.9249 [D] >>9254
>>9241
Programming from the Ground Up is a good book for learning to write x86 assembly on Linux is that's your preferred platform.
http://gen.lib.rus.ec/search.php?req=programming+from+the+ground+up

After that try some crackmes or binary CTFs. When you start off you'll need to lookup every instruction in the Intel manual to understand what it does but after a while you'll know all the common ones and it will get much easier.

Nanonymous No.9254 [D][U][F]
File: 896bbb27c5eccca23c51a64fcd6da4b3110181a99851e930c1f22a27c039a50a.jpg (dl) (70.46 KiB)
>>9249
> Programming from the Ground Up
It's good, but it's too old: x86-64 have many new things not mentioned here. I have read half of it, and it's not even says how to output numbers (they are must be converted into ASCII values first).
Anyway, juggling bytes is pretty fun.

I'd wish to participate, but my English sucks. If you can bear with my grammatix, I'll post some notes taken while learning it a little bit later… Okay, Nanonimousu-san?

Nanonymous No.9261 [D] >>9274
>and it's not even says how to output numbers
I assume you mean printing to them to the screen? This is really advanced to do since you will need to write a driver to handle talking to whatever in your system handles output (such as vga). It is much easier if you have something that abstracts over it though like a BIOS or a kernel.

Nanonymous No.9266 [D]
avatar nigger thread
do not reply

Nanonymous No.9274 [D][U][F] >>9286
File: e30a48a03701ce47384b0b27c459dc43ace999ebaabef25ebba74c499f380148.txt (dl) (381 B)
>>9261
It's not that hardcore, 'cause it's an introductory book: all of the examples are written using linux-32 syscalls (and AT&T syntax, which is pretty inconvenient).

Here is a better way to do it using the same assembler, GAS.

Good news is that you don't need to install anything if you compiled or make'd any programs on that machine - utilities you are going to need are already there, provided by a "binutils" package.
They are:
as - GAS, GNU Assembler
ld - linker

$ as file.txt -o file.o && ld -N file.o -o file
"-N" means "Don't link the C library and standard routines". C functions like "printf" cannot be called from this binary, but there's no such calls, so it's not needed. Resulting binary will be much smaller.
By the way, assembly source files for GAS must have a ".s" extension.

syscall Nanonymous No.9275 [D]
$ man -k . -s 2
or
$ apropos -s 2 .
Manuals. Alot of them.

Tables with syscalls names and numbers are in kernel source tree.
arch/x86/syscalls/syscall_64.tbl
arch/x86/syscalls/syscall_32.tbl
https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl
https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_32.tbl

Basically, what one could do to find some needed syscall:
$ egrep '\<write\>' syscall_64.tbl
1 common write __x64_sys_write

So "write" number is 1. It's present in 32 and 64 bit kernels (common), but it's number is specific to x64 kernel, for 32 bit kernel it will be different.
To learn about it's arguments, enter:
$ man 2 write
ssize_t write(int fd, const void *buf, size_t count);

It's a function signature for C, bit it can be easily converted into assembly language.
In order to call it, three arguments must be passed: file descriptor to write to, beginning address of a string to write, and how many bytes you want to be written.

Registers layout for x64 syscall is:
RAX - syscall number
RDI, RSI, RDX, R10, R8, R9 - arguments.
RAX - return value, positive or negative in the case of error.

To call that "write" you need to put:
RAX = 1
RDI = file descriptor
RSI = buffer address (string pointer)
RDX = size of that buffer
and execute "syscall" instruction. After that return value, which is count of bytes written, will be in RAX.

Same goes for the "exit":
void _exit(int status);
It needs one argument, which must be in RDI register.
Here I put return value from write into RDI before exiting just for demonstration purposes. You can check it with
$ echo $?
It will be a number of bytes written. 17 in this case.

Nanonymous No.9286 [D]
>>9274
As I said at the end of my post. If you are running on top of a kernel it is much easier since the kernel will do all the hard work for you.

Nanonymous No.9333 [D]
>It's good, but it's too old: x86-64 have many new things not mentioned here.
and they're all crap and AIDS, just get an "old" PC