flat assembler
Message board for the users of flat assembler.

Index > Windows > A Tiny PE

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
goldenspider



Joined: 16 May 2011
Posts: 38
goldenspider 22 May 2011, 14:38
Wink
Code:
;@rem  $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;@rem  flat assembler  version 1.69.31
;@rem  usage: fasm <source> [output]
;@echo off
;set FILE=tinyPE
;set path=D:\fasm;%path%
;fasm %FILE%.asm %FILE%.exe
;@rem  $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

org 0x400000   ;ImageBase 
origin: 
DOS_MZ_header: 
  .e_magic      db "MZ" 
  .e_cblp dw 0
;===================================
  .Signature    dd "PE"
  .Machine dw 014Ch
Imp_Name_MsgBox:
  .Hint             dw 0001h        
  .MessageBoxA      db 'MessageBoxA',0 ; Name     
Imp_Name_MsgBox_End:
;.TimeDateStamp               dd  00000000h  
;.PointerToSymbolTable    dd  00000000h
;.NumberOfSymbols          dd  00000000h 
 .SizeOfOptionalHeader dw  OptionalHeader_End - OptionalHeader
 .Characteristics      dw  010Fh 
;===================================
OptionalHeader:
  .Magic dw  010Bh ;exe Image
User32_DLL   db 'User32',0
                db 68h
              dd Imp_Name_MsgBox.MessageBoxA 
             db 0EBh,04h
;.MajorLinkerVersion  
;.MinorLinkerVersion 
;.SizeOfCode     
;.SizeOfInitializedData  
;.SizeOfUninitializedData 
  .AddressOfEntryPoint         dd  start-origin              ;*
  .BaseOfCode                  db  0FFh,34h,24h,6Ah          ;*# ---Code 2---- 8 ----------
  .BaseOfData                  db  00h,090h,0EBh,84          ;*# -----------------------
  .ImageBase                   dd  origin                            
  .SectionAlignment            dd  00000004h                 ;*
  .FileAlignment               dd  00000004h                 ;* 
  .MajorOperatingSystemVersion dw  0004h 
  .MinorOperatingSystemVersion dw  0000h 
start:
  .MajorImageVersion           db  6Ah                       ;# ---Code 1 ---- 4 ----------
                               db  00h
  .MinorImageVersion           db  0EBh                      ;# 
                               db  -39
  .MajorSubsystemVersion       dw  0004h  
  .MinorSubsystemVersion       dw  0000h  
  .Win32VersionValue           dd  00000000h                 ;# 
  .SizeOfImage                 dd  Code_End-origin           ;*
  .SizeOfHeaders               dd  OptionalHeader_End-origin ;*
  .CheckSum                    dd  00000000h 
  .Subsystem                   dw  0002h  
  .DllCharacteristics          dw  0000h  
  .SizeOfStackReserve          dd  00100000h                 ;# 
  .SizeOfStackCommit           dd  00001000h 
  .SizeOfHeapReserve           dd  00100000h                 ;# 
Thunk_User32:
 .Imp_MsgBox                   dd  Imp_Name_MsgBox-origin    ;[***]
                               dd  00000000h                 ;End
;.SizeOfHeapCommit  
;.LoaderFlags 
 .NumberOfRvaAndSizes          dd  00000002h           ;*
 .ExportRva                    dd  00000000h           ;# 
 .ExportSize                   dd  0000000h            ;# 
 
 .ImportRva                    dd  ImportDir-origin  

ImportDir:
 .ImportSize                   dd  ImportDir_End - ImportDir  ;# ;*    
                               db  0FFh, 15h           ;*# ---Code 3 -------- 8 -----------
                               ;dd   Thunk_User32        ;call [****]  call [00400070h]
                               db  70h,0
OptionalHeader_End: ;section_header
                               db  40h,0
                               db  90h, 0C3h           ; nop ret  modify 90h to 0CCh to debug
; OriginalFirstThunk 
; TimeDateStamp 
; ForwarderChain                
                               dd User32_DLL-origin  ; Name                                 
 .VirtualSize                  dd Thunk_User32-origin ; FirstThunk
ImportDir_End:
 .VirtualAddress               dd  0             
 .SizeOfRawData                db Code_End-origin         ;RVA     
         
Code_End:
      
Post 22 May 2011, 14:38
View user's profile Send private message Reply with quote
mindcooler



Joined: 01 Dec 2009
Posts: 423
Location: Västerås, Sweden
mindcooler 22 May 2011, 18:48
I take it that you're on XP.
Post 22 May 2011, 18:48
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
Overflowz



Joined: 03 Sep 2010
Posts: 1046
Overflowz 22 May 2011, 22:30
Good work mate ! Smile But topic like that already exists here Razz
http://board.flatassembler.net/topic.php?t=1309
Anyway, nice work! Smile
Post 22 May 2011, 22:30
View user's profile Send private message Reply with quote
goldenspider



Joined: 16 May 2011
Posts: 38
goldenspider 23 May 2011, 04:14
mindcooler wrote:
I take it that you're on XP.

Yeah, Win7 appears: Program too big to fit in memory. I will try to make some corrections.

Aha ,Overflowz, thx.
Post 23 May 2011, 04:14
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 23 May 2011, 17:11
The smallest possible PE correctly loadable by XP has the size 97 bytes. Besides it is also able to show a message box.
Post 23 May 2011, 17:11
View user's profile Send private message Reply with quote
goldenspider



Joined: 16 May 2011
Posts: 38
goldenspider 24 May 2011, 03:57
l_inc wrote:
The smallest possible PE correctly loadable by XP has the size 97 bytes. Besides it is also able to show a message box.

Able to share it? Wink
Post 24 May 2011, 03:57
View user's profile Send private message Reply with quote
mindcooler



Joined: 01 Dec 2009
Posts: 423
Location: Västerås, Sweden
mindcooler 24 May 2011, 06:19

_________________
This is a block of text that can be added to posts you make.
Post 24 May 2011, 06:19
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
goldenspider



Joined: 16 May 2011
Posts: 38
goldenspider 24 May 2011, 08:35
I know this site.

" Besides it is also able to show a message box?"
Post 24 May 2011, 08:35
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 24 May 2011, 14:25
Quote:
Able to share it?

That is actually not me, who shares the sample, because I did not make it.
Anyway you can find it within the attachment to this post.
The executable within the attachment produces the 97 bytes PE. This is needed, because the 97 bytes executable relies on hardcoded addresses of LoadLibrary and MessageBox, which are filled by the producing executable. Otherwise it would not be possible to fit the code within 97 bytes, because the data directory entries are also cut off and dynamical search for the APIs (e.g. through PEB) needs comparatively much place.

Have fun. Wink

P.S. And in the attachment to the last post of the same thread you can find a whole window application having the size of 185 bytes.
Post 24 May 2011, 14:25
View user's profile Send private message Reply with quote
mindcooler



Joined: 01 Dec 2009
Posts: 423
Location: Västerås, Sweden
mindcooler 24 May 2011, 17:39
Anyone knows anything about "importing functions by hash"?

From Crinkler manual:

Quote:
- DLL functions are imported by hash code. This is robust to
structural changes to the DLL between different versions while being
quite compact - only 4 bytes per imported function. For DLLs with
fixed relative ordinals (such as opengl32), a special technique,
ordinal range import, can be used to further reduce the number of
hash codes needed.

_________________
This is a block of text that can be added to posts you make.
Post 24 May 2011, 17:39
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 24 May 2011, 21:29
mindcooler
"Importing functions by hash" is not some standard import resolving method supported by PEs. Instead of making use of the windows PE loader ability to find function addresses by names specified within the PE import directory the linker embeds own stub procedure into the executable.

Thus if an executable imports for example ExitProcess, then the linker inserts a hash of the string "ExitProcess" (let's say 0x89ABCDEF) into some table with such hashes.

Once the PE is loaded into memory the previously mentioned stub procedure gets control, loads the corresponding dll (well... in this case kernel32 does not need to be extra loaded), goes through the export table of this dll and computes hashes for every function name within the export table. When/if the desired hash (0x89ABCDEF) is found, the stub procedure takes the corresponding address (of the function ExitProcess) and inserts it into the executable's original or linker's self-made IAT.

One disadvantage of this approach is efficiency loss. Apart from the time delays necessary to compute a hash for every checked exported name, it is also impossible to perform binary search over sorted array of exported names like Windows PE loader does. However resolving function addresses by hash may also be optimized, if the hashes are placed into a hash table (with O(1) lookup complexity). But this optimization is also questionable.

Another disadvantage arises from the chance of hash collision if the hash function has not been chosen very carefully. In this case the loaded PE will crash if you're lucky (I don't consider hidden bugs to be a good luck).

Anyway such approach is widely used by base independent pieces of code, including malware.
Post 24 May 2011, 21:29
View user's profile Send private message Reply with quote
mindcooler



Joined: 01 Dec 2009
Posts: 423
Location: Västerås, Sweden
mindcooler 24 May 2011, 21:46
Ah, so instead of calling the system call, you are calling a stub that does the job of the windows loader. I can see why this would save space for large includes, like OpenGL.

And "ordinal range" is just a loop i guess.
Post 24 May 2011, 21:46
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 24 May 2011, 21:59
mindcooler
Quote:
so instead of calling the system call, you are calling a stub that does the job of the windows loader

First part of the sentence is wrong. The second is right. The stub is called only once, right after the PE has been loaded by windows. It resolves all the addresses of the functions imported by the payload code of the executable and saves the addresses into the IAT (windows PE loader does the same job, if the function names or ordinals are specified within the PE import table). A normal API function call (I wouldn't name it a system call, because it's normally referred to functions provided by the kernel and called via int/syscall/sysenter) is made in the same way as by normal executables. E.g. call dword [401236], where 401236 is the address of an entry within the IAT, which contains an address of the corresponding API function.

I assume, "ordinal range import" refers to the normal import by ordinals, supported by PE format. Or may be not.
Post 24 May 2011, 21:59
View user's profile Send private message Reply with quote
rain_storm



Joined: 05 Apr 2007
Posts: 67
Location: Ireland
rain_storm 25 May 2011, 21:37
mindcooler wrote:
Anyone knows anything about "importing functions by hash"?

I know a little something something bout the matter

http://www.dbfinteractive.com/forum/index.php?topic=3274.msg43812#msg43812
http://www.dbfinteractive.com/forum/index.php?topic=4019.msg54032#msg54032
http://www.dbfinteractive.com/forum/index.php?topic=4981.msg66772#msg66772

Heres an example from that last thread, its a 512b with integrated import by hash (not compressed with a packer)

Can anyone help me get rid of byte 513 in this image any attempt to do so seems to break compatibility with Win7. And without direct access to a Win7 box its a pain in the butt for me to go about this through trial and error.


Description:
Download
Filename: 471b.zip
Filesize: 5.42 KB
Downloaded: 361 Time(s)

Post 25 May 2011, 21:37
View user's profile Send private message Reply with quote
iic2



Joined: 26 Jun 2008
Posts: 122
iic2 31 May 2011, 09:40
Do you guys realize that goldenspider PE don't set-off Avira-2010 with the latest update. I have never seen a single manual PE that did not. WoW! Can you guys check with other anti-virus programs that you may be using?

goldenspider, what did you do to archive all of this??? Anyway, if you can get this much out of Windows-7 and the up-coming Windows-8, anything else that need to be done can get in line. Great work!
Post 31 May 2011, 09:40
View user's profile Send private message Reply with quote
rain_storm



Joined: 05 Apr 2007
Posts: 67
Location: Ireland
rain_storm 31 May 2011, 15:34
It aint that difficult iic2, all you have to do is make a change to the image and load it in IDA. If it loads without errors then you're golden. You can safely ignore the error regarding "cannot allocate memory heap". The one I posted shouldn't raise any alarms, I aint heard feedback about false positives... yet.
Post 31 May 2011, 15:34
View user's profile Send private message Reply with quote
goldenspider



Joined: 16 May 2011
Posts: 38
goldenspider 01 Jun 2011, 02:13
The main problem is not compatible with Windows-7.
Is not allowed such a small PE on the Windows-7 ?
Post 01 Jun 2011, 02:13
View user's profile Send private message Reply with quote
iic2



Joined: 26 Jun 2008
Posts: 122
iic2 01 Jun 2011, 03:53
Quote:
The one I posted shouldn't raise any alarms, I aint heard feedback about false positives... yet.

rain_storm, I don't think you did you home work. Since 2003 I never seen a PE created for FASM that did not set off an anti-virus warning. Now in 2011 you tell me it's was EASY ... LOL
Quote:
all you have to do is make a change to the image and load it in IDA.

I will be using this once I get back into my ASM. You idea makes since for a lot more too. But I swear I hope you are right on this one in the end, if so, please do me this one giant favor ... SHOW ME!

For now the 471b.zip you posted fire-off Avira-2010 with-out hesitation. This could be that you forgot to apply your own method of testing with the final version. Could you fix 471b with your method and repost it. If it don't work, don't feel bad about it. I just hope it do.
....
....

NEW GAME - NEW RULES - xp and beyond 2011

1) Working FASM-PE - working means working. Extended to mean no-virus WARNING allow.

2) size - this means the smallest working PE for any or each modern 32-64bit OS since Windows XP..

goldenspider-PE xp:
tinyPE - 161 byte

As of 6/01/2011 it's the smallest and the only one in FASM universe that works out the box for XP.

Well, at lease that the way I see it.

Quote:
The main problem is not compatible with Windows-7.
Is not allowed such a small PE on the Windows-7 ?

goldenspider, I remember something about a 47byte PE ... And it was concluded:
Quote:
Is not allowed such a small PE on the Windows-ME

...so the minimum size max-out at 97 bytes that even worked for windows-XP. The between 1999-2003 thread is here, posted by "babyboy" if I remember correctly. But still virus warning became an issue a few years latter. To me they use FASM to fight the power of FASM but now the jig is up, thanks to goldenspider-PE. Keep your eyes open to see what happen.

Get the picture. Don't waste your time on the HYPE... It's going to take rocket science for someone to reduce your working XP-PE by one byte and if that is possible only somebody like bitRAKE can do that.

Btw; there were some new threads here about the new Windows-7 PE with-in the pass 8 months. I did not read it fully. I gave up during the Win95 to XP disaster on my app (a*s). I was still writing for my tiny Win-95 PE in 2006 until XP Service-pack-2 took me out the game until now.

Thanks goldenspider
Post 01 Jun 2011, 03:53
View user's profile Send private message Reply with quote
goldenspider



Joined: 16 May 2011
Posts: 38
goldenspider 01 Jun 2011, 07:10
[quote="iic2"]
Quote:

NEW GAME - NEW RULES - xp and beyond 2011

1) Working FASM-PE - working means working. Extended to mean no-virus WARNING allow.

2) size - this means the smallest working PE for any or each modern 32-64bit OS since Windows XP..

Funny .

------------------------------
Complete scanning result of "tinyPE.exe",(161Bytes) received in VirusTotal :
File name: tinyPE.exe
Submission date: 2011-06-01 06:42:02 (UTC)
Current status: finished
Result: 0 /41 (0.0%)

Antivirus........ VersionLast ........ Update ....... Result
AhnLab-V3..... 2011.06.01.01... .2011.06.01..... -
AntiVir............7.11.8.213......... 2011.06.01..... -
Antiy-AVL....... 2.0.3.7............... 2011.06.01......-
...

Additional informationShow all
MD5 : 8b7b522a8f3468ad462186f28cd6043c
SHA1 : 4c04a0a6814695f4bfa8bbc50508ca869c6c3f3a
SHA256: f58efe79703f130a75f46728ea1c01a6cf9d93e1d8180baea19feb3febe24018
Post 01 Jun 2011, 07:10
View user's profile Send private message Reply with quote
rain_storm



Joined: 05 Apr 2007
Posts: 67
Location: Ireland
rain_storm 01 Jun 2011, 22:59
iic2 - Of course I did not literally mean "easy" Byte Crunching is long hard work, if I'm proven wrong it wouldn't surprise me, you'll always get a false positive with one AV or another. But that trick will catch all of the obvious stuff that looks suspicious. like not having a text section, or having no sections at all.

I needed to ensure Win7 compatibility wasn't broken. but I'm running XP SP3, and the only Win7 box I have access to is at work. That meant I only had one test run per day. I needed to get the most out of each run so I started using IDA to verify the image at home. I use AVG on my system and the Win7 box I tested on was running Norton. Neither of them complained.
Post 01 Jun 2011, 22:59
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.