pouët.net

packers/compressors & security & malware & webhosting

category: code [glöplog]
yumeji: if you dont care then dont participate in threads where people are trying to discuss ways to solve it. alcohol forgives all.
added on the 2010-06-14 13:25:39 by psenough psenough
iq: when I registered (a few years back mind, and maybe this was a one-off) I never got any email confirmation at all. No reply to my emails asking what happened too. But I randomly tried to log in some time later, and it worked, the account was all set up!

So I suggest trying to log in now and then while you wait :)
added on the 2010-06-14 14:13:08 by psonice psonice
Wow .. everybody hates me again !! .. the usual case !! ..

Like i wrote in my last post .. there's barely a solution.

The best thing you could possibly do is write a new compressor that doesn't get flagged by AVs and is kept in the scene and used for demoscene stuff only .. thus would atleast kill the aspect of the misuse of compressing real malware.

But i don't see that happen since it's still an executable compressor and as such will always get flagged as a threat since it writes - in AV terms - unpredictable code and executes it and as such is suspicious. There's no way to change that or the things just won't run.

Also there are way to much AVs out there .. to let them all know how the compressor does it's thing and get it whitelisted. They won't do it anyway. So .. Just live with it.

Sorry .. for bothering you. peace.
added on the 2010-06-14 14:51:23 by yumeji yumeji
i still think ryg's idea is great.

it'd be peanuts also to make common demoscene servers (e.g. scene.org) serve "directly executable" and "AV-proof" versions of the same zip, even dynamically. since this problem typically holds for small zips only, unpacking a zip on the fly, byte-patching all exes and re-zipping it shouldn't be that much server overhead. ok well it is, but caching the result also doesn't cost that much web space for the same reason. just disallowing the option for zips over e.g. 1MB solves any cost issues, i guess.

this means ryg's solution could be implemented even without the active support of all/most coders. all we need is an intro-running tool that we all agree upon, and someone to add a patching/repacking tool to common servers.
added on the 2010-06-14 15:12:00 by skrebbel skrebbel
ok, not a tool that we *all* agree upon of course. one that a fair amount of sane active sceners agree upon will do. :-)
added on the 2010-06-14 15:13:07 by skrebbel skrebbel
if we are to make an intro launcher (like the old Ixalance of TBL), would it make sense to make a web-version so we can embed intros in webs? I have something half-running, it can run most of rgba's gl and dx intros.. The ActiveX downloads the ".bin" intro, which is just a raw miniLZO-compressed DLL with the usual init(), config(), doframe() and end() methods. A hwnd was passed from the acftivex to the bin, et voila. The ActiveX could have the pause, resume, ff and fw controls of youtube... Makes any sense?
added on the 2010-06-14 20:10:47 by iq iq
(and I say this after having played with WebGL this Sunday and getting the impression that we are still very far, and will always be, from having real demos in the web thru webgl...)
added on the 2010-06-14 20:11:53 by iq iq
iq: lunaquatic?
added on the 2010-06-14 20:33:01 by xTr1m xTr1m
iq: cool, you've solved the problem of rewinding feedback effects! :D

That aside, sounds like a cool idea. If demos generally get their timing from some common timer, maybe it's possible to replace that to get the time controls? Probably wouldn't work all that often though.

How about security though? Any plugin that can execute code like this has to be handled with extreme caution. Also, activex? IE only?
added on the 2010-06-14 20:57:57 by psonice psonice
Demos on the web? Probably using Google Native Client is the way to go!
Also Google Native Client will suport OpenGL ES 2.0.
However Google Native Client is still in early preview... :(
iq: nice idea! it's very different from an introlauncher in the way ryg proposed, though, and it makes a whole set of extra assumptions. plus, you can remove the createwindow from your code thus get a slightly smaller exe. ryg's idea doesn't change the game.

that said, i think i'd use it. how about developing both?
added on the 2010-06-15 07:32:49 by skrebbel skrebbel
Quote:
Ouch. Good thing the kkrunchy context model is comperatively tiny at about 6MB. :)

Crinkler's hashtable would be about that size as well if it included hash collision detection. But that would take up precious space in the decompressor. Rather make the hashtanle huge to minimize collisions. Memory is plentiful anyway.:)
added on the 2010-06-15 23:15:40 by Blueberry Blueberry
Ok, that explains it. kkrunchy has collision detection and I spent some time making sure the table was as small as I could get it without taking a noticeable hit, since the frequent cache misses with large tables really when you have a couple hundred kilobytes to decompress :)
added on the 2010-06-16 04:35:47 by ryg ryg
btw, anybody has experience with wordpress in untergrund.net? I'm trying to install it (3.0, latest) and I get a message saying that some memory allocations couldn't be performed. Apparently untergrund.net is limited to 12 Megabytes of php memory... Anybody with a workaround or suggestion?

Fatal error: Allowed memory size of 12582912 bytes exhausted (tried to allocate 184320 bytes) in /home/unet_homes/iquilezles/pubhtml/blog/wp-admin/includes/template.php on line 2117
added on the 2010-07-13 06:09:08 by iq iq
I've used Wordpress on Untergrund along with BBPress in untergrund and it worked, it was just unpacking to the folder and following the instructions. Either you're doing it wrong (tm) or it's a problem with newer versions.
added on the 2010-07-13 06:30:21 by xernobyl xernobyl
i jusr did the same i did last 2 times i installed wordpress in other servers - unpack in folder and follow instructions indeed. The DB setup worked fine, the problem happens after that.
added on the 2010-07-13 06:56:09 by iq iq
iq try raising the PHP memory limit from the php.ini file. Not sure if untergrund allows for a local copy to override the settings of the super-ini.
added on the 2010-07-13 06:58:25 by decipher decipher
i didn't find any php.ini, config.php or anything like that. but perhaps indeed i can try to create one and see if it overrides the defaults! thx!
added on the 2010-07-13 07:27:07 by iq iq
php.ini (memory_limit = 32M) nor .htaccess too (php_value memory_limit 32M) seem to work. wp is set to use 32M too (define('WP_MEMORY_LIMIT', '32M'), yet the error message keeps saying the limit is 12M :(
added on the 2010-07-13 07:59:51 by iq iq
well, the php.ini seems to have an effect. But if I add my own php.ini with that memory limit line, then wp complains about some mysql stuff. Seems like more than overriding parameters, the complete ini file was overriden?
added on the 2010-07-13 08:08:43 by iq iq
ok, more info here: http://bw.untergrund.net/

Memory Limit is 12M
added on the 2010-07-13 08:14:36 by iq iq
Currently it says 32M, so I assume you managed to change it; if you can make it 64M Wordpress would install.
added on the 2010-07-13 08:32:50 by decipher decipher
now it complains about MySql or something. I see that untergrund is using php 4.3 and I read that wp3.0 needs 5.x?? hehe, how much i hate computers and it and all.
added on the 2010-07-13 08:41:40 by iq iq

login