-4

暗号化された GET パラメータを使用する Web ベースのシステムがあります。どの暗号化が使用されているかを把握し、それを再作成するための PHP 関数を作成する必要があります。何か案は？

URL の例: ...&watermark=ISpQICAK&width=IypcOysK&height=IypcLykK&...

4

2 に答える 2

8

エンコードに使用されたアルファベットでさえ確実に推測するのに十分なサンプル データが提供されていません。

あなたが提供した3つのサンプル値から、私が言えることは次のとおりです。

  • データには非常に多くの冗長性があります — たとえばと を比較してください(さらに、それは単なる偶然かもしれませんが)。これは、データがランダムでも安全に暗号化されていないことを示唆しています (ランダムに見えるようになります)。width=IypcOysKheight=IypcLykKwatermark=ISpQICAK

  • Aアルファベットには、 toSとctoのかなり広い範囲の大文字と小文字が含まれていますy。アルファベットが連続した文字範囲で構成されていると仮定すると、42 から 52 の可能な文字のパレットを意味します。もちろん、他の文字も使用されている可能性があるかどうかをサンプルから確実に判断することはできないため、Base64 を完全に除外することはできません。

  • これは、私が最初に推測したように、 PHP の関数の出力ではありませんbase_convert。この関数は 36 までの塩基のみを処理し、大文字を出力しません。

ただし、それはほぼすべてです。理想的には、それらが対応するプレーンテキスト値を使用して、さらにいくつかのデータ サンプルを確認すると役立ちます。

編集：idコメントで指定したパラメーターは、間違いなくBase64です。特徴的な末尾=記号に加えて、どちらも 9 つの印刷可能な ASCII 文字の単純な文字列にデコードされ、その後に改行 (hex 0A) が続きます。

_Base64___________Hex____________________________ASCII_____
JiJQPjNfT0MtCg==  26 22 50 3e 33 5f 4f 43 2d 0a  &"P>3_OC-.
JikwPClUPENICg==  26 29 30 3c 29 54 3c 43 48 0a  &)0<)T<CH.

(上記の ASCII 列で、印刷できない文字を a に置き換えました.。) 他のすべてのパラメーターも Base64 であると仮定して、それらが何にデコードされるかを見てみましょう。

_Base64___Hex________________ASCII_
ISpQICAK  21 2a 50 20 20 0a  !*P  .
IypcOysK  23 2a 5c 3b 2b 0a  #*\;+.
IypcLykK  23 2a 5c 2f 29 0a  #*\/).

ISNAICAK  21 23 40 20 20 0a  !#@  .
IyNAPjIK  23 23 40 3e 32 0a  ##@>2.
IyNAKjAK  23 23 40 2a 30 0a  ##@*0.

ISggICAK  21 28 20 20 20 0a  !(   .
IikwICAK  22 29 30 20 20 0a  ")0  .
IilAPCAK  22 29 40 3c 20 0a  ")@< .

したがって、別のエンコーディング レイヤーが関与していることは間違いありませんが、すでにいくつかのパターンを確認できます。

  • デコードされたすべての値は、一定数の印刷可能な ASCII 文字とそれに続く改行文字で構成されます。これは偶然ではありません。

  • ほとんどの文字は、印刷可能な ASCII 範囲 (hex 20– 7E) の下限にあります。特に、印刷可能な最小の ASCII 文字である space = hex20は、特にwatermark文字列でよく使用されます。

  • 各 URL の文字列は、他の URL の対応する文字列よりも、互いに似ています。(ただし、URL 間にも類似点があります。たとえば、デコードされた値はすべて= hexwatermarkで始まります。)!21

実際、任意の文字列に出現する最大の番号付き文字は_= hex5Fであり、最小 (改行を除く) は space = hex20です。それらの違いは、16 進数3F= 10 進数の 63 です。偶然ですか? ないと思います。2 番目のエンコーディング層はuuencodingに似ていると思います: データは (Base64 のように) 6 ビットのグループに分割され、各グループは 16 進数を追加するだけで ASCII 文字にマップされ20ます。

実際、2 番目の層はuuencoding である可能性があるように見えます。各文字列の最初のバイトには、uuencode の長さの指標となる正しい値があります。それらをデコードしようとすると、何が得られるか見てみましょう。

_Base64___________UUEnc______Hex________________ASCII___re-UUE____
JiJQPjNfT0MtCg==  &"P>3_OC-  0b 07 93 fe f8 cd  ......  &"P>3_OC-
JikwPClUPENICg==  &)0<)T<CH  25 07 09 d1 c8 e8  %.....  &)0<)T<CH

_Base64___UUEnc__Hex_______ASC__re-UUE____
ISpQICAK  !*P    2b        +    !*P``
IypcOysK  #*\;+  2b c6 cb  +..  #*\;+
IypcLykK  #*\/)  2b c3 c9  +..  #*\/)

ISNAICAK  !#@    0e        .    !#@``
IyNAPjIK  ##@>2  0e 07 92  ...  ##@>2
IyNAKjAK  ##@*0  0e 02 90  ...  ##@*0

ISggICAK  !(     20             !(```
IikwICAK  ")0    25 00     %.   ")0``
IilAPCAK  ")@<   26 07     &.   ")@<`

これは良さそうです:

  • unpack "u"(Perl のおよびを使用して) データを Udecoding および再エンコードするとpack "u"、元の文字列が生成されます`。

  • デコードされた文字列はもはや印刷可能な ASCII ではありません。これは、実際のデータに近い可能性があることを示唆しています。

  • watermark文字列は単一の文字になりました。width3 つのうち 2 つのケースでは、対応する文字列と文字列のプレフィックスですheight。(3 番目のケースは少し異なりますが、透かしが他の値に追加された可能性があります。)

パズルのもう 1 つのピース — ID 文字列と、コメントで指定した対応する数値を比較すると、次のことがわかります。

  • 数字はすべて6桁です。各数字の最初の 2 桁は同じです。
  • udecode された文字列はすべて 6 バイトです。各文字列の最初の 2 バイトは同じです。

一致？繰り返しますが、そうではないと思います。数値を ASCII 文字列として書き出し、udecode された文字列と XOR した場合に得られる結果を見てみましょう。

_Num_____ASCII_hex___________UUDecoded_ID________XOR______________
406747   34 30 36 37 34 37   25 07 09 d1 c8 e8   11 37 3f e6 fc df
405174   34 30 35 31 37 34   25 07 0a d7 cb eb   11 37 3f e6 fc df
405273   34 30 35 32 37 33   25 07 0a d4 cb ec   11 37 3f e6 fc df

この11 37 3f e6 fc df文字列は何ですか？私にはわかりません — ほとんどは印刷可能な ASCII ではありません — しかし、udecode された ID とそれを XOR すると、3 つのうち 3 つのケースで対応する ID 番号が得られます。

さらに考えてみましょう: 値に と の 2 つの異なる ID 文字列を指定し405174ましJiJQPjNfT0MtCg==たJikwPCpVXE9LCg==。0b 07 93 fe f8 cdこれらはそれぞれおよびにデコードされ25 07 0a d7 cb eb、それらの XOR は2e 00 99 29 33 26です。これらの ID 文字列の元となった 2 つの URL には0e、20それぞれ と の透かしがデコードされており、これが最初のバイトを占めています (いずれにせよ、2 番目のバイトはどちらも同じです)。残りの 4 バイトの違いがどこから来るのかは、私にはまだ謎です。

于 2012-03-05T13:40:15.630 に答える
0

それは難しいでしょう。暗号化方法とキーが見つかったとしても、元のデータはソルトされている可能性が高く、ソルトはレコードごとに異なる可能性があります。

それが暗号化のポイントです。

于 2012-03-05T12:37:26.650 に答える