I want to get user's input from the console and use the IP address for a socket connection instead of hardcoding the IP address.
From my learning on https://azeria-labs.com/tcp-bind-shell-in-assembly-arm-32-bit/, I modified the socket structure (still using a hardcoded address) as such:
struct:
.ascii "\x02\xff"
.ascii "\x11\x5c"
ipv4: .byte 0
ipv4_2: .byte 0
ipv4_3: .byte 0
ipv4_4: .byte 0
I then copy the actual address to the 4 bytes for IP address
adr r1,ipv4
mov r2,#127
strb r2, [r1]
adr r1,ipv4_2
mov r2,#0
strb r2, [r1]
adr r1,ipv4_3
mov r2,#0
strb r2, [r1]
adr r1,ipv4_4
mov r2,#1
strb r2, [r1]
The connection will complete successfully. However, if I want to get an IP address input from user, such as 255.255.255.255, each single digit actually takes up one byte individually, so 255 is treated as 0x2 0x5 0x5, instead of 0xff which is the intended interpretation (one byte). The code to read input:
mov r7,#3
mov r0,#0
adr r1,userinput
mov r2,#20
svc #1
How do I "combine" the three digits into one and then store it in a single byte?
If that is not the way, what is the correct way to do it? Is it possible to do it without the use of external libc functions?
Related
Would someone be able to clarify whether when you type a command at the Windbg command prompt are the 64 bit addresses displayed in the very first column virtual or are they actually physical addresses ?
lkd> uf nt!KiInitSpinLocks
nt!KiInitSpinLocks:
fffff802`127eb05c 48895c2408 mov qword ptr [rsp+8],rbx
fffff802`127eb061 48896c2410 mov qword ptr [rsp+10h],rbp
fffff802`127eb066 4889742418 mov qword ptr [rsp+18h],rsi
fffff802`127eb06b 57 push rdi
fffff802`127eb06c 4883ec20 sub rsp,20h
fffff802`127eb070 33ed xor ebp,ebp
fffff802`127eb072 488bd9 mov rbx,rcx
fffff802`127eb075 c781a058000001000000 mov dword ptr [rcx+58A0h],1
fffff802`127eb07f 448d4520 lea r8d,[rbp+20h]
fffff802`127eb083 488d8100590000 lea rax,[rcx+5900h]
fffff802`127eb08a 89a998580000 mov dword ptr [rcx+5898h],ebp
fffff802`127eb090 4889a9882c0000 mov qword ptr [rcx+2C88h],rbp
fffff802`127eb097 8bf2 mov esi,edx
fffff802`127eb099 418bc8 mov ecx,r8d
Assuming you're on a physical machine (not a VM) and assuming that the physical memory is handled in a contiguous way (it needn't be in VMs), 0xfffff802127eb05c is at 18446735286 GB in your RAM.
But yeah, the documentation leaves it open. Just if you know that there is up to disassemble physical memory, you'll find the statement
The up command disassembles only physical memory, while the u command disassembles only virtual memory.
.
I have a school project, recoding a strace-like command on a x86_64 OpenSUSE. (Intell i7)
For this purpose we are, of course, using ptrace system call but it is forbiden to use PTRACE_SYSCALL. We have to use PTRACE_SINGLESTEP and detect systems calls thanks to PTRACE_PEEKTEXT and opcodes corresponding to system calls instructions (0x80CD for int0x80, 0x050F for syscall and 0x340F for sysenter).
Until there, I'm good. But then we have to fetch the parameters of the system call. For syscall and intx80 it's kind of easy, I look into rax to know which system call it is, then I look into rdi, rsi, rdx, etc.
But for sysenter I cannot find how it's really working. So I tried to code a little assembly program to test those 3 instructions.
BITS 64
global main
section .text
main:
push rbp
mov rbp, rsp
mov rdi, 1
mov rsi, FormatStr
mov rdx, 30
mov rax, 1
syscall
leave
ret
section .rodata
FormatStr db 'Hello World ! Sysenter Test !',0Ah,0
Which works perfectly fine !
Now for the int 0x80 version I just change the number of the system call in rax from 1 to 4. (In 32, dunno why but the system calls numbers aren't the same)
BITS 64
global main
section .text
main:
push rbp
mov rbp, rsp
mov rdi, 1
mov rsi, FormatStr
mov rdx, 30
mov rax, 4
int 0x80
leave
ret
section .rodata
FormatStr db 'Hello World ! Sysenter Test !',0Ah,0
Which works at 50%. A string is displayed but it's garbage.
Now if I put a sysenter I get a SIGILL signal. I tried with 1 and 4 in rax.
My project just has to run on my computer but I have to be able to detect and analyse binaries who are using sysenter
Can someone give a little explication on those things ?
Thank you !
Ps : sorry for my bad english
I've recently been researching Operating Systems, the boot process, and NASM. On my journeys I ran into a piece of useful bootstrapping code which I partially understand and have tested via a virtual floppy disk. My basic question is to what some of these lines I don't understand do. I've commented what I think the lines do, and any corrections or confirmations would be much appreciated.
; This is NASM
BITS 16 ; 16 bits!
start: ; Entry point
mov ax, 07C0h ; Move the starting address (after this bootloader) into 'ax'
add ax, 288 ; Leave 288 bytes before the stack beginning for some reason
mov ss, ax ; Show 'stack segment' where our stack starts
mov sp, 4096 ; Tell 'stack pointer' that our stack is 4K in size
mov ax, 07C0h ; Use 'ax' as temporary variable for setting 'ds'
mov ds, ax ; Set data segment to where we're loaded
mov si, text_string ; Put string position into SI (the reg used for this!)
call print_string ; Call our string-printing routine
jmp $ ; Jump here - infinite loop!
text_string db 'This is my cool new OS!', 0 ; Our null terminated string
; For some reason declared after use
print_string: ; Routine: output string in SI to screen
mov ah, 0Eh ; I don't know what this does..
; Continue on to 'repeat'
.repeat:
lodsb ; Get character from DS:SI into AL
cmp al, 0 ; If end of text_string
je .done ; We're done here
int 10h ; Otherwise, print the character (What 10h means)
jmp .repeat ; And repeat
.done:
ret
times 510-($-$$) db 0 ; Pad remainder of boot sector with 0s
dw 0xAA55 ; The standard PC 'magic word' boot signature
Thanks,
Joe
Your comments are largely correct.
mov ah,0Eh
This sets a parameter to the BIOS interrupt call:
int 10h
See here for more details, but essentially the call to 10h expects an operation in ah and data for the operation in al.
The segment registers cannot be loaded directly and can only load from a register, thus the use of ax as a 'temporary variable.'
The 288 bytes added to the base stack pointer are actually not bytes at all. Addresses loaded into the segment registers are actually pointers to 16-byte blocks, so to convert the number to its actual address, shift it left by 4-bits. That means that the address 07C0h is actually referring to 7C00h, which is where your bootloader code is placed. 288 is 120h in hex, and so the actual location of the stack is really 7C00h + 1200h = 8E00h.
Also, you use words like "show" and "tell" which are fine, but it's better to think of defining the stack by setting ss and sp as opposed to reporting where it is at... I hope that makes sense.
mov ah, 0Eh ; I don't know what this does..
Loading 0eh into ah sets up the int 10h function Teletype output, which will print the character in al to the screen.
Your .repeat loop will then load each character from text_string into al and call int 10h.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
So I took up assembly programming. It's quite simple on my Ubuntu box: using NASMamd GNU ld, I were able to write more or less complicated HelloWorld-style programs in half an hour.
But when it comes to the iPhone, it's so complicated. First of all, I have a JB'en iPhone 3G on 4.2.1 firmware, which means that I use the ARM port of the Darwin kernel v10.
Second. I have to use GNU as, as there's no NASM for iPhone: the native toolchain (both Xcode on Mac OS X and the opensource tooolchain on linux) use GCC.
So I have gathered together basic info about:
- how to write assembly in GNU as language;
- what are the basic ARM instructions, registers, memory access.
But even HelloWorld requires kernel calls for writing to stdout. My question is: what kernel call to use and how (what arguments go where); I should use the swi # ARM instruction, shouldn't I?
So, can you please post some info/links to tutorials, or somebody with an ARM Darwin Hello world asm code?
As of now, I could do this:
;Hello World for Linux and NASM
section data
hello db "Hello World"
helloLen equ $ - hello
section text
global _start
_start:
mov eax, 4 ; sys_write
mov ebx, 1 ; to stdout
mov ecx, hello ; address of string
mov edx, helloLen ; value (because of eq!!!) of strLen
int 0x80 ; call awesome Linux kernel
mov eax, 1 ; sys_exit
mov ebx, 0 ; "return 0; " if you like C
int 0x80 ; call kernel to end program
on ARM, however, I could only do like this:
.text
start:
mov r0, #0
mov r1, #234
add r2, r0, r1
#all mov and add and other stuff works fine
swi #0xc00
#all that I get is Bad system call error
So, anybody please?
Here's how libc (libSystem) does it:
; ssize_t read(int, void *, size_t)
EXPORT _read
_read
MOV R12, #3 ; SYS_read
SVC 0x80 ; 'А' ; do a syscall
BCC _ok ; carry clear = no error
LDR R12, =(cerror_ptr - . - 8) ; otherwise call error handler
LDR R12, [PC,R12] ; load pointer
B _call_error
DCD cerror_ptr - .
_call_error
BX R12 ; cerror ; jump to it (error number is in R0)
_ok
BX LR ; return to caller
; End of function _read
I.e.:
System call number is in R12 (see sys/syscall.h).
System call instruction is SVC 0x80 (SWI 0x80).
Other parameters are according to the ABI (R0-R3, then stack).
On error, carry flag is set and error number is returned in R0.
Best I can find right quick and yea I realize the initial post is old
http://blog.softboysxp.com/post/7888230192/a-minimal-168-byte-mach-o-arm-executable-for-ios
.text
.globl start
start:
mov r2, #14
adr r1, hello_str
mov r0, #1
mov r12, #4
swi 0x80
mov r0, #0
mov r12, #1
swi 0x80
hello_str:
.ascii "Hello, World!\n"
compile:
as new.asm -o new.o
ld new.o -o new
./new
I have written simple first stage bootloader which displays "Hello world" using interrupt to bios. Now as a next obvious step to write a second stage, but where code for that should exist and how to load it from first stage ?
Here is a program for first stage
[BITS 16] ;Tells the assembler that its a 16 bit code
[ORG 0x7C00] ;Origin, tell the assembler that where the code will
;be in memory after it is been loaded
MOV SI, HelloString ;Store string pointer to SI
CALL PrintString ;Call print string procedure
JMP $ ;Infinite loop, hang it here.
PrintCharacter: ;Procedure to print character on screen
;Assume that ASCII value is in register AL
MOV AH, 0x0E ;Tell BIOS that we need to print one charater on screen.
MOV BH, 0x00 ;Page no.
MOV BL, 0x07 ;Text attribute 0x07 is lightgrey font on black background
INT 0x10 ;Call video interrupt
RET ;Return to calling procedure
PrintString: ;Procedure to print string on screen
;Assume that string starting pointer is in register SI
next_character: ;Lable to fetch next character from string
MOV AL, [SI] ;Get a byte from string and store in AL register
INC SI ;Increment SI pointer
OR AL, AL ;Check if value in AL is zero (end of string)
JZ exit_function ;If end then return
CALL PrintCharacter ;Else print the character which is in AL register
JMP next_character ;Fetch next character from string
exit_function: ;End label
RET ;Return from procedure
;Data
HelloString db 'Hello World', 0 ;HelloWorld string ending with 0
TIMES 510 - ($ - $$) db 0 ;Fill the rest of sector with 0
DW 0xAA55 ;Add boot signature at the end of bootloader
On x86 you would do the following (simplified):
Have the bootloader load the n-th sector of the disk/floppy (wherever you're booting from) into memory and execute it (i.e. load segment/offset and do retf). A better alternative is to search the filesystem for a certain filename (e.g. KERNEL.BIN) -- but you'd need to know the file system type (e.g. FAT12 if you're testing from a floppy image).
The kernel would then start in real mode. It sets up code descriptors, GDT, and so on, activates 32-bit addressing (you should have heard of "A20") and finally enters protected mode. Then you need a far jump to a 32-bit code segment (kernel file must be linked together in a way that the 32-bit code is at an absolute position, e.g. at offset 512, right after the 16-bit real mode stuff).
The 32-bit kernel assembly, then, just defines EXTERN _mykernel (for example) and calls that symbol.
Then you can begin writing your kernel as C function mykernel.
Okay that was a short overview of what I did a few years ago (with lots of copy&paste from the Internet ;). If that isn't helpful, here are some good web resources on OS development:
http://www.brokenthorn.com/Resources/OSDevIndex.html
http://wiki.osdev.org/Main_Page
http://lowlevel.brainsware.org/wiki/index.php/Hauptseite (wiki with many hobbyist OS developers, German only...)
Hope that helps ^^
Look at the GRUB implementation here (stage 1):
http://src.illumos.org/source/xref/illumos-gate/usr/src/grub/grub-0.97/stage1/stage1.S
First noticed the starting point at 0x7c00 and the end signature of 0xaa55 for this first sector. From within the disassembly, u can see this:
349 copy_buffer:
350 movw ABS(stage2_segment), %es
351
352 /*
353 * We need to save %cx and %si because the startup code in
354 * stage2 uses them without initializing them.
355 */
356 pusha
357 pushw %ds
358
359 movw $0x100, %cx
360 movw %bx, %ds
361 xorw %si, %si
362 xorw %di, %di
363
364 cld
365
366 rep
367 movsw
368
369 popw %ds
370 popa
371
372 /* boot stage2 */
373 jmp *(stage2_address)
374
375 /* END OF MAIN LOOP */
376
Essentially the logic is to copy the stage 2 code into another part of memory, and after that jump directly there, and that is "boot stage2". In other words, "boot stage1" is effectively triggered from BIOS after it has loaded the sector into memory, whereas stage2 is where you jump there - it can be anywhere.
Minimal runnable NASM BIOS example that loads stage 2 and jumps to it
use16
org 0x7C00
; You should do further initializations here
; like setup the stack and segment registers.
; Load stage 2 to memory.
mov ah, 0x02
; Number of sectors to read.
mov al, 1
; This may not be necessary as many BIOS set it up as an initial state.
mov dl, 0x80
; Cylinder number.
mov ch, 0
; Head number.
mov dh, 0
; Starting sector number. 2 because 1 was already loaded.
mov cl, 2
; Where to load to.
mov bx, stage2
int 0x13
jmp stage2
; Magic bytes.
times ((0x200 - 2) - ($ - $$)) db 0x00
dw 0xAA55
stage2:
; Print 'a'.
mov ax, 0x0E61
int 0x10
cli
hlt
; Pad image to multiple of 512 bytes.
times ((0x400) - ($ - $$)) db 0x00
Compile and run:
nasm -f bin -o main.img main.asm
qemu-system-i386 main.img
Expected outcome: a gets printed to the screen, and then the program halts.
Tested on Ubuntu 14.04.
Saner GAS example using a linker script and more correct initialization (segment registers, stack) on my GitHub.