Recent Posts

Pages: 1 ... 3 4 [5] 6 7 ... 10
41
Programming with NASM / Re: Question about Windows programming and section attributes
« Last post by ben321 on February 27, 2023, 08:01:45 PM »
Depending on the mode of operation (i386 or x86-64) this can be impossible.

i386 mode uses different segment selectors for code and data and code segments can be only executed and/or read (not write!). Unless the data descriptor is mapped to the sabe linear address space that of the codeseg, you can't write in codeseg.

In x86-64 there's no segmentation, but the page write code is in can be marked as read-only.

See Intel SDM volume 3 about protection and memory management.

This code is valid on i386/x86-64 modes (because only READs the msg bytes, don't write on this region):
Code: [Select]
  ; i386 mode Win32 hello using only a text segment.
  ;
  ; nasm -fwin32 -o test.o test.asm
  ; ld -s -o test.exe test.o -lkernel32
  ;
  bits  32

  section .text

  extern __imp__GetStdHandle@4
  extern __imp__WriteConsoleA@20
  extern __imp__ExitProcess@4

  global _start
_start:
  ; Get STDOUT handle.
  push  -11
  call  [__imp__GetStdHandle@4]

  push  0
  push  0
  push  msg_len
  push  msg
  push  eax
  call  [__imp__WriteConsoleA@20]

  push  0
  jmp   [__imp__ExitProcess@4]

  ; Notice: this is in .text section!
  ; Can read, but can't write!
msg:
  db    `Hello\r\n`
msg_len equ $ - msg

Try to add mov byte [msg + 5],0 before calling WriteConsoleA and you'll get an 'segmentation fault'.

I'm using 64bit Windows but am writing a 32bit program. When I look at the EXE output from NASM in a hex editor, the Characteristics field in the section header for the .text section, I see the bytes 0x20, 0x00, 0x00, 0x60. The first byte is the one that tells the OS what type of content is in it. 0x20 is code. 0x40 would be data. 0x60 would be both code and data. The last byte says 0x60, and this is the protection byte. The value 0x60 here means that reading and executing are permitted. 0x20 would mean executing code is permitted, 0x40 would mean reading is permitted, and 0x80 would mean writing is permitted. The actual permissions granted is a combination of one or more of these flags. In the case of the .text section output by NASM and GoLink, the value here is 0x60, meaning read and execute permissions are granted, but writing permission is not granted. In OllyDbg, such a section has its permissions shown as "R E". If it also had writing permission, it would show as "RWE". The resulting flag value for such an RWE section would be 0xE0 (the sum of 0x20 + 0x40 + 0x80). And yes, I've tested it by using a hex editor and manually setting the write permission in this way. And it works fine.

I just don't want to have to hexedit my EXE after every single compilation, in order to get my code to work. It would be nice, if NASM provided a way to set these permission flags for each section. Those permission flags would then get stored in the MS style COFF file that's output from the WIN32 format from NASM, and then the linker would be forced to give those permissions to that section when it generated the EXE file. I'm surprised that NASM doesn't have this feature yet. Anybody wanting to make self modifying code will NEED this feature.

Things like EXE compressors (as well as EXE obfuscators to try to stop reverse engineering) do this all the time. When such a tool is run on an EXE, it compresses the code section and puts it in a new section, and replaces the original code section with decompression or decryption code, as well as creating a third section that is uninitialized (the section header says where it should be allocated, but the EXE file itself contains no data or code to fill it). When you run the EXE, it runs the decryption or decompression code, and puts the output of this operation into the third section, and then jumps to that new section. Guess what type of permissions that third section has. Yep, it has both write and execute permissions. So that way the decompressed/decrypted code can be written into the third section and executed.


I'm just wondering if NASM has a feature to assign such access permissions to sections, even if it's not a documented feature. If not a feature now, it should certainly be added as soon as the devs have the time to do so.
42
Example Code / Re: MacOS Quine (And Many More)
« Last post by alCoPaUL on February 27, 2023, 07:03:55 PM »
Bumping the Example Quines From The Off-Topic Section

TASM32, MASM32, MASM64 Quines
https://forum.nasm.us/index.php?topic=3686.0
43
Other Discussion / TASM32, MASM32, MASM64 Quines
« Last post by alCoPaUL on February 27, 2023, 07:01:58 PM »
Code: [Select]
; Benu

; by alCoPaUL [GIMO][As][aBrA][NPA][b8][BCVG][rRlf]

; 2/27/2023 NYC

; tasm32 benu.asm

; tlink32 ~Tpe ~ap benu.obj,benu.exe,,tmsvcrt.lib,,

.686

.model flat,stdcall

extrn _printf:proc

.code

start:

enter 0,0

mov al,0Dh

mov bl,2Dh

z:lea edx,a

mov cx,1318

r:cmp byte ptr[edx],bl

je s

jmp u

s:mov byte ptr[edx],al

cmp al,2Dh

je c

mov byte ptr[edx+1],0Ah

jmp u

c:mov byte ptr[edx+1],2Dh

u:inc edx

dec cx

cmp cx,0

jnz r

cmp bl,0Dh

je td

push offset a

push offset i

call _printf

jmp ll

td:

lea edi,n

lea esi,a

mov cx,1374

sn:mov al,byte ptr[esi]

mov byte ptr[edi],al

inc esi

inc edi

dec cx

cmp cx,1224

je t

cmp cx,1074

je t

cmp cx,924

je t

cmp cx,774

je t

cmp cx,624

je t

cmp cx,474

je t

cmp cx,324

je t

cmp cx,174

je t

cmp cx,24

je t

jmp sts

t:mov byte ptr[edi],27h

mov byte ptr[edi+1],0Dh

mov byte ptr[edi+2],0Ah

mov byte ptr[edi+3],64h

mov byte ptr[edi+4],62h

mov byte ptr[edi+5],20h

mov byte ptr[edi+6],27h

add edi,7

jmp sts

sts:cmp cx,0

jne sn

push offset n

push offset i

call _printf

ll:mov al,0Dh

cmp bl,2Dh

xchg al,bl

je z

push offset x

push offset i

call _printf

leave

ret

.data

d db 27h,0Dh,0Ah,64h,62h,20h,27h,0

x db 2Ch,32h,37h,68h,2Ch,30h,0Dh,0Ah,65h,6eh,64h,20h,73h,74h,61h,72h,74h,0

i db 25h,73h,0

n db 1380 DUP(0)

a db '; Benu--; by alCoPaUL [GIMO][As][aBrA][NPA][b8][BCVG][rRlf]--; 2/27/2023 NYC--; tasm32 benu.asm--; tlink32 ~Tpe ~ap benu.obj,benu.exe,,tmsvcrt.lib,,--'

db '.686--.model flat,stdcall--extrn _printf:proc--.code--start:--enter 0,0--mov al,0Dh--mov bl,2Dh--z:lea edx,a--mov cx,1318--r:cmp byte ptr[edx],bl--je '

db 's--jmp u--s:mov byte ptr[edx],al--cmp al,2Dh--je c--mov byte ptr[edx+1],0Ah--jmp u--c:mov byte ptr[edx+1],2Dh--u:inc edx--dec cx--cmp cx,0--jnz r--cmp'

db ' bl,0Dh--je td--push offset a--push offset i--call _printf--jmp ll--td:--lea edi,n--lea esi,a--mov cx,1374--sn:mov al,byte ptr[esi]--mov byte ptr[edi]'

db ',al--inc esi--inc edi--dec cx--cmp cx,1224--je t--cmp cx,1074--je t--cmp cx,924--je t--cmp cx,774--je t--cmp cx,624--je t--cmp cx,474--je t--cmp cx,32'

db '4--je t--cmp cx,174--je t--cmp cx,24--je t--jmp sts--t:mov byte ptr[edi],27h--mov byte ptr[edi+1],0Dh--mov byte ptr[edi+2],0Ah--mov byte ptr[edi+3],64'

db 'h--mov byte ptr[edi+4],62h--mov byte ptr[edi+5],20h--mov byte ptr[edi+6],27h--add edi,7--jmp sts--sts:cmp cx,0--jne sn--push offset n--push offset i--'

db 'call _printf--ll:mov al,0Dh--cmp bl,2Dh--xchg al,bl--je z--push offset x--push offset i--call _printf--leave--ret--.data--d db 27h,0Dh,0Ah,64h,62h,20h'

db ',27h,0--x db 2Ch,32h,37h,68h,2Ch,30h,0Dh,0Ah,65h,6eh,64h,20h,73h,74h,61h,72h,74h,0--i db 25h,73h,0--n db 1380 DUP(0)--a db ',27h,0

end start
; ###########################

; Firebird

; by alCoPaUL[GIMO][As][aBrA][NPA][b8][BCVG][rRlf]

; 2/27/2023 NYC

; ml64.exe firebird.asm /link /subsystem:console /defaultlib:64mscrt.lib /entry:main

; ############

;

extrn printf:proc

.code

main proc

sub rsp,28h

mov al,13

mov bl,95

z:lea r9,a

mov dx,1329

r:cmp byte ptr[r9],bl

je s

jmp u

s:mov byte ptr[r9],al

cmp al,95

je kcl

mov byte ptr[r9+1],10

jmp u

kcl:mov byte ptr[r9+1],95

u:inc r9

dec dx

cmp dx,0

jnz r

cmp bl,0Dh

je otd

lea rdx,a

lea rcx,i

call printf

jmp ll

otd:

lea rdi,n

lea rsi,a

mov cx,1380

son:mov al,byte ptr[rsi]

mov byte ptr[rdi],al

inc rsi

inc rdi

dec cx

cmp cx,1224

je t

cmp cx,1074

je t

cmp cx,924

je t

cmp cx,774

je t

cmp cx,624

je t

cmp cx,474

je t

cmp cx,324

je t

cmp cx,174

je t

cmp cx,24

je t

jmp sts

t:mov byte ptr[rdi],27h

mov byte ptr[rdi+1],0Dh

mov byte ptr[rdi+2],0Ah

mov byte ptr[rdi+3],64h

mov byte ptr[rdi+4],62h

mov byte ptr[rdi+5],20h

mov byte ptr[rdi+6],27h

add rdi,7

jmp sts

sts:cmp cx,0

jne son

lea rdx,n

lea rcx,i

call printf

ll:mov al,13

cmp bl,95

xchg al,bl

je z

lea rdx,x

lea rcx,i

call printf

add rsp,28h

ret

main endp

.data

d db 27h,0Dh,0Ah,64h,62h,20h,27h,0

x db 2Ch,32h,37h,68h,2Ch,30h,0Dh,0Ah,65h,6eh,64h,0

i db 25h,73h,0

n db 1380 DUP(0)

a db '; ###########################__; Firebird__; by alCoPaUL[GIMO][As][aBrA][NPA][b8][BCVG][rRlf]__; 2/27/2023 NYC__; ml64.exe firebird.asm /link /subsystem:con'

db 'sole /defaultlib:64mscrt.lib /entry:main__; ############__;__extrn printf:proc__.code__main proc__sub rsp,28h__mov al,13__mov bl,95__z:lea r9,a__mov d'

db 'x,1329__r:cmp byte ptr[r9],bl__je s__jmp u__s:mov byte ptr[r9],al__cmp al,95__je kcl__mov byte ptr[r9+1],10__jmp u__kcl:mov byte ptr[r9+1],95__u:inc r'

db '9__dec dx__cmp dx,0__jnz r__cmp bl,0Dh__je otd__lea rdx,a__lea rcx,i__call printf__jmp ll__otd:__lea rdi,n__lea rsi,a__mov cx,1380__son:mov al,byte pt'

db 'r[rsi]__mov byte ptr[rdi],al__inc rsi__inc rdi__dec cx__cmp cx,1224__je t__cmp cx,1074__je t__cmp cx,924__je t__cmp cx,774__je t__cmp cx,624__je t__cm'

db 'p cx,474__je t__cmp cx,324__je t__cmp cx,174__je t__cmp cx,24__je t__jmp sts__t:mov byte ptr[rdi],27h__mov byte ptr[rdi+1],0Dh__mov byte ptr[rdi+2],0A'

db 'h__mov byte ptr[rdi+3],64h__mov byte ptr[rdi+4],62h__mov byte ptr[rdi+5],20h__mov byte ptr[rdi+6],27h__add rdi,7__jmp sts__sts:cmp cx,0__jne son__lea '

db 'rdx,n__lea rcx,i__call printf__ll:mov al,13__cmp bl,95__xchg al,bl__je z__lea rdx,x__lea rcx,i__call printf__add rsp,28h__ret__main endp__.data__d db '

db '27h,0Dh,0Ah,64h,62h,20h,27h,0__x db 2Ch,32h,37h,68h,2Ch,30h,0Dh,0Ah,65h,6eh,64h,0__i db 25h,73h,0__n db 1380 DUP(0)__a db ',27h,0

end

;FengHuang

;by alCoPaUL[GIMO][As][aBrA][NPA][b8]

;2/27/2023

;ml fh.asm /link /subsystem:console /defaultlib:32mscrt.lib /entry:main

.686

.model flat,stdcall

extern printf:proc

.code

start:

main proc

enter 0,0

mov al,0Dh

mov bl,2Dh

z:lea edx,a

mov cx,1329

r:cmp byte ptr[edx],bl

je s

jmp u

s:mov byte ptr[edx],al

cmp al,2Dh

je g

mov byte ptr[edx+1],0Ah

jmp u

g:mov byte ptr[edx+1],2Dh

u:inc edx

dec cx

cmp cx,0

jnz r

cmp bl,0Dh

je td

push offset a

push offset i

call printf

jmp ll

td:

lea edi,n

lea esi,a

mov cx,1374

sn:mov al,byte ptr[esi]

mov byte ptr[edi],al

inc esi

inc edi

dec cx

cmp cx,1224

je t

cmp cx,1074

je t

cmp cx,924

je t

cmp cx,774

je t

cmp cx,624

je t

cmp cx,474

je t

cmp cx,324

je t

cmp cx,174

je t

cmp cx,24

je t

jmp sts

t:mov byte ptr[edi],27h

mov byte ptr[edi+1],0Dh

mov byte ptr[edi+2],0Ah

mov byte ptr[edi+3],64h

mov byte ptr[edi+4],62h

mov byte ptr[edi+5],20h

mov byte ptr[edi+6],27h

add edi,7

jmp sts

sts:cmp cx,0

jne sn

push offset n

push offset i

call printf

ll:mov al,0Dh

cmp bl,2Dh

xchg al,bl

je z

push offset x

push offset i

call printf

leave

ret

main endp

.data

d db 27h,0Dh,0Ah,64h,62h,20h,27h,0

x db 2Ch,32h,37h,68h,2Ch,30h,0Dh,0Ah,65h,6eh,64h,20h,73h,74h,61h,72h,74h,0

i db 25h,73h,0

n db 1380 DUP(0)

a db ';FengHuang--;by alCoPaUL[GIMO][As][aBrA][NPA][b8]--;2/27/2023--;ml fh.asm /link /subsystem:console /defaultlib:32mscrt.lib /entry:main--.686--.model f'

db 'lat,stdcall--extern printf:proc--.code--start:--main proc--enter 0,0--mov al,0Dh--mov bl,2Dh--z:lea edx,a--mov cx,1329--r:cmp byte ptr[edx],bl--je s--'

db 'jmp u--s:mov byte ptr[edx],al--cmp al,2Dh--je g--mov byte ptr[edx+1],0Ah--jmp u--g:mov byte ptr[edx+1],2Dh--u:inc edx--dec cx--cmp cx,0--jnz r--cmp bl'

db ',0Dh--je td--push offset a--push offset i--call printf--jmp ll--td:--lea edi,n--lea esi,a--mov cx,1374--sn:mov al,byte ptr[esi]--mov byte ptr[edi],al-'

db '-inc esi--inc edi--dec cx--cmp cx,1224--je t--cmp cx,1074--je t--cmp cx,924--je t--cmp cx,774--je t--cmp cx,624--je t--cmp cx,474--je t--cmp cx,324--j'

db 'e t--cmp cx,174--je t--cmp cx,24--je t--jmp sts--t:mov byte ptr[edi],27h--mov byte ptr[edi+1],0Dh--mov byte ptr[edi+2],0Ah--mov byte ptr[edi+3],64h--m'

db 'ov byte ptr[edi+4],62h--mov byte ptr[edi+5],20h--mov byte ptr[edi+6],27h--add edi,7--jmp sts--sts:cmp cx,0--jne sn--push offset n--push offset i--call'

db ' printf--ll:mov al,0Dh--cmp bl,2Dh--xchg al,bl--je z--push offset x--push offset i--call printf--leave--ret--main endp--.data--d db 27h,0Dh,0Ah,64h,62'

db 'h,20h,27h,0--x db 2Ch,32h,37h,68h,2Ch,30h,0Dh,0Ah,65h,6eh,64h,20h,73h,74h,61h,72h,74h,0--i db 25h,73h,0--n db 1380 DUP(0)--a db ',27h,0

end start

Ready to assemble and link sources and respective Essential Libraries Attached..

~ alCoPaUL [GIMO][As][aBrA][NPA][b8][BCVG][rRlf]
44
Depending on the mode of operation (i386 or x86-64) this can be impossible.

i386 mode uses different segment selectors for code and data and code segments can be only executed and/or read (not write!). Unless the data descriptor is mapped to the sabe linear address space that of the codeseg, you can't write in codeseg.

In x86-64 there's no segmentation, but the page write code is in can be marked as read-only.

See Intel SDM volume 3 about protection and memory management.

This code is valid on i386/x86-64 modes (because only READs the msg bytes, don't write on this region):
Code: [Select]
  ; i386 mode Win32 hello using only a text segment.
  ;
  ; nasm -fwin32 -o test.o test.asm
  ; ld -s -o test.exe test.o -lkernel32
  ;
  bits  32

  section .text

  extern __imp__GetStdHandle@4
  extern __imp__WriteConsoleA@20
  extern __imp__ExitProcess@4

  global _start
_start:
  ; Get STDOUT handle.
  push  -11
  call  [__imp__GetStdHandle@4]

  push  0
  push  0
  push  msg_len
  push  msg
  push  eax
  call  [__imp__WriteConsoleA@20]

  push  0
  jmp   [__imp__ExitProcess@4]

  ; Notice: this is in .text section!
  ; Can read, but can't write!
msg:
  db    `Hello\r\n`
msg_len equ $ - msg

Try to add mov byte [msg + 5],0 before calling WriteConsoleA and you'll get an 'segmentation fault'.
45
Programming with NASM / Re: Question about Windows programming and section attributes
« Last post by ben321 on February 27, 2023, 02:27:12 PM »
See nasmdoc chapter 8.

Where do I download NASM Doc?

Update:
Nevermind, I found it here https://www.nasm.us/xdoc/2.16.01/html/nasmdoc0.html



Update2:
I was reading chapter 8 here https://www.nasm.us/xdoc/2.16.01/html/nasmdoc8.html like you said, and unless I somehow overlooked it, it seems none of the Windows output object formats like COFF or WIN32 (depending on which linker you plan to use) indicate that you can combine multiple section characteristics such as data+code. If I'm wrong here, please let me know.
46
See nasmdoc chapter 8.
47
Programming with NASM / Question about Windows programming and section attributes
« Last post by ben321 on February 27, 2023, 01:10:19 PM »
I know you can override a section to have data or code like this
Code: [Select]
SECTION MySection1 data
SECTION MySection2 code

However, is it possible to label a section as containing both code and data, using NASM? I know the PE format supports this, because the section header has a flags field called Characteristics. This controls how the operating system interprets the contents of this section, whether it can be read, written, or executed (or any combination of these), as well as if it contains code, initialized data, or uninitialized data (or any combination of these). A section does NOT have to contain exclusively data or code. It can certainly contain both. Is it possible to achieve this with NASM? If so how? If not, consider this a feature request.
48
Other Discussion / Legacy 32-bit Assembler to Modern 32-bit Assembler
« Last post by alCoPaUL on February 27, 2023, 01:02:21 AM »
the Microsoft Macro Assembler 32-bit (from the Visual Studio 2010 x86 build tools) has updated its preprocessor to use "extern/extrn functionhere:proc" already and the current maintainer of the community created MASM SDK is still using the old assembler AND that doesn't include some of its modern functions/features (one of which was the feature that I mentioned)

if they continue to build up on that old assembler version (their macros are too stacked), maybe a new feature included that addresses an update can break some of the important stuffs in their SDK.

just saying.
49
Programming with NASM / Re: Ok I finally got this working.
« Last post by ben321 on February 22, 2023, 11:56:27 PM »
See table 9.1 at Intel SDM to have an idea of how to do it... Notice you load the segment descriptors with Granularity flags turned on and never turned it off to go back to real mode (just an example). As for the far jump, to go to protected mode you should do a far 32 bits jump after loading GDTR, not a simple far jump. You are probably NOT in protected mode there because the processor will jump to protected mode just after this specific kind of jump.

I absolutely was in protected mode. I made sure to use a far jump (or in this case a far call). If you read the code I posted at the top of this thread (in fact you initially were replying directly to the code I'd written, when you criticized it), you would see I did make this far call. In fact, DosBox Debugger is what I used to test my code, and like any good debugger it reports the internal state of the CPU. Its mode indicator changed from Real to Pr32 when I made that far call. And after turning off the CR0 bit and then making a far return, the debugger's mode indicator went back to showing Real. And I didn't even have to reload the GDT. Then when I exited to leave back to DOS, I had no problems. Had I attempted to go back to DOS while still in protected mode, it would have crashed.

However you say you need to reload the GDTR when leaving protected mode (even though it worked for me in DosBox without doing this step). So, please inform me more about that. What am I supposed to reload the GDTR with, in order to properly leave protected mode? Am I supposed to load it with a null pointer? Also, am I supposed to do this reloading of the GDTR just before or after I clear the PE bit in CR0?
50
Programming with NASM / Re: Ok I finally got this working.
« Last post by ben321 on February 22, 2023, 11:48:35 PM »
Notice, as an example, you forgot to enable Gate A20 when jumping to protected mode (and disable it when back to real mode).
I wasn't using the extra memory space, just testing how to transition in and out of protected mode.
Pages: 1 ... 3 4 [5] 6 7 ... 10