73 replies to this topic

[Wonko the Sane]

Based on the provided answer on 2, it is evident that the solution is OS version dependent. It may work on different versions, but must be considered as luck if it does. Have you tried modifying the imports directory to change over to names?

I never claimed that it should work on *any* OS version, and of course if a different OS have functions under different Ordinal number, it's just a matter of changing the Ordinal that is different, as you already pointed out.

 

I will repeat how the scope of this challenge is not to make something that works on *anything* or that is "proper", "elegant" or *whatever else* (if it does it is a plus, of course, and yes "luck" is a perfectly acceptable component of the solution) the scope is only to create the smallest 32 bit PE capable of doing that on the given OS.

Of course using names instead of ordinals requires "more bytes".

 

Wonko

[joakim]

I never claimed that it should work on *any* OS version, and of course if a different OS have functions under different Ordinal number, it's just a matter of changing the Ordinal that is different, as you already pointed out.

 

I will repeat how the scope of this challenge is not to make something that works on *anything* or that is "proper", "elegant" or *whatever else* (if it does it is a plus, of course, and yes "luck" is a perfectly acceptable component of the solution) the scope is only to create the smallest 32 bit PE capable of doing that on the given OS.

Of course using names instead of ordinals requires "more bytes".

 

Wonko

I interpret that to contradict with requirement 3 in first post:

3.the program should run on *any* Windows XP regardless of SP level

Which I believe can't be achieved by using ordinals (since they may vary from one version to another).

[Wonko the Sane]

OK.

 

Let's rephrase  this to "ONLY XP and ONLY SP2", with the possibility of - by merely changing - (if needed) - the different Ordinal involved to adapt the solution to other SP levels (still on XP) and/or to other NT based versions.

 

And add a new rule to the challenge (in order to simplify the matter and put an end to this kind of nit-picking )  :

• executable using external functions and calling them by Name and not by Ordinal will be automatically deemed NOT acceptable, i.e. it is compulsory, if your PE calls external function(s), that function(s) is/are called by Ordinal and NOT by Name.

 

This way it will be easier.

Rules amended with even more detail.

 

Wonko

[joakim]

OK, fair enough, but I'm not happy with the "new" rules, as the executables get targeted at specific OS version. So the smallest size so far is at 228 bytes?

[joakim]

208 bytes: http://www.mediafire...x7tkgepdi9gta29

 

Though I may get disqualified for not conforming to the rules as my import uses name and not ordinal

 

However, the drawback is that the same executable thus likely works on any nt5.x without modification, saving you from keeping track of ordinals.

 

If you want to debug it, put in 0xCC at offset 0xC, which is an int3 that your jit debugger can break on.

[joakim]

192 bytes: http://www.mediafire...13b9velfo0fb525

 

and likely my final contribution. If you want ordinals, fix it yourself. I don't like the idea.

[Wonko the Sane]

192 bytes: http://www.mediafire...13b9velfo0fb525

 

and likely my final contribution. If you want ordinals, fix it yourself. I don't like the idea.

Well, it was for "your" benefit .

Now anyone can take your 192 bytes solution , change the import method from Name to Ordinal and win the challenge.

I guess that proving plagiarism on such small snippets will be tough.

As said I will readily change again the Rules to allow your "names" solution to be allowed.

But, to be fair, we must introduce a change in the points attributed, to give to your solution an advantage:

P=512-L+D-d

Where D is final day for submission and d is the day of actual submission.

Joakim has currently 512-192+31-2=319 points.

 

EDIT: 

The only issue is that it doesn't work on my machine.

Testing procedure:

Rename the file to osk.exe

replace the osk.exe in C:\Windows\System32

switch to to Wista0\Winlogon (Switch users)

Win+U

From Utilman call the osk

 

OR:

 

Rename the file to utilman.exe

replace the utilman.exe in C:\Windows\System32

switch to to Wista0\Winlogon (Switch users)

Win+U

 

NOTHING happens.

Wonko

[joakim]

Hmm I tried reproducing it in a vm, but I can't and I'm getting fed up of XP. Did you by any chance use CreateProcessA instead of WinExec?

[Wonko the Sane]

Hmm I tried reproducing it in a vm, but I can't and I'm getting fed up of XP. Did you by any chance use CreateProcessA instead of WinExec?

Sure, in my "solution" I used CreateProcessA, because that's what is in the "base" code and that allows to "choose" between winsta0\Default and winsta0\Winlogon.

Your "192" .exe does work "normally" on the standard desktop of course, but it seems like not on the Winlogon one.

 

BTW it is well possible which is a peculiar issue with my install, though I do not believe it.

I also tried the "first" version you posted, the 400 bytes one, (which it seems like using CreateProcessA, but that is seemingly set to "Winsta0\Default".

 

Wonko

 

 

P.S.: I just tried again, starting the 192 app in a slightly different way, and now I manage to get on the Winlogon an error 0x0c0000142, so it is very possible that it is this machine that "saturates" the heap space, I'll do more tests .

[joakim]

Actually WinExec is uselesss when switching window stations. I forgot about that in the hurry of creating the "almost smallest executable". So no need to test it. CreateProcess seems like the way to go. Other CreateProcess* functions are better suited when more fuzz is required. Thus it is also apparent that more bytes are required in order to get CreateProcess going rather than WinExec.

[Icecube]

P.S.: I just tried again, starting the 192 app in a slightly different way, and now I manage to get on the Winlogon an error 0x0c0000142, so it is very possible that it is this machine that "saturates" the heap space, I'll do more tests .

I think I also got the 0x0c0000142 error when just running the original source code on Windows 7, with this fix of course:

Replaced:

LPTSTR szDesktop = _tcsdup(TEXT("WinSta0\\\\Winlogon"));

with:

LPTSTR szDesktop = _tcsdup(TEXT("WinSta0\\Winlogon"));

When changing the text to "WinSta0\\default", there was no crash.

Replacing ultiman.exe on Windows 7 doesn't seem to be that easy because only "Trusted Installer" seems to have rights to modify/update some file, so I didn't try that yet.

[Wonko the Sane]

Yes, but there must be still be something queer on the install I am running, I could swear that yesterday the 192 byte version did "nothing", and today I managed to get a 0x0c0000142 error, and even "my" builds do this now (if I use cmd.exe as "target").

I have "alternative builds creating a new process with "rundll32.exe shell32.dll,#61" instead of cmd.exe that work (but that can run on the Winlogon desktop - say - freecell.exe but not cmd.exe).

I remember having this same issue at the time I did the first tests, I did find the issue and solved it, and it was connected to the cmd.exe requiring too much resources, but for the life of me I cannot remember which specific changes I made to have it working.

 

Wonko

[joakim]

119 bytes: http://www.mediafire...qoksng08oxoddq5

 

But I have to admit I was wrong on several points, and still am probably. Specifically, WinExec being useless, the swapping of window stations (your all the time at Winsta0, but its the desktop that change). WinExec works fine on nt6.x, and you are all the time in the same user session (though in different desktop (default <-> winlogon)). Therefore CreateProcess is a huge waste of bytes if minimal size is the goal and nt6.x is target OS. Worth noting is that such minimal PE's don't work on nt6.x as they are detected as 16-bit, and launched through ntvdm.. Not exactly sure what causes it, but may be several things about the header. As for n5.x, I am having problems verifying what works and not, because I can not even get any winlogon trick to work. So Wonko's installation is probably not the only one screwed, unless it's the crappy OS.

 

Regarding the 119 byte exe, it obviously don't have any imports. In fact the whole data dir is removed, as is parts of the optional header. The actual code is spread inside the optional header, and the address of WinExec is hardcoded, meaning it likely must be changed when used on a different service pack, or something. If so then offset 0x73 contains the target dword. Inside the download is a simpel program to retrieve the address. Also, if a clean exit is not important, then another 3 bytes can be shaved off, by overwriting the 3 bytes starting at 0x70 (xor'ing eax and ret) by moving the WinExec offset forward 3 bytes and deleting the last 3. Maybe it is also possible to save a couple more by carefully reallocating the code across the optional header, but did not try too hard on that.

 

So if it works or not on XP is hard to say. At least WinExec should work from Winlogon, and the collapsed PE works on the nt5.x platform.

 

Edit: And you can still debug it by injecting CC at offset 0xC.

[Wonko the Sane]

But it is not anymore a PE? Or it is?

 

I mean, if you open the .exe in (say) CFF explorer:

http://www.ntcore.com/exsuite.php

 

it is  still recognized as a "valid" PE, though the "Data Directories" are invalid, this may be the reason why it "switches" (if I understand correctly) to using the NTVDM.

 

I have had no time to recheck my environment/find the reason of the 0x0c0000142 error (or re-make a suitable VM), in any case I am attaching "my" earlier "solution" (NASM .asm - now "set" to "default", change to "winlogon") , please check if it works in your environment (and on NT6.x).

 

If I recall correctly some of my earlier experiments, on XP Winexec does not work on the "Winlogon" desktop (but it is well possible that I am mistaken on this, and something else made me abandon the "simpler" Winexec approach).

 

Wonko

Attached Files

•  OSKW228.7z   1005bytes   2 downloads

[joakim]

It is still a valid PE as far as XP is concerned, because otherwise double clicking it within XP would cause it to fail. I guess nt6.x (or Windows 7, did not test Vista), introduced more checks to a PE before loading it. The data directory is just 1 one thing, out of many. The main reason for failing on Windows 7 seems to be the collapsed/merged headers, which causes it to believe it ineeds ntvdm.

[Wonko the Sane]

I managed (though I am not sure what exactly fixed it) to fix the OS to avoid the 0x0c0000142.

 

I used the attached "plain" (and rather biggish being set at 512 bytes ) oskw_rundll.exe, invoked from powerprompt as a "loader" on the Winlogon desktop and from it tested all of Joakim's solutions.

ALL worked BUT the 119 bytes one.

 

This confirms that Winexec does work when you are already on the Winlogon desktop and that thus there is seemingly no "real need" for CreateProcess (thuough this allows, while on the Default desktop to launch an app on the Winlogon one, as long as you have System privileges).

 

The 119 bytes one simply dosn't work, in the sense that it shows nothing  takes 50% CPU (which might mean that also on XP somehow the NTVDM is involved, as often the NTVDM hogs the CPU and starts eating memory ).

 

It is still however possible that my environment is not "fixed enough" .

 

Wonko

Attached Files

•  oskw_rundll.7z   1.34KB   6 downloads

[joakim]

The 119 bytes one simply dosn't work, in the sense that it shows nothing  takes 50% CPU (which might mean that also on XP somehow the NTVDM is involved, as often the NTVDM hogs the CPU and starts eating memory ).

 

Are you sure you updated the memory address located at 0x73 with your values? The values in the exe are correct for my xp sp 2 vm. Yours may be different.

 

The download seems unavailable btw.

[Wonko the Sane]

Are you sure you updated the memory address located at 0x73 with your values? The values in the exe are correct for my xp sp 2 vm. Yours may be different.
 
The download seems unavailable btw.

What memory address? How/why should it be "updated"?

Which download?

I continued a bit on the "plainer" Winexec that I had abandoned (very similar to your 192 bytes) and I managed to shave off 20 bytes (it is now 172 bytes - with access by "name").


Wonko

Attached Files

•  oskw172.7z   244bytes   4 downloads

[joakim]

What memory address? How/why should it be "updated"?

Which download?
 

The memory address inside the 119 byte version, that you reported failing. You will need to get it with the tool included in the download, and then update the exe at the mentioned offset with the shellcode formatted output (big endian). It's about as complicated as keeping track of ordinals I thought with the bonus of getting to remove all imports, as well as the whole data directory. Actually we are just left with a minimal loader for any given shellcode.. If the location of WinExec is different on your system, and you did not update the exe, then the reserved memory would for sure be corrupted.

 

I meant the download attached to your post, which I could not reach.

[joakim]

Your download was flagged as virus.

[joakim]

97 bytes: http://www.mediafire...5jh93ig9k63ex61

 

as is already stated to be the absolute minimum possible size of a pe; http://www.phreedom....esearch/tinype/

[joakim]

Here's a 97 byte equivalent of the 133 byte webdav sample: http://www.mediafire...v124ghf9ai6bmlu

[Wonko the Sane]

Joakim, I am now lost.

WHICH download you could not reach? (please refer to it by the filename or by the post #)
WHICH download is flagged as a virus? (as above)
Do you want me to post just the corresponding .asm?


Wonko

[joakim]

Those flagged are:

• oskw172.7z
• oskw_rundll.7z

 

No need for the source.

[Wonko the Sane]

Those flagged are:

• oskw172.7z
• oskw_rundll.7z

 

No need for the source.

Well I was kinda expecting you would test them on non-Windows XP, if they were flagged as virus did you get them nonetheless?

 

It seems that only Antivir and MalwareBytes don't like oskw_rundll.7z (and TrendMicro-HouseCall. but that doesn't count ):

https://www.virustot...sis/1377273072/

On the other hand it seems that only TrendMicro and TrendMicro-HouseCall do not like oskw172.7z, but BOTH don't count )

 

BTW also MyCmd_97b.zip is "flagged" by reputable antivirus such as CAT-QuickHeal and Ikarus :

https://www.virustot...sis/1377273530/

 

97b_tweaked.zip is also flagged by CAT-QuickHeal and TrendMicro (which still doesn't count )

https://www.virustot...sis/1377273854/

 

Wonko