I recently found on my WP installation a plugin.php inside plugins that was executed and fortunately returned some errors.
The files begin with:
<?php
/**
* Author: plugin
* License: GPL v2 or later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
* Plugin Name: Plugin
* Requires PHP: 5.4
* Requires at least: 5.0
* Text Domain: plugin
* Version: 1.0
*/
if ( ! defined( 'ABSPATH' ) ) {
exit();
}
#¾êºÐý½s4+{œîÇê7ÀTG4î8TlŸþ§àU,åœàJ›ÒK.-èÒÃåbÀ¢žÇŒ±¤ùâÕDÑ!ò¡,÷YÛIŠ:£‘%½DF¶…àõzejXhøÑ_Ó—'þ6wNƆŽh•ÙB¾kn5J¥ðëÒˆ+1eÀ\¶xVÎïFÃã—aÊŨ±WAÄ®€>©áBPìXÄW1£#A3æ|ˆé§‚‰À°j„øÈUʶ„k'ÕüÒ¿.é¾}¾4óÍz„ßœønœâé.6Z"vz¦_ÅÕ+—Z7‹ ÷Ó†Étͣ˛⩋wÓ"=£h6íÞéBB /*%0ÕH‘%0.4‡?.ňuÀÀƒDFÌ!úé•6!ßNnRüôÅ•þÞÊNº.$H‘óÏ¿†y•³!Š7àx»Ñ´<ö~Þ|l}ì1²G'RÖº¤mQr»Ÿ3êßUëü•ùÑ#à»Yt²¼42ŽOy4z·–ïÄ‹^«î {ýFVD5¬ˆ_$7çyV8>í¹µÒ7OòžN’…3O¢àÐåF×ß~ÉÅù¿€IØälpŽwÝÌ7\ Š¿#CÜ¡•KßnÚV‚Å9äq˜ÞynˆßÿKEIk¯nÆ•RÄŒn1e16;L5›ËÍYð5g˜œ*/
and continues. I suspect there is HEX + eval + gzip involved here.
What can I do to know what this file is doing?
Here is a link to the complete file
https://pastebin.com/redDEFJM
I tried some online tools, but got no hints
Can you confirm that if you download your PasteBin file it matches the exact file you found? Once the comments are stripped out, the code does seem to: assemble an array of strings; concatenate the strings together; attempt to uncompress the result using gzinflate; and then would eval the result if the gzinflate was not failing due to invalid data.
There are a number of special characters in the original strings, so I'm wondering if either the copy-and-paste to PasteBin, the rendering PasteBin gives, or the download I'm doing from there is making a small change that is breaking the compressed stream.
I'm going to keep looking at it too, but here's some ideas for dealing with the obfuscation:
strip the comments out - I used a lazy regex of /\*.*?\*/
you end up (in the obfuscated bit) with three statements
an assignment to an array of 252 items
an assignment to a new single-value array of the last item (which is just 'gzinflate')
eval of the output of running 'gzinflate' on the concatenation of the remaining array items
so you could just take the first statement to form the array, then concatenate the entries as done in the last statement
this would then be able to be passed to gzinflate, and the output should give you the code it is trying to execute
Related
PHP has a function called get_meta_tags which can read meta tags of HTML files. However, as far as I know there is no standard way to define meta tags for PHP files. The de facto solution seems to be to add comment to the top of the file like so:
<?php
# Author: Ood
# Description: Hello World
?>
Is there any way to read these "meta tags" with PHP similar to the way get_meta_tags works using the default PHP library? Preferably without parsing the entire file with file_get_contents followed by a regex for best performance. If not, maybe someone knows of a better solution to add meta data capabilities to PHP files. Thanks in advance!
In our project we are happy with the standard JavaDoc that was adopted by PHPDoc using the #field syntax as you might know it from any PHP function or class definition. This is pretty fine readable using the PHPDocumenter.
In our adoption we use the very first multi-line comment, ie anyting between /** and closing tag */, using the JavaDoc style to describe all the details about the current script.
So to adopt your example in our project we would have following syntax:
<?php
/**
* #author Ood
* #desc Hello World
*/
Of course you may end up with your custom function reading the beginning of the php file parsing just the very first multi-line comment to get the script description aka meta tags.
I have a config file where I store all my strings for easy reference and to make translation easier - just in case I ever need to roll out my application into one of our international locations.
I would like to remove my hardcoded strings from both HTML and PHP code.
This site shows that IntelliJ IDEA is capable of highlighting hardcoded strings. However, I see no such option in my PhpStorm 2017.2 installation.
This is one example in HTML that I'd like to purge and replace with non-hardcoded strings:
<thead>
<tr>
<th class="text-center">#</th>
<th>Benutzername</th>
<th>Nachname</th>
<th>Vorname</th>
<th>E-Mail</th>
<th>Rollen</th>
<th></th>
</tr>
</thead>
However, PhpStorm does not highlight the hardcoded strings or suggests any fix. Same goes for PHP code.
If it's of any interest, here's how I usually retrieve strings from my config array.
/**
* Extract a string from the config file depending on its tag.
*
* #param string $tag The string to extract.
*
* #return mixed The string that was extracted. At least it should usually be a string, but it could also be
* something different, depending on the config.
*/
function get_string($tag)
{
// Check the config file first.
global $config;
$string = $config['strings'][$tag];
if (!isset($string)) {
// The faulty tag can be found in the logfile.
logfile("String Tag not found: " . $tag);
$string = $tag;
}
return $string;
}
I simply give the array index to the function and retrieve the string from the config array. If I ever need internationalisation, I can modify this function.
You can use 'cmd + f' and search for >[a-z0-9] which does a decent job finding any instances where an HTML tag ends and a string begins
#axiac provided a different point of view.
HTML is in itself basically full of hardcoded strings - tags et cetera.
PHP requires many strings to work. $_GET[], $_POST[] and array indices like my $config['strings'][$tag] are a few examples.
If PhpStorm were to highlight all of these strings, all of them would have to be excluded from inspection manually.
As #axiac said:
You can use the "Find in Files" command to find the strings in the PHP
scripts (search for ['"] and check "RegExp") but you'll probably be
overwhelmed by the big number of strings, many of them being array
keys or other strings (separators, SQL queries) that are part of the
code, not of the output.
I have a form with an input name="title" and in functions.php I'm simply getting all the data from that form
Here's the code:
$title = $_POST['title'];
print_r($_POST);
var_dump($title);
var_dump(esc_attr($title));
The expected outcome would be the same string, but, I have no idea why, WordPress shows an empty string on the esc_attr one
Here's the output:
Array ( [title] => Swedish House Mafia – Doooon\'t You Worry Child ft. John Martin )
string(63) "Swedish House Mafia – Doooon\'t You Worry Child ft. John Martin"
string(0) ""
It's not related to the input field being called title or the variable being called $title and conflicting with other stuff in WordPress, I have no idea why the escape functions are not working.
Let's walk through the thought process of what might be a contributor to this problem.
With the code as presented, nothing in your code is affecting the variable or $_POST. You are just echoing out each variable one after the other (as you presented above).
That means something is wonky with esc_attr. What could the possibilities be:
The function is not available yet.
Something is overriding the returned value and behavior.
Possibility 1 is not feasible because you are working in the theme's function.php file. WordPress has loaded the escaping functions by the time the theme is called. To check that, you can do:
echo function_exists( 'esc_attr' ) ? 'yes, loaded' : 'whoops, not loaded';
That leaves us with Possibility 2. Let's look at the function in WordPress Core.
function esc_attr( $text ) {
$safe_text = wp_check_invalid_utf8( $text );
$safe_text = _wp_specialchars( $safe_text, ENT_QUOTES );
/**
* Filters a string cleaned and escaped for output in an HTML attribute.
*
* Text passed to esc_attr() is stripped of invalid or special characters
* before output.
*
* #since 2.0.6
*
* #param string $safe_text The text after it has been escaped.
* #param string $text The text prior to being escaped.
*/
return apply_filters( 'attribute_escape', $safe_text, $text );
}
There are 3 functions that interact with the text. I don't see anything in the first two. However, look at the filter event attribute_escape. Any other plugin or theme can register to that event and change the returned text, including returning an empty string.
That sounds like a highly probable candidate.
Next Steps
Something is stepping on (filtering) the text when it's passed through esc_attr(). You need to eliminate all variables, strip the site down to the bare bones basics, and then see if the problem resolves itself.
The following steps are a process to discover where the problem lies. It's an elimination methodology. As you walk through it, it'll help you to pinpoint what component (theme, plugin, or even core) is affecting it.
Step 1: Deactive ALL plugins
Step 2: Move your code to the top of the theme's functions.php file. Why? It eliminates anything in the theme from affecting the text as the functions.php file loads first.
Step 3: Manually add the title to $_POST['title']. Put as the first line in functions.php: $_POST['title'] = "Swedish House Mafia – Doooon't You Worry Child ft. John Martin";.
Step 4: Refresh the browser.
Is it working properly, meaning esc_attr() returns the string?
Nope, the problem is still happening.
Hum, that means something then in WordPress Core is not playing nice. You could investigate by digging into Core and finding what is causing the conflict. Or reload a fresh version of it.
Yes, the problem is gone
Add in one plugin at a time. Refresh the browser. Check if the problem reappears. If yes, then you found the plugin that is causing it.
Now what?
Once you find the culprit, you can take steps to fix the problem. Then you can remove the code from functions.php file that I had you add.
This might be edge case, but I had the same issue and the problem was with multibyte characters.
My code looked something like this: esc_attr( substr( $desc, 0, 152 ) )
Without esc_attr() it worked but I sometimes got the �-character. When running it through esc_attr() I got nothing back.
So my solution was to replace substr() with mb_substr(). Read about the difference in this answer.
Retrieve data with this code
echo esc_attr( $title );
Sometimes in my code I like to comment out a block of code for temporary use/reference etc eg:
/*
blah
*/
But it's a minor annoyance that if I then want to go and insert a line inside that block, when I click enter, it will automatically put a * on the next line as though I were doing a DocBlock. This happens on every enter key:
/*
blah<enter pressed here>
*
*/
Now I would have thought this 'auto-formatting' should only take place if the opening comment is using the format /** (two stars). Multi line comments were around a long time before DocBlocks, so I'm not sure why it forces these "old school" standard straight forward /* */ comments to have fancy unwanted extra DocBlock *'s!
So is there a way to:
a) Ideally - only have that formatting take place if the opening tag is /**
b) Or if it can't differentiate between /* and /**, is there a way to disable the auto-comment-formatting entirely?
Cheers
I ended up entering this as a Netbeans bug in their Bugzilla and they have now fixed the issue. They did this VERY Quickly I should add - within 12 hours - kudos to them. From what I can make out it looks like it will be included in Netbeans 7.4 release. Gotta love Open Source! :)
Job details here:
https://netbeans.org/bugzilla/show_bug.cgi?id=230814
select your code and press ctrl+? It will comment with double all lines selected
I am trying to write a PHPDoc description and as soon as I type a dot (.) it just cuts the rest of the description in the code assistant. For example,
/**
* A boolean value indicating whether code assitant worked with dots in PHPDoc.
* As you can see, it did not work!
* #var bool
*/
public $var = false;
I only see the first line in the code assistant. How would I solve this problem?
I haven't had any luck using the Short Description and Long Description in Eclipse (Helios) - even though it should be supported.
An option if you want to increase the length of your short description is to use the <br> tag. As long as you don't include a period in your short description, you can span it over multiple lines. You can even use other tags to add a bullet list if you like.
/**
* Function to take a 10 digit phone number and<br>
* return it in North American standard format of:<br>
* <ul><li>(123) 456-7890</li></ul>
*
* #param int $phone <ul><li>up to 10 digit int for the phone number</li></ul>
* #return string <ul><li>formatted phone number</li></ul>
*/
Eclipse Helios supports most (if not all) of the DocBlock format tags listed on this web page.
phpDocumentor Tutorial: DocBlock Description Details
However, not all these tags work in all instances, and there are definitely examples in other sections of this page that do NOT work. But using these techniques can definitely make your phpDoc blocks look better.
It is likely that the code assistant logic expects that docblock descriptions exist in the "one sentence summary description, followed by a longer detailed description", and most likely only shows the summary description in popups. In Eclipse, you can tab into the code assistant popup, and the information in there expands to show everything (via scrollbars).
UPDATE:
Testing KingCrunch's exact layout of (short description to a period, blank like, additional description with/without a period, blank line, tags) in Eclipse PDT on Helios shows that the period in the first sentence does indeed prevent the popup from showing any of the description beyond the period. I even moved the secondary portion onto the same line with the first portion, and everything beyond the period still does not appear. Change it to a comma, and everything up to the next period will then appear. Well, unless there's a blank line between the comma'd line and the next line... in that case, the blank line has the same effect as a period would, blocking everything after it. I see no issue with the tags being seen and interpreted, regardless of whether or not the description pieces are visible.
I believe, therefore, that Eclipse is indeed ignoring all description beyond the first period and/or blank line that it encounters. I'm unaware of a way to disable this behavior.
ashnazg is almost right. Usually there is the "short summary". You have no empty line after that, so it assumes, that the whole block (including the tags) belongs to the summary and are cut down after the first full stop (because its a short summary ;))
Newlines after the short summary and before the tags should work.
/**
* A boolean value indicating whether code assitant worked with dots in PHPDoc.
*
* Should work ;)
*
* #var bool
*/
public $var = false;
I've found that you can display multiple sentences if you put an HTML-encoded space character (" ") after the period. For example:
/**
* Sentence One. Sentence Two.
*/
However, if you want to include line breaks in your PHPDoc comment to make it easier to read from the source code, it will only allow up to three lines. If you include any more, only the first line will be displayed. This makes complete sense because you will never ever need more than three lines. For example:
/**
* Line one.
* Line two. Another line two sentence.
* Line three.
* This fourth line being here will prevent lines 2, 3, and 4, from being displayed.
*/
Thanks for posting this question. I've been wondering if I installed PDE wrong or something.