Recent Posts

Pages: 1 ... 8 9 [10]
CLFLUSH is a ring0 instrunction. If you are running MS-DOS you are using ring0...
Unless you are using a very old processor (before Core2), CLFLUSH is available.

BUT, to do a cleanup of L1I cache, I believe, isn't possible.
I didn't know you could do that. Only thing I can think would be to use NOPs to execute for as many cycles as needed. I use code modifiers as part of my CPUID code to differentiate between 8088 and 8086.
Programming with NASM / How do you refresh the instruction cache in 16bit programs?
« Last post by ben321 on February 28, 2023, 09:33:35 PM »
I know that in 32bit Windows (which uses 32bit protected mode) you call the Windows API function FlushInstructionCache. This forces the CPU to clear the instruction cache, and should be called immediately after any code to be executed gets modified (for self modifying code, such as compressed EXE files). How do you do the same thing in 16bit real mode (or for that matter in 16bit protected mode)?
See the instructions BTC, BTS, BSR and BSF.
Programming with NASM / Anyone come across information about optimizing this?
« Last post by Franciswalser on February 28, 2023, 11:49:53 AM »
I'm currently playing around with a 64-bit x86_64 kernel and am at the point where I need to do paging.
I've written bit arrays before in several languages but was wondering if there are more efficient ways to do
it in assembly.   It really only needs three operations:

1.  Set bit
2.  Clear bit
3.  Find first cleared bit

The set and clear bit functions are pretty straightforward, but the find first clear bit is a time hog. TellTims Survey

I've google'd for this, but keep finding information on bit masking word sized values and the like.  Plus, I'm sure
my google-fu is weak.

Anyone come across information about optimizing this?
Other Discussion / Re: TASM32, MASM32, MASM64 Quines
« Last post by alCoPaUL on February 27, 2023, 10:02:49 PM »
that's why it's in the off-topic section.

but if you think of it, this is related to "Source Code Portability".

you can use this as an EXTERNAL reference as a comparison to the NASM quine i made for WINDOWS and MacOS.

if you insist that this belongs to its own appropriate forum, what they use there is old assembly syntax and also they are not using ML64.EXE there.

idk why people here are coming so hard everytime i post.

Other Discussion / Re: TASM32, MASM32, MASM64 Quines
« Last post by debs3759 on February 27, 2023, 09:08:36 PM »
You do realise that this is a NASM forum? I imagine it assembles and executes fine, but just saying...
Other Discussion / Re: TASM32, MASM32, MASM64 Quines
« Last post by alCoPaUL on February 27, 2023, 08:27:17 PM »

1.) Adjust your text viewer (e.g. Notepad) to open with Windows CRLF formatting.
2.) Adjust your console upto the 169th column for the artsy view of the quine..
3.) For the first quine, replace the tilde (~) with the minus (-) sign.
4.) To get the proper source code output, do the birdquine.exe > birdquine.txt and assemble/link birdquine.txt for the roundtrip, proving that it is indeed a quine.

Build Tools:
a.) Use Visual Studio 2010 x86/win64 build tools. The libs should be compatible but I included the exact libs as a separate download just in case.
b.) Obtain TASM 5 and update it with the necessary .exe patches coz assembling the TASM32 source code with the vanilla/rtm version leads to error. You can download the LATEST TASM32.EXE from Embarcadero's C++ Builder 10.4 Suite, which is free to try. I used TLINK32.EXE (updated/update file together with TASM32 update file) from TASM 5 suite+updates. You can use any of the 2 C Runtime libs (the one with "t" and the other one with "latest") that I provided with no error.

~ alCoPaUL [GIMO][As][aBrA][NPA][b8][BCVG][rRlf]
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
  ; 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!
  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.
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
Pages: 1 ... 8 9 [10]