背景
昔々、古いサイトが1つありました。 両親は彼を拒否し、存在の2番目の10年で、彼は私たちのところに来ました。 これは、フォルダーに散らばったPHPコードのジャングルでした。 これはすべて、異なる松葉杖
パターンを使用して、異なるエンコーディング(同じファイル内で最大3つのエンコーディング)で異なるタイミングで記述されました。 MVCは、おそらく、まだ知られておらず、開発者はテンプレートエンジンについて聞いていなかったので、突然に驚かないでください。
<? if (cond) { ?>
HTMLマークアップで。 権利のエキサイティングな検索に1時間以上費やしました
<? } ?>
開発者はバックアップを忘れていませんでした。ルートにはindex.php、index_old.php、index.php.bakがあります。 しかし、何であれ、この奇跡はうまくいきました。 そして、何が機能するかに触れないでください。
ネクタイ
この話は、12月の晴れた朝、プロモーションの専門家がフッターに外国のサイトへのリンクを見つけて驚いたときに始まりました。 少し掘り下げると、2つのことが明らかになりました。
- これは鼻landです。
- 顧客は当惑しています。
お客様の困惑を理解することができます:彼はこれらのリンクを見ません。
調査
彼らはタスクを設定します-見つけ、整理し、破壊します。 含まれているPHPファイルの
HTMLマークアップで目的の場所を見つけると、誰かに役立つ関数の名前がわかりました。 〜60kコードファイルの検索結果は肯定的な結果をもたらしませんでした-そのような機能はどこにも発表されていません。 目的のエントリポイントで接続されているすべてのファイルの列挙が使用されました。 その過程で、目は次のようにファイルにしがみつきます。

何も明確ではありませんが、ヘッダーの注釈を削除しなかった人に心から感謝します。 私は `` Zend Optimizer ''をグーグルで検索し始めており、このゴミの復号化につながると確信しています。 動作中のデコーダの検索は
ここで終了し
ます 。 キャプチャに特に満足しています:

結果のコピーの禁止に関連するいくつかのsomeで、私は次のようになりました:
複雑な正規表現には不信感がありますが、ここでは完全に消滅しています。
preg_replace()の仕組みを覚え始めています。 そして、私が読むほど、私はより困惑します。 正規表現自体は、最初のパラメーターと、2番目のパラメーターで置き換えられる必要があります。 与えられたものをもう一度見ました。 文字列
「x」が
「#x#e」をその長いピースに置き換えられます。 さらに、
preg_replace()関数は
xおよびe修飾子を使用します。 しかし、自分自身を混同しないようにしましょう。
#の間に置かれているものはすべてエスケープされるため、実際には
xは行
「x」で置き換えられるべきものです。 それだけです
。e修飾子を使用すると、結果の式をPHPコードとして実行できます。 置換文字列をよく見ると、ほとんどがノイズであることがわかります。

コメントを削除すると、判明します
@eval(base64_decode($I0));
この時点で
、関数を呼び出す前に「@」値をグーグルで検索
する必要がありました。 次に、
オンラインデコーダーのおかげで、パズルの次のバッチを手に入れました。

ここで、最初に
chr()関数を見ました。 やった
$ll = @explode(chr(187) , @implode('', @array_map('trim', @file($ll))));
Googled
array_map() 。 一般に、Zend Optimizerによって暗号化された同じ元のファイルの一部がここで使用されます。 どのようなアルゴリズムがあるのかはわかりませんが、文字を再配置して
base64_decode()を既に使い慣れたものにした後、暗号関数を取得しました。

さらに、comは指数関数的に成長し始め、数回繰り返した後、ファイルは2k行に達しました。 このすべての調査の後、私は明日のためにファイル構造を残しましたが、今のところいくつかの楽しみがあります:

内部サブネットの端末から気付かれることなく移動できます。

興味深いことに、彼らはそこですぐにそのような暗号化を行いますか、それとも誰かがすでに私たちの専門家を試しましたか?
あとがきの代わりに
ファイルを作成するのにかかった時間を信じているなら、それは庭での2009年の過酷なものでした。 結局、Zend Optimizerについての注釈だけが残っていなければ、これはすべて不可能だったでしょう。