Index
> Windows > A Tiny PEGoto page 1, 2 Next |
| Author |
|
|
mindcooler 22 May 2011, 18:48
I take it that you're on XP.
|
|||
22 May 2011, 18:48 |
|
|
Overflowz 22 May 2011, 22:30
Good work mate !
 But topic like that already exists here 
http://board.flatassembler.net/topic.php?t=1309 Anyway, nice work! |
|||
|
22 May 2011, 22:30 |
|
|
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. |
|||
|
23 May 2011, 04:14 |
|
|
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.
|
|||
|
23 May 2011, 17:11 |
|
|
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?  |
|||
|
24 May 2011, 03:57 |
|
|
mindcooler 24 May 2011, 06:19
_________________ This is a block of text that can be added to posts you make. |
|||
|
24 May 2011, 06:19 |
|
|
goldenspider 24 May 2011, 08:35
I know this site.
" Besides it is also able to show a message box?" |
|||
|
24 May 2011, 08:35 |
|
|
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.
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. |
|||
|
24 May 2011, 14:25 |
|
|
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 _________________ This is a block of text that can be added to posts you make. |
|||
|
24 May 2011, 17:39 |
|
|
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. |
|||
|
24 May 2011, 21:29 |
|
|
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. |
|||
|
24 May 2011, 21:46 |
|
|
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. |
|||
|
24 May 2011, 21:59 |
|
|
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.
|
|||||||||||
|
25 May 2011, 21:37 |
|
|
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! |
|||
|
31 May 2011, 09:40 |
|
|
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.
|
|||
|
31 May 2011, 15:34 |
|
|
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 ? |
|||
|
01 Jun 2011, 02:13 |
|
|
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. 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 |
|||
|
01 Jun 2011, 03:53 |
|
|
goldenspider 01 Jun 2011, 07:10
[quote="iic2"]
Quote:
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 |
|||
|
01 Jun 2011, 07:10 |
|
|
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. |
|||
|
01 Jun 2011, 22:59 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|