I have devised a hypothetical instruction set that I believe is Turing-complete. I cannot think of any computational operation that this instruction set is not able to complete. I would just like to verify that this hypothetical instruction set is indeed Turing-complete.
Registers
IP = Instruction Pointer
FL = Flags
Memory
Von Neumann
Other Info
Instructions have two forms (The conditional/immediate jumps being the outliers):
Acting on memory using a scalar
Acting on memory using other memory
All instructions act on unsigned integers of a fixed size
Each instruction consists of a one-byte opcode with three trailing one-byte arguments (not all arguments must be used).
Assume a byte is able to hold any memory address
Instructions
Moving = MOV
Basic Arithmetic = ADD, SUB, MUL, DIV, REM
Binary Logic = AND, NOT, OR, NOR, XOR, XNOR, NAND, SHR, SHL
Comparison = CMP (this instruction sets the flags (excluding the unsigned integer overflow flag) by comparing two values)
Conditional Jumps = JMP, various conditional jumps based on the flags
Flags
"Unsigned Integer Overflow"
">"
"<"
">="
"<="
"=/="
"="
I am in trouble with the definition 'memory location'. According to the 'Intel 64 and IA-32 Software Developer's Manual' many instruction can use a memory location as operand.
For example MOVBE (move data after swapping bytes):
Instruction: MOVBE m32, r32
The question is now how a memory location is defined;
I tried to use variables defined in the .bss section:
section .bss
memory: resb 4 ;reserve 4 byte
memorylen: equ $-memory
section .text
global _start
_start:
MOV R9D, 0x6162630A
MOV [memory], R9D
SHR [memory], 1
MOVBE [memory], R9D
EDIT:->
MOV EAX, 0x01
MOV EBX, 0x00
int 0x80
<-EDIT
If SHR is commented out yasm (yasm -f elf64 .asm) compiles without problems but when executing stdio shows: Illegal Instruction
And if MOVBE is commented out the following error occurs when compiling: error: invalid size for operand 1
How do I have to allocate memory for using the 'm' option shown by the instruction set reference?
[CPU=x64, Compiler=yasm]
If that is all your code, you are falling off at the end into uninitialized region, so you will get a fault. That has nothing to do with allocating memory, which you did right. You need to add code to terminate your program using an exit system call, or at least put an endless loop so you avoid the fault (kill your program using ctrl+c or equivalent).
Update: While the above is true, the illegal instruction here is more likely caused by the fact that your cpu simply does not support the MOVBE instruction, because not all do. If you look in the reference, you can see it says #UD If CPUID.01H:ECX.MOVBE[bit 22] = 0. That is trying to tell you that a particular flag bit in the ECX register returned by the 01 leaf of the CPUID instruction shows support of this instruction. If you are on linux, you can conveniently check in /proc/cpuinfo whether you have the movbe flag or not.
As for the invalid operand size: you should generally specify the operand size when it can not be deduced from the instruction. That said, SHR accepts all sizes (byte, word, dword, qword) so you should really not get that error at all, but you might get an operation of unexpected default size. You should use SHR dword [memory], 1 in this case, and that also makes yasm happy.
Oh, and +1 for reading the intel manual ;)
Goal:
I need to write a program that tests the write functionality of an entire 1MB of memory on a byte by byte basis for a system using an Intel 80186 microprocessor. In other words, I need to write a 0 to every byte in memory and then check if a 0 was actually written. I need to then repeat the process using a value of 1. Finally, any memory locations that did not successfully have a 0 or 1 written to them during their respective write operation needs to be stored on the stack.
Discussion:
I am an Electrical Engineering student in college (Not Computer Science) and am relatively new to x86 assembly language and MASM611. I am not looking for a complete solution. However, I am going to need some guidance.
Earlier in the semester, I wrote a program that filled a portion of memory with 0's. I believe that this will be a good starting point for my current project.
Source Code For Early Program:
;****************************************************************************
;Program Name: Zeros
;File Name: PROJ01.ASM
;DATE: 09/16/14
;FUNCTION: FILL A MEMORY SEGMENT WITH ZEROS
;HISTORY:
;AUTHOR(S):
;****************************************************************************
NAME ZEROS
MYDATA SEGMENT
MYDATA ENDS
MYSTACK SEGMENT STACK
DB 0FFH DUP(?)
End_Of_Stack LABEL BYTE
MYSTACK ENDS
ASSUME SS:MYSTACK, DS:MYDATA, CS:MYCODE
MYCODE SEGMENT
START: MOV AX, MYSTACK
MOV SS, AX
MOV SP, OFFSET End_Of_Stack
MOV AX, MYDATA
MOV DS, AX
MOV AX, 0FFFFh ;Moves a Hex value of 65535 into AX
MOV BX, 0000h ;Moves a Hex value of 0 into BX
CALL Zero_fill ;Calls procedure Zero_fill
MOV AX, 4C00H ;Performs a clean exit
INT 21H
Zero_fill PROC NEAR ;Declares procedure Zero_fill with near directive
MOV DX, 0000h ;Moves 0H into DX
MOV CX, 0000h ;Moves 0H into CX. This will act as a counter.
Start_Repeat: INC CX ;Increments CX by 1
MOV [BX], DX ;Moves the contents of DX to the memory address of BX
INC BX ;Increments BX by 1
CMP CX, 10000h ;Compares the value of CX with 10000H. If equal, Z-flag set to one.
JNE Start_Repeat ;Jumps to Start_Repeat if CX does not equal 10000H.
RET ;Removes 16-bit value from stack and puts it in IP
Zero_fill ENDP ;Ends procedure Zero_fill
MYCODE ENDS
END START
Requirements:
1. Employ explicit segment structure.
2. Use the ES:DI register pair to address the test memory area.
3. Non destructive access: Before testing each memory location, I need to store the original contents of the byte. Which needs to be restored after testing is complete.
4. I need to store the addresses of any memory locations that fail the test on the stack.
5. I need to determine the highest RAM location.
Plan:
1. In a loop: Write 0000H to memory location, Check value at that mem location, PUSH values of ES and DI to the stack if check fails.
2. In a loop: Write FFFFH to memory location, Check value at that mem location, PUSH values of ES and DI to the stack if check fails.
Source Code Implementing Preliminary Plan:
;****************************************************************************
;Program Name: Memory Test
;File Name: M_TEST.ASM
;DATE: 10/7/14
;FUNCTION: Test operational status of each byte of memory between a starting
; location and an ending location
;HISTORY: Template code from Assembly Project 1
;AUTHOR(S):
;****************************************************************************
NAME M_TEST
MYDATA SEGMENT
MYDATA ENDS
MYSTACK SEGMENT STACK
DB 0FFH DUP(?)
End_Of_Stack LABEL BYTE
MYSTACK ENDS
ESTACK SEGMENT COMMON
ESTACK ENDS
ASSUME SS:MYSTACK, DS:MYDATA, CS:MYCODE, ES:ESTACK
MYCODE SEGMENT
START: MOV AX, MYSTACK
MOV SS, AX
MOV SP, OFFSET End_Of_Stack
MOV AX, MYDATA
MOV DS, AX
MOV AX, FFFFH ;Moves a Hex value of 65535 into AX
MOV BX, 0000H ;Moves a Hex value of 0 into BX
CALL M_TEST ;Calls procedure M_TEST
MOV AX, 4C00H ;Performs a clean exit
INT 21H
M_TEST PROC NEAR ;Declares procedure M_TEST with near directive
MOV DX, 0000H ;Fill DX with 0's
MOV AX, FFFFH ;Fill AX with 1's
MOV CX, 0000H ;Moves 0H into CX. This will act as a counter.
Start_Repeat: MOV [BX], DX ;Moves the contents of DX to the memory address of BX
CMP [BX], 0000H ;Compare value at memory location [BX] with 0H. If equal, Z-flag set to one.
JNE SAVE ;IF Z-Flag NOT EQUAL TO 0, Jump TO SAVE
MOV [BX], AX ;Moves the contents of AX to the memory address of BX
CMP [BX], FFFFH ;Compare value at memory location [BX] with FFFFH. If equal, Z-flag set to one.
JNE SAVE ;IF Z-Flag NOT EQUAL TO 0, Jump TO SAVE
INC CX ;Increments CX by 1
INC BX ;Increments BX by 1
CMP CX, 10000H ;Compares the value of CX with 10000H. If equal, Z-flag set to one.
JNE Start_Repeat ;Jumps to Start_Repeat if CX does not equal 10000H.
SAVE: PUSH ES
PUSH DI
RET ;Removes 16-bit value from stack and puts it in IP
M_TEST ENDP ;Ends procedure Zero_fill
MYCODE ENDS
END START
My commenting might not be accurate.
Questions:
1. How do I use ES:DI to address the test memory area?
2. What is the best way to hold on to the initial memory value so that I can replace it when I'm done testing a specific memory location? I believe registers AX - DX are already in use.
Also, if I have updated code and questions, should I post it on this same thread, or should I create a new post with a link to this one?
Any other advice would be greatly appreciated.
Thanks in advance.
How do I use ES:DI to address the test memory area?
E.g. mov al, es:[di]
What is the best way to hold on to the initial memory value so that I can replace it when I'm done testing a specific memory location? I believe registers AX - DX are already in use.
Right. You could use al to store the original value and have 0 and 1 pre-loaded in bl and cl and then do something like this (off the top of my head):
mov al, es:[di] // load/save original value
mov es:[di], bl // store zero
cmp bl, es:[di] // check that it sticks
jne #pushbad // jump if it didn't
mov es:[di], cl // same for 'one'
cmp cl, es:[di]
jne #pushbad
mov es:[di], al // restore original value
jmp #nextAddr
#pushbad:
mov es:[di], al // restore original value (may be redundant as the mem is bad)
push es
push di
#nextAddr:
...
Some words about for to test also the memory location that our own routine is claimed. We can copy and run our routine into the framebuffer of the display device.
..
Note: If we want to store or compare a memory location with an immediate value, then we have to specify how many bytes we want to access. (But in opposite of it with using a register as a source, or a target, the assembler already knows the size of it, so we do not need to specify.)
Accessing one byte of one address (with an immediate value):
CMP BYTE[BX], 0 ; with NASM (Netwide Assembler)
MOV BYTE[BX], 0
CMP BYTE PTR[BX], 0 ; with MASM (Microsoft Macro Assembler)
MOV BYTE PTR[BX], 0
Accessing two bytes of two adresses together
(executing faster, if the target address is even aligned):
CMP WORD[BX], 0 ; with NASM
MOV WORD[BX], 0
CMP WORD PTR[BX], 0 ; with MASM
MOV WORD PTR[BX], 0
If you start with the assumption that any location in RAM might be faulty; then this means you can't use RAM to store your code or your data. This includes temporary usage - for example, you can't temporarily store your code in RAM and then copy it to display memory, because you risk copying corrupted code from RAM to display memory.
With this in mind; the only case where this makes sense is code in ROM testing the RAM - e.g. during the firmware's POST (Power On Self Test). Furthermore; this means that you can't use the stack at all - not for keeping track of faulty areas, or even for calling functions/routines.
Note that you might assume that you can test a small area (e.g. find the first 1 KiB that isn't faulty) and then use that RAM for storing results, etc. This would be a false assumption.
For RAM faults there are many causes. The first set of causes is "open connection" and "shorted connection" on either the address bus or the data bus. For a simple example, if address line 12 happens to be open circuit, the end result will be that the first 4 KiB always has identical contents to the second 4 KiB of RAM. You can test the first 4 KiB of RAM as much as you like and decide it's "good", but then when you test the second 4 KiB of RAM you trash the contents of the first 4 KiB of RAM.
There is a "smart sequence" of tests. Specifically, test the address lines from highest to lowest (e.g. write different values to 0x000000 and 0x800000 and check that they're both correct; then do the same for 0x000000 and 0x400000, then 0x000000 and 0x200000, and so on until you get to addresses 0x000000 and 0x000001). However, the way RAM chips are connected to the CPU is not necessarily as simple as a direct mapping. For example, maybe the highest bit of the address selects which bank of RAM; and in that case you'd have to test both 0x000000 and 0x400000 and also 0x800000 and 0xC00000 to test both banks.
Once you're sure the address lines work; then you can do similar for data lines and the RAM itself. The most common test is called a "walking ones" test; where you store 0x01, then 0x02, and so on (up to 0x80). This detects things like "sticky bits" (e.g. where a bit's state happens to be "stuck" to its neighbour's state). If you only write (e.g.) 0x00 and test it then write 0xFF and test it, then you will miss most RAM faults.
Also; be very careful with "open connection". On some machines bus capacitance can play tricks on you, where you write a value and the bus capacitance "stores" the previous value, so that when you read it back it looks like it's correct even when there's no connection. To avoid this risk, you need to write a different value in between - e.g. write 0x55 to the address you're testing, then write 0xAA somewhere else, then read the original value back (and hope you get 0x55 because the RAM works, and not 0xAA). With this in mind (for performance) you may consider doing "walking ones" in one area of RAM while also doing "walking zeros" in the next area of RAM; so that you're always alternating between reading a value from one area and reading the inverted value from the other.
Finally, some RAM problems depend on noise, temperature, etc. In these cases you can do extremely thorough RAM tests, say that it's all perfect, then suffer from RAM corruption 2 minutes afterwards. This is why (e.g.) the typical advice is to run something like "memtest" for 8 hours or so if you really want to test RAM properly.
i've got a question regarding the exploit_notesearch program.
This program is only used to create a command string we finally call with the system() function to exploit the notesearch program that contains a buffer overflow vulnerability.
The commandstr looks like this:
./notesearch Nop-block|shellcode|repeated ret(will jump in nop block).
Now the actual question:
The ret-adress is calculated in the exploit_notesearch program by the line:
ret = (unsigned int) &i-offset;
So why can we use the address of the i-variable that is quite at the bottom of the main-stackframe of the exploit_notesearch program to calculate the ret address that will be saved in an overflowing buffer in the notesearch program itself ,so in an completely different stackframe, and has to contain an address in the nop block(which is in the same buffer).
that will be saved in an overflowing buffer in the notesearch program itself ,so in an completely different stackframe
As long as the system uses virtual memory, another process will be created by system() for the vulnerable program, and assuming that there is no stack randomization,
both processes will have almost identical values of esp (as well as offset) when their main() functions will start, given that the exploit was compiled on the attacked machine (i.e. with vulnerable notesearch).
The address of variable i was chosen just to give an idea about where the frame base is. We could use this instead:
unsigned long sp(void) // This is just a little function
{ __asm__("movl %esp, %eax");} // used to return the stack pointer
int main(){
esp = sp();
ret = esp - offset;
//the rest part of main()
}
Because the variable i will be located on relatively constant distance from esp, we can use &i instead of esp, it doesn't matter much.
It would be much more difficult to get an approximate value for ret if the system did not use virtual memory.
the stack is allocated in a way as first in last out approach. The location of i variable is somewhere on the top and lets assume that it is 0x200, and the return address is located in a lower address 0x180 so in order to determine the where about to put the return address and yet to leave some space for the shellcode, the attacker must get the difference, which is: 0x200 - 0x180 = 0x80 (128), so he will break that down as follows, ++, the return address is 4 bytes so, we have only 48 bytes we left before reaching the segmentation. that is how it is calculated and the location i give approximate reference point.
When a value is copied from one register to another, what happens to the value
in the source register? What happens to the value in the destination register.
I'll show how it works in simple processors, like DLX or RISC, which are used to study CPU-architecture.
When (AT&T syntax, or copy $R1 to $R2)
mov $R1, $R2
or even (for RISC-styled architecture)
add $R1, 0, $R2
instruction works, CPU will read source operands: R1 from register file and zero from... may be immediate operand or zero-generator; pass both inputs into Arithmetic Logic Unit (ALU). ALU will do an operation which will just pass first source operand to destination (because A+0 = A) and after ALU, destination will be written back to register file (but to R2 slot).
So, Data in source register is only readed and not changed in this operation; data in destination register will be overwritten with copy of source register data. (old state of destination register will be lost with generating of heat.)
At physical level, any register in register file is set of SRAM cells, each of them is the two inverters (bi-stable flip-flop, based on M1,M2,M3,M4) and additional gates for writing and reading:
When we want to overwrite value stored in SRAM cell, we will set BL and -BL according to our data (To store bit 0 - set BL and unset -BL; to store bit 1 - set -BL and unset BL); then the write is enabled for current set (line) of cells (WL is on; it will open M5 and M6). After opening of M5 and M6, BL and -BL will change state of bistable flip-flop (like in SR-latch). So, new value is written and old value is discarded (by leaking charge into BL and -BL).