Dark Bit Factory & Gravity
GENERAL => Projects => Topic started by: rain_storm on March 19, 2011
-
Heres a gdi based 512b framework I've been working on. I haven't done much header mangling yet but I've marked out most of the feilds that are safe to play with on my system. It would be a great help if some people could test to see if I have already broken the clean version and if the dirty version is too optimistic. If all goes well you should see a greyscale.
Using this framework I hope to be able to release win32 demos on par with the average 128b DOS releases.
Edit 1 - (OLD) Added current version (352 bytes) tested only on XP
Edit 2 - (OLD) Added example of raycasting in 512 bytes
Edit 3 - (OLD) version 347b
Edit 4 - Latest version 295b
-
At first look, it will not run on Windows 64bits ? (I just guessing since I don't have a Windows actually)
Secondly ... can you give information on how to compile ... or maybe you don't want us to reuse it ? :D (I am not use to ASM ... so I guess it's MASM with some option simply)
I will try to test it soon, but I think it's a great job (It has to be great it's ASM :D)
-
Both versions run fine on XP (32 bit).
-
It wont run on Windows 7 64 bit here either which is no surprise to me.
I know that I could run it under dosbox, but you know, I feel that <1kb dos intros are fantastic. With people moving over to systems that have no native support for VGA modes, <1kb dos intros will probably become an even more exclusive art.
Do any of the dos display modes work with 64 bit windows?
-
@Rain: Both .exe's doesn't work here on Windows 7 32 bits, dirty.exe crashes with "invalid win32 application" and "gdi_fw_512b.exe" just load and exit without any error message.
I'm not sure, but maybe you can find some help looking in 1kpack (http://www.pouet.net/prod.php?which=52796)pe fix for win7.
-
I thought I did post it on here but to my surprize....it isnt ....I have to post again....
It wont run on Window 32bit :(....does it mean have to run in old window or dosbox? ???
-
I guess it will run in Windows XP 32 bits (nearly only ... or at least ... only on older thing (did you trash your pentium II ? :D) ... so ... we have to set our Virtual Machines :p
-
I might be taking you guys up wrong but I get the impression that half of you think this is a VGA demo. Its not DOS its a Windows framework using gdi32 to render to a pixel buffer.
To compile you need to use the latest version of FASM. No commandline switches necessary.
When Vista decided to drop all pretences of backwards compatibility with VGA I decided I had to take a new approach at the microscopic categories. This is what I came up with. Software rendering in 512b without the 200 byte overhead that a decompressor requires.
@rbz: Its definately not the DLLCharacteristics I made sure of that, it must be the way the PE and Optional headers are overlapped.
I used the tinype template which was designed to simply get the header as small as possible. Theres plenty of spare bytes to use for code / data but they're spread out all over the place, trying to make use of dead bytes in this headers is like trying to fill a bucket using a thimble. (!practical)
I'm gonna have to take a deeper look at crinklers file header. Its obviously the way to go if you want to use as many of those dead bytes as possible.
Edit : Just found out that on Windows 7 theres an extra loophole to jump through in order to import by hash. But its not even getting that far. So this problem is a 64 bit issue.
-
Works fine on Windows XP Home 32 Bit with NVidia GeForce.
-
Do you think it can be made to work for 64 bit without too much of a file size overhead ?
-
I'm gonna pump Crinkler for the information I need to make this work. Thats one thing you learn from programming 256b dos, reverse engineering such a small prod is a piece of cake. Reversing a 1kb crinkler file header should be no match for me.
-
Okay I managed to get step 1, windows 7 version of get kernel32 image base, done in the first 49 bytes of a crinkler style header. I need to find out if this runs on Vista / Windows 7 before I can make any further progress. Again its a grey scale image that Im hoping you will see.
-
Sorry to report that it won't run on my box (Windows 7 64 bit), both as is and in compatibility mode.
-
@rainstorm:
Dont work on Win7! Afaik retrieving the adress of kernel32.dll dont work under Windows7! For Windows 7 it will give back the adresss of the KernelBase.dll - maybe this helps you to fix your framework for Windows7.
[Edited - added:
I am sure this is something for you:
http://blog.harmonysecurity.com/2009/06/retrieving-kernel32s-base-address.html (http://blog.harmonysecurity.com/2009/06/retrieving-kernel32s-base-address.html)
-
Indeed, it's not working on win7, too bad, I can't help you now, I'm very busy trying to code a destructive intro for dbf compo.
-
@va!n Yeah I caught that one. I'm using the updated version that walks the PEB it's suppose to work on 2K -> Windows 7
Looks like I'm gonna have to beg the brother in law to let me commandeer his PC this week. Just out of interest is anyone getting a "not a valid win32 executable" error? or is it just crashing silently?
-
@rain_storm:
Here at Win7 x64 it crashes and a system requester appears with following detailed infos:
Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: pe_01.exe
Anwendungsversion: 0.0.0.0
Anwendungszeitstempel: 30408b64
Fehlermodulname: pe_01.exe
Fehlermodulversion: 0.0.0.0
Fehlermodulzeitstempel: 30408b64
Ausnahmecode: c0000005
Ausnahmeoffset: 00010014
Betriebsystemversion: 6.1.7601.2.1.0.256.1
Gebietsschema-ID: 1031
Zusatzinformation 1: 0a9e
Zusatzinformation 2: 0a9e372d3b4ad19135b953a78882e789
Zusatzinformation 3: 0a9e
Zusatzinformation 4: 0a9e372d3b4ad19135b953a78882e789
Lesen Sie unsere Datenschutzbestimmungen online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407
Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
C:\Windows\system32\de-DE\erofflps.txt
-
Thanks va!n that means that its executing so the header is getting my foot in the door. I neglected to zero eax.
-
rain_storm
pe_01.exe crashes silently for me on Win7 x64. I've tried it with various compatibility settings and the result is the same.
-
Thanks for testing guys, I've managed to get hold of a 64bit Windows 7 system and tested a few versions.
With a standard header and an import section it works perfect. Then I tried a version that imported by hash with a mangled header... it runs, creates a fullscreen window, All you see is a little white bar across the top of the screen. And it exited cleanly on escape key down. It doesn't bitblit to the screen.
I've seen this symptom before its got to do with either GetClientRect or StretchDIBits. I think I'm getting hash collisions on one of those. If its GetClientRect then I can just use GetWindowRect but otherwise I'm going to have to change my hash meathod.
I hate to ask but if I can get a test of this it would really mean a lot to me.
-
I hate to ask but if I can get a test of this it would really mean a lot to me.
No problem at all, always happy to help. No need to hate to ask :)
And now the good news... It works fine here on Win 7 x64. I get a full screen gradient from black at top of screen down to gray at bottom of screen.
I notice if I move my mouse pointer over the monitor with the gradient, the cursor is the windows "waiting" cursor (the spinning coloured circle one).
If I click the screen, I get a message saying "GetWindowRect.exe" is not responding and do I want to wait or close the program. Not sure if this is anything to do with the packing. I expect not.
Hope this helps rain_storm...
-
Yeah, excellent.
I didn't bother to pump the MessageQueue / ShowCursor(0) to save on bytes. At 512b I think its acceptable behaviour but I am heavily biased having seen many 256b demos that don't even have exit, If I can save enough bytes I might add these back in.
-
I didn't bother to pump the MessageQueue / ShowCursor(0) to save on bytes. At 512b I think its acceptable behaviour but I am heavily biased having seen many 256b demos that don't even have exit, If I can save enough bytes I might add these back in.
Ah, that makes sense now.Would be interested to know just how many bytes those additions add.
-
Works fine now on Win7 x64! Great work!
-
Ah, that makes sense now.Would be interested to know just how many bytes those additions add.
It takes around 50 bytes when the stack has been zero'd (which it has). I'm hoping I can crunch this down by another 100-150 bytes, mostly by hiding stuff inside the header.
I'd much rather spend those bytes on the effect but I'm sure that I can spare enough to at least hide the cursor.
-
I tested it with exactly the same result as Raizor :)
It would be cool to stop that error message but it's great work!
-
Tested it on Window 64bits ... GTX 8800 (but we don't care about GPU, no ?)
So, I got a shaded screen black from white. Hope it is correct.
The cursor and the resolution did not change in the desktop.
The cursor was like searching for something, I have pressed it crashed (windows sending message)
Otherwise, escape key is working :)
So ... I have to say:
Really nice job ! :clap:
-
Added MessagePump and hidden cursor so that problem should be fixed. the code is only 471 bytes but I have to pad it out with zeros to 513 bytes, still haven't gotten round to correctly calculating the required parameters in the header.
Edit : check first post for latest version which is no longer padded
-
Yep, looks and works great now rain_storm. No cursor anymore.
Looking forward to seeing what you do with this next :)
-
Good to hear, Trying to support multiple versions of Windows at this size limit is much like Programming Punched Cards (http://www.columbia.edu/acis/history/fisk.pdf) in a way. I still need to cunch some bytes before this is truely useable though.
-
471b downloaded and works fine, thanks. Lovely to see some tiny coding running on a Windows 7 computer.
-
Thanks for sharing your work rain_storm.
I know this is an old thread, but wanted to ask you if the "Edit 3 - Latest version 347b" attachment of 1st post is an update of the compatible 471-byte version that everybody tested from xp to win7-32bit to win7-64bit ? ie: is 471 bytes the lowest footprint for compatibility ?
Thank you in advance and congratulations again.
-
The versions above were the product of an incremental improvement. I crunched things as far as I could, but sometimes I would start fresh and by taking a different route from the start I managed to shave additional bytes. The latest version is 295 bytes and compatible with XP, Vista, 7 and 8. But the latest version is not ( or at least should not be ) NX bit safe.
Check the first post to grab a copy of the 295 byte version.
In the source code you will find a bitfield that disects tinype at a bit level. It states explicity which bits must be 0, must be 1 or can be toggled freely ( within limits ). This bitfield was built up using a program I wrote that toggled each bit and loaded the resultant image with CreateProcess then tested for errors during CreateProcess or errors in the return value. Then I ran this program on as many PC's as I had access to which included multiple XP systems, one Vista box, multiple Windows 7 systems and just one Windows 8 system.
This bitfield was what I started from when I built the 295 byte version.