flat assembler
Message board for the users of flat assembler.
Index
> Windows > Tiny PE in win64Goto page Previous 1, 2, 3, 4 Next |
| Author |
|
|
MatQuasar 19 Apr 2024, 14:22
jochenvnltn wrote: What about a self replicating 64bit EXE ? You can, either submit a pull request (late entry will be accepted) or use your tiny PE and wait for BGGP 2024 (begin in June). I was the winner of PE category (@fliermate) with 1024 bytes. But my late entry is a 528-byte 32-bit PE, as demonstrated in the second last post in page 1 of this thread. (Or you can click link: https://board.flatassembler.net/topic.php?p=237311#237311 ) With your 309-byte tiny PE, I think you can easily beat mine 528-byte PE (and 1KB PE). |
|||
|
|
jochenvnltn 19 Apr 2024, 17:02
MatQuasar wrote:
I now got a working x64 PE, with an import table that shows a MessageBox to 277bytes |
|||
|
|
bitRAKE 22 Apr 2024, 07:13
jochenvnltn wrote: Ill delete my post sorry ! Here is a related article, perhaps of interest ... https://secret.club/2023/06/05/spoof-pe-sections.html (FYI, this technique still works in Win11.) One of the beautiful things about such an advanced assembler, is that we can write code to verify what we know about the loader! Code: ; verify some known rules of loader: load e_lfanew:4 from $$+3Ch ; Offset to the NT header assert e_lfanew < ($-$$-4) ; can't be larger than file load PE_Sig:4 from $$+e_lfanew assert PE_Sig = 'PE' _________________ ¯\(°_o)/¯ AI may [not] have aided with the above reply. |
|||
|
|
jochenvnltn 23 Apr 2024, 17:21
I found this : https://github.com/ayaka14732/TinyPE-on-Win10
Not sure if i want to just take what he did and put it into FASM code. He got to this result by his own effort and i don't want to replicate his project.. A PE file that's 277 bytes and works with Win10 & 11 isn't that bad |
|||
|
|
MatQuasar2 23 Jun 2024, 21:01
A virus researcher's guide to Tiny PE header, with comments for each header field!
http://pferrie.epizy.com/misc/tiny/pehdr.htm |
|||
|
|
ProMiNick 25 Jun 2024, 13:59
(related to win32 subsys) In flat memory model all segments force address space to be mapped exactly at its origin, but fs segment maps memory from TEB structure located somewhere in the middle of address space. for any thread TEB is always located by random addresses from launch to launch. But fs in every thread allways points to TEB of that thread.
|
|||
|
|
revolution 25 Jun 2024, 14:42
MatQuasar2 wrote: What is "fs"? CS DS ES FS GS SS All those are segment registers. Because of paging, segments are mostly useless nowadays, but Windows still uses FS to point to the thread local storage area. |
|||
|
|
MatQuasar2 25 Jun 2024, 14:47
Thanks ProMiNick and revolution, I learned something useful today from both of you.
|
|||
|
|
MatQuasar2 25 Jun 2024, 15:44
MatQuasar2 wrote: Any tiny PE example using GetProcAddress and then LoadLibraryA to call API, especially when need to call more than one API function and want to get rid of import table. I found a great example: https://keyj.emphy.de/win32-pe/ TEB --> PEB --> base address of Kernel32.dll in memory --> .... |
|||
|
|
Roman 26 Jun 2024, 11:27
Quote:
In Windows this registers unavailable. 6 registers i could using for my calculation. Sad but my program crash if i do mov es,ax or mov gs,ax or mov ds,ax. |
|||
|
|
revolution 26 Jun 2024, 11:36
Officially, in protected mode they aren't called registers, they are called selectors. And you can't arbitrarily select a different segment.
If you want to use them as registers, then you have to switch to (un)real mode. |
|||
|
|
Roman 26 Jun 2024, 15:25
Quote: If you want to use them as registers, then you have to switch to (un)real mode. How do this in Windows ? This is option in fasm compiler setup ? |
|||
|
|
revolution 26 Jun 2024, 15:30
You can't switch any current version of Windows to real mode. Real mode is the 1MB, 16-bit mode, with segments. It can be extended to unreal mode using some tricks, but there is no way you can get Windows to run there.
You can run DOS in real mode. Or write your own OS and use real mode there. |
|||
|
|
therektafire 06 Jul 2026, 21:42
Mikl___ wrote: a working PE64 with import, size of exe-file is 282 bytes run on Windows 10 Hey so I'm coming back to this since I want to use this as a basis for a personal asm project I'm trying to get started with, and I'm wondering if there is any way to automatically calculate some of the hardcoded stuff like the virtual size and the import RVA size? Having to figure out exactly what values they need to be every time I want to make a code change would be annoying. And this is more so related to my complete and utter lack of windows PE knowledge but I'm also not sure how I would extend the import table to add multiple dlls since I also want to use specific functions from opengl32 and kernel32. |
|||
|
|
Tomasz Grysztar 06 Jul 2026, 22:10
therektafire wrote: Hey so I'm coming back to this since I want to use this as a basis for a personal asm project I'm trying to get started with, and I'm wondering if there is any way to automatically calculate some of the hardcoded stuff like the virtual size and the import RVA size? Having to figure out exactly what values they need to be every time I want to make a code change would be annoying. And this is more so related to my complete and utter lack of windows PE knowledge but I'm also not sure how I would extend the import table to add multiple dlls since I also want to use specific functions from opengl32 and kernel32. |
|||
|
|
therektafire 07 Jul 2026, 21:02
Tomasz Grysztar wrote:
Thanks, I'm reading through it now and it does indeed seem pretty useful 👍 I already understand most of the actual assembly stuff, it's just the exe formatting part that's tripping me up. It's definitely not a requirement for me to manually create everything, I could just use the built in fasm x64 PE formatting, I just wanted to do it for the "I made it super small" brag |
|||
|
|
Calendos 19 Jul 2026, 17:00
Hello everyone!
In one of the Win64 programs provided as an example in the FASM package (Template.asm), I see the instruction `sub rsp,8` at the entry point. Unless I'm mistaken, I don't see the point of aligning the code to a DQWORD at the beginning of the section when it seems to me that this alignment is implicit. Furthermore, subtracting 8 bytes from `RSP` doesn't seem to guarantee this alignment requirement. What do you think? I've included the beginning of the ASM file below. Thank you! Code: format PE64 GUI 5.0 entry start include 'win64a.inc' section '.text' code readable executable start: sub rsp,8 ; Make stack dqword aligned invoke GetModuleHandle,0 mov [wc.hInstance],rax invoke LoadIcon,0,IDI_APPLICATION mov [wc.hIcon],rax mov [wc.hIconSm],rax invoke LoadCursor,0,IDC_ARROW mov [wc.hCursor],rax invoke RegisterClassEx,wc test rax,rax jz error invoke CreateWindowEx,0,_class,_title,WS_VISIBLE+WS_DLGFRAME+WS_SYSMENU,128,128,256,192,NULL,NULL,[wc.hInstance],NULL test rax,rax jz error …. |
|||
|
|
revolution 19 Jul 2026, 17:30
The stack alignment is a requirement for the FASTCALL convention to work.
It is guaranteed to make RSP aligned, because the loader will call the entry point with an unaligned RSP, as per the FASTCALL convention. Without the stack alignment the program can crash when the OS call (using invoke) uses MOVAPD to copy the registers to the shadow stack. So, yes, the sub rsp,8 is required, unless the desire is to have unreliable code that crashes. BTW: I recommend to use push rbp instead of sub rsp,8. It is shorter and is more compatible with debuggers. |
|||
|
|
Calendos 19 Jul 2026, 17:57
Thank you very much for your very quick and extremely detailed response. However, I need some time to think about what you said. I am struggling to understand why the 'text' section doesn't implicitly provide the required alignment. Am I making myself clear?
|
|||
|
| Goto page Previous 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2026, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.