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.
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 :)
So I suggest trying to log in now and then while you wait :)
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.
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.
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.
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.
ok, not a tool that we *all* agree upon of course. one that a fair amount of sane active sceners agree upon will do. :-)
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?
(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...)
iq: lunaquatic?
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?
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?
Demos on the web? Probably using Google Native Client is the way to go!
Also Google Native Client will suport OpenGL ES 2.0.
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?
that said, i think i'd use it. how about developing both?
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.:)
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 :)
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
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
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.
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.
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.
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!
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 :(
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?
Currently it says 32M, so I assume you managed to change it; if you can make it 64M Wordpress would install.
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.