UCブラウザの脆弱性を探しています

導入

XNUMX月末に私たちは、 報告された、UCブラウザに未検証のコードをロードして実行する隠れた機能を発見したとのこと。 今日は、このダウンロードがどのように行われるのか、そしてハッカーがそれをどのように独自の目的で使用するのかを詳しく見ていきます。

少し前、UC ブラウザは非常に積極的に宣伝され、配布されました。マルウェアを使用してユーザーのデバイスにインストールされ、ビデオ ファイルを装ってさまざまなサイトから配布されました (つまり、ユーザーは、たとえばポルノ ビデオをダウンロードしていると思っていましたが、代わりに、このブラウザで APK を受け取りました）、ブラウザが古い、脆弱であるなどのメッセージを含む恐ろしいバナーを使用しました。 VK の公式 UC Browser グループには、 テーマ、ユーザーが不当な広告について苦情を申し立てることができる場合、そこには多くの例があります。 2016年には、 動画広告 ロシア語で（そう、広告ブロックブラウザの広告です）。

この記事の執筆時点で、UC Browser は Google Play で 500 億件以上インストールされています。 これは印象的です。これ以上の機能を備えているのは Google Chrome だけです。 レビューの中には、広告や Google Play 上の一部のアプリケーションへのリダイレクトに関する苦情がかなり多く見られます。 これが私たちの調査の理由でした。UC ブラウザーが何か悪いことをしているかどうかを確認することにしました。 そして、彼はそうしていることが判明しました！

アプリケーション コードでは、実行可能コードをダウンロードして実行する機能が発見されました。 これはアプリケーションの公開ルールに違反します Google Playで。 UC ブラウザは、実行可能コードをダウンロードするだけでなく、安全でない方法でダウンロードを行うため、MitM 攻撃の開始に使用される可能性があります。 そのような攻撃を実行できるかどうか見てみましょう。

以下に記載されている内容はすべて、調査時点で Google Play で入手可能だった UC ブラウザのバージョンに関連しています。

package: com.UCMobile.intl
versionName: 12.10.8.1172
versionCode: 10598
sha1 APK-файла: f5edb2243413c777172f6362876041eb0c3a928c

攻撃ベクトル

UC ブラウザー マニフェストでは、わかりやすい名前のサービスを見つけることができます。 com.uc.deployment.UpgradeDeployService.

    <service android_exported="false" android_name="com.uc.deployment.UpgradeDeployService" android_process=":deploy" />

このサービスが開始されると、ブラウザは POST リクエストを送信します。 puds.ucweb.com/upgrade/index.xhtml, スタート後しばらくすると渋滞の中で見られます。 それに応じて、更新または新しいモジュールをダウンロードするコマンドを受信する場合があります。 分析中、サーバーはそのようなコマンドを発行しませんでしたが、ブラウザーで PDF を開こうとすると、サーバーは上で指定したアドレスに対して XNUMX 回目のリクエストを行い、その後ネイティブ ライブラリをダウンロードすることに気付きました。 攻撃を実行するために、私たちは UC Browser のこの機能を使用することにしました。つまり、APK には含まれておらず、必要に応じてインターネットからダウンロードするネイティブ ライブラリを使用して PDF を開く機能です。 理論的には、ブラウザの起動後に実行されるリクエストに対して適切な形式の応答を提供した場合、UC ブラウザはユーザーの介入なしに強制的に何かをダウンロードできることは注目に値します。 しかし、これを行うには、サーバーとの対話プロトコルをより詳細に研究する必要があるため、インターセプトされた応答を編集し、PDF を操作するためのライブラリを置き換える方が簡単であると判断しました。

したがって、ユーザーがブラウザで直接 PDF を開こうとすると、トラフィック内で次のリクエストが発生する可能性があります。

まず、次への POST リクエストがあります。 puds.ucweb.com/upgrade/index.xhtmlその後
PDF および Office 形式を表示するためのライブラリを含むアーカイブがダウンロードされます。 最初のリクエストがシステムに関する情報 (少なくとも必要なライブラリを提供するアーキテクチャ) を送信し、それに応答してブラウザがダウンロードする必要のあるライブラリに関する情報 (アドレスと、おそらくはアドレス) を受け取ると想定するのが論理的です。 、何か他のもの。 問題は、このリクエストが暗号化されていることです。

リクエストフラグメント

回答の断片

ライブラリ自体は ZIP でパッケージ化されており、暗号化されません。

トラフィック復号化コードを検索する

サーバーの応答を解読してみましょう。 クラスコードを見てみましょう com.uc.deployment.UpgradeDeployService: メソッドから onStartコマンド に行く com.uc.deployment.bx、そしてそこから com.uc.browser.core.dcfe:

    public final void e(l arg9) {
int v4_5;
String v3_1;
byte[] v3;
byte[] v1 = null;
if(arg9 == null) {
v3 = v1;
}
else {
v3_1 = arg9.iGX.ipR;
StringBuilder v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]product:");
v4.append(arg9.iGX.ipR);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]version:");
v4.append(arg9.iGX.iEn);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]upgrade_type:");
v4.append(arg9.iGX.mMode);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]force_flag:");
v4.append(arg9.iGX.iEo);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]silent_mode:");
v4.append(arg9.iGX.iDQ);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]silent_type:");
v4.append(arg9.iGX.iEr);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]silent_state:");
v4.append(arg9.iGX.iEp);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]silent_file:");
v4.append(arg9.iGX.iEq);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]apk_md5:");
v4.append(arg9.iGX.iEl);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]download_type:");
v4.append(arg9.mDownloadType);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]download_group:");
v4.append(arg9.mDownloadGroup);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]download_path:");
v4.append(arg9.iGH);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]apollo_child_version:");
v4.append(arg9.iGX.iEx);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]apollo_series:");
v4.append(arg9.iGX.iEw);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]apollo_cpu_arch:");
v4.append(arg9.iGX.iEt);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]apollo_cpu_vfp3:");
v4.append(arg9.iGX.iEv);
v4 = new StringBuilder("[");
v4.append(v3_1);
v4.append("]apollo_cpu_vfp:");
v4.append(arg9.iGX.iEu);
ArrayList v3_2 = arg9.iGX.iEz;
if(v3_2 != null && v3_2.size() != 0) {
Iterator v3_3 = v3_2.iterator();
while(v3_3.hasNext()) {
Object v4_1 = v3_3.next();
StringBuilder v5 = new StringBuilder("[");
v5.append(((au)v4_1).getName());
v5.append("]component_name:");
v5.append(((au)v4_1).getName());
v5 = new StringBuilder("[");
v5.append(((au)v4_1).getName());
v5.append("]component_ver_name:");
v5.append(((au)v4_1).aDA());
v5 = new StringBuilder("[");
v5.append(((au)v4_1).getName());
v5.append("]component_ver_code:");
v5.append(((au)v4_1).gBl);
v5 = new StringBuilder("[");
v5.append(((au)v4_1).getName());
v5.append("]component_req_type:");
v5.append(((au)v4_1).gBq);
}
}
j v3_4 = new j();
m.b(v3_4);
h v4_2 = new h();
m.b(v4_2);
ay v5_1 = new ay();
v3_4.hS("");
v3_4.setImsi("");
v3_4.hV("");
v5_1.bPQ = v3_4;
v5_1.bPP = v4_2;
v5_1.yr(arg9.iGX.ipR);
v5_1.gBF = arg9.iGX.mMode;
v5_1.gBI = arg9.iGX.iEz;
v3_2 = v5_1.gAr;
c.aBh();
v3_2.add(g.fs("os_ver", c.getRomInfo()));
v3_2.add(g.fs("processor_arch", com.uc.b.a.a.c.getCpuArch()));
v3_2.add(g.fs("cpu_arch", com.uc.b.a.a.c.Pb()));
String v4_3 = com.uc.b.a.a.c.Pd();
v3_2.add(g.fs("cpu_vfp", v4_3));
v3_2.add(g.fs("net_type", String.valueOf(com.uc.base.system.a.Jo())));
v3_2.add(g.fs("fromhost", arg9.iGX.iEm));
v3_2.add(g.fs("plugin_ver", arg9.iGX.iEn));
v3_2.add(g.fs("target_lang", arg9.iGX.iEs));
v3_2.add(g.fs("vitamio_cpu_arch", arg9.iGX.iEt));
v3_2.add(g.fs("vitamio_vfp", arg9.iGX.iEu));
v3_2.add(g.fs("vitamio_vfp3", arg9.iGX.iEv));
v3_2.add(g.fs("plugin_child_ver", arg9.iGX.iEx));
v3_2.add(g.fs("ver_series", arg9.iGX.iEw));
v3_2.add(g.fs("child_ver", r.aVw()));
v3_2.add(g.fs("cur_ver_md5", arg9.iGX.iEl));
v3_2.add(g.fs("cur_ver_signature", SystemHelper.getUCMSignature()));
v3_2.add(g.fs("upgrade_log", i.bjt()));
v3_2.add(g.fs("silent_install", String.valueOf(arg9.iGX.iDQ)));
v3_2.add(g.fs("silent_state", String.valueOf(arg9.iGX.iEp)));
v3_2.add(g.fs("silent_file", arg9.iGX.iEq));
v3_2.add(g.fs("silent_type", String.valueOf(arg9.iGX.iEr)));
v3_2.add(g.fs("cpu_archit", com.uc.b.a.a.c.Pc()));
v3_2.add(g.fs("cpu_set", SystemHelper.getCpuInstruction()));
boolean v4_4 = v4_3 == null || !v4_3.contains("neon") ? false : true;
v3_2.add(g.fs("neon", String.valueOf(v4_4)));
v3_2.add(g.fs("cpu_cores", String.valueOf(com.uc.b.a.a.c.Jl())));
v3_2.add(g.fs("ram_1", String.valueOf(com.uc.b.a.a.h.Po())));
v3_2.add(g.fs("totalram", String.valueOf(com.uc.b.a.a.h.OL())));
c.aBh();
v3_2.add(g.fs("rom_1", c.getRomInfo()));
v4_5 = e.getScreenWidth();
int v6 = e.getScreenHeight();
StringBuilder v7 = new StringBuilder();
v7.append(v4_5);
v7.append("*");
v7.append(v6);
v3_2.add(g.fs("ss", v7.toString()));
v3_2.add(g.fs("api_level", String.valueOf(Build$VERSION.SDK_INT)));
v3_2.add(g.fs("uc_apk_list", SystemHelper.getUCMobileApks()));
Iterator v4_6 = arg9.iGX.iEA.entrySet().iterator();
while(v4_6.hasNext()) {
Object v6_1 = v4_6.next();
v3_2.add(g.fs(((Map$Entry)v6_1).getKey(), ((Map$Entry)v6_1).getValue()));
}
v3 = v5_1.toByteArray();
}
if(v3 == null) {
this.iGY.iGI.a(arg9, "up_encode", "yes", "fail");
return;
}
v4_5 = this.iGY.iGw ? 0x1F : 0;
if(v3 == null) {
}
else {
v3 = g.i(v4_5, v3);
if(v3 == null) {
}
else {
v1 = new byte[v3.length + 16];
byte[] v6_2 = new byte[16];
Arrays.fill(v6_2, 0);
v6_2[0] = 0x5F;
v6_2[1] = 0;
v6_2[2] = ((byte)v4_5);
v6_2[3] = -50;
System.arraycopy(v6_2, 0, v1, 0, 16);
System.arraycopy(v3, 0, v1, 16, v3.length);
}
}
if(v1 == null) {
this.iGY.iGI.a(arg9, "up_encrypt", "yes", "fail");
return;
}
if(TextUtils.isEmpty(this.iGY.mUpgradeUrl)) {
this.iGY.iGI.a(arg9, "up_url", "yes", "fail");
return;
}
StringBuilder v0 = new StringBuilder("[");
v0.append(arg9.iGX.ipR);
v0.append("]url:");
v0.append(this.iGY.mUpgradeUrl);
com.uc.browser.core.d.c.i v0_1 = this.iGY.iGI;
v3_1 = this.iGY.mUpgradeUrl;
com.uc.base.net.e v0_2 = new com.uc.base.net.e(new com.uc.browser.core.d.c.i$a(v0_1, arg9));
v3_1 = v3_1.contains("?") ? v3_1 + "&dataver=pb" : v3_1 + "?dataver=pb";
n v3_5 = v0_2.uc(v3_1);
m.b(v3_5, false);
v3_5.setMethod("POST");
v3_5.setBodyProvider(v1);
v0_2.b(v3_5);
this.iGY.iGI.a(arg9, "up_null", "yes", "success");
this.iGY.iGI.b(arg9);
}

ここでは、POST リクエストの形成がわかります。 16 バイトの配列の作成とその配列 (0x5F、0、0x1F、-50 (=0xCE)) の作成に注目します。 上記のリクエストで確認した内容と一致します。

同じクラス内に、別の興味深いメソッドを持つネストされたクラスが表示されます。

        public final void a(l arg10, byte[] arg11) {
f v0 = this.iGQ;
StringBuilder v1 = new StringBuilder("[");
v1.append(arg10.iGX.ipR);
v1.append("]:UpgradeSuccess");
byte[] v1_1 = null;
if(arg11 == null) {
}
else if(arg11.length < 16) {
}
else {
if(arg11[0] != 0x60 && arg11[3] != 0xFFFFFFD0) {
goto label_57;
}
int v3 = 1;
int v5 = arg11[1] == 1 ? 1 : 0;
if(arg11[2] != 1 && arg11[2] != 11) {
if(arg11[2] == 0x1F) {
}
else {
v3 = 0;
}
}
byte[] v7 = new byte[arg11.length - 16];
System.arraycopy(arg11, 16, v7, 0, v7.length);
if(v3 != 0) {
v7 = g.j(arg11[2], v7);
}
if(v7 == null) {
goto label_57;
}
if(v5 != 0) {
v1_1 = g.P(v7);
goto label_57;
}
v1_1 = v7;
}
label_57:
if(v1_1 == null) {
v0.iGY.iGI.a(arg10, "up_decrypt", "yes", "fail");
return;
}
q v11 = g.b(arg10, v1_1);
if(v11 == null) {
v0.iGY.iGI.a(arg10, "up_decode", "yes", "fail");
return;
}
if(v0.iGY.iGt) {
v0.d(arg10);
}
if(v0.iGY.iGo != null) {
v0.iGY.iGo.a(0, ((o)v11));
}
if(v0.iGY.iGs) {
v0.iGY.a(((o)v11));
v0.iGY.iGI.a(v11, "up_silent", "yes", "success");
v0.iGY.iGI.a(v11);
return;
}
v0.iGY.iGI.a(v11, "up_silent", "no", "success");
}
}

このメソッドはバイト配列を入力として受け取り、0 バイトが 60x0 であるか、0 番目のバイトが 1xD11 であり、0 番目のバイトが 1、0、または 60x0F であることを確認します。 サーバーからの応答を確認します。ゼロバイトは 1x0、60 番目のバイトは XNUMXxXNUMXF、XNUMX 番目のバイトは XNUMXxXNUMX です。 必要なもののようですね。 行 (たとえば、「up_decrypt」) から判断すると、サーバーの応答を復号化するメソッドがここで呼び出されるはずです。
方法に移りましょう gj。 最初の引数はオフセット 2 のバイト (つまり、この場合は 0x1F) であり、XNUMX 番目の引数はサーバーの応答です。
最初の 16 バイト。

     public static byte[] j(int arg1, byte[] arg2) {
if(arg1 == 1) {
arg2 = c.c(arg2, c.adu);
}
else if(arg1 == 11) {
arg2 = m.aF(arg2);
}
else if(arg1 != 0x1F) {
}
else {
arg2 = EncryptHelper.decrypt(arg2);
}
return arg2;
}

明らかに、ここでは復号化アルゴリズムと、私たちのファイルにあるものと同じバイトを選択します。
0x1F に等しい場合は、XNUMX つの可能なオプションの XNUMX つを示します。

コードの分析を続けます。 いくつかジャンプすると、わかりやすい名前のメソッドにたどり着きます。 decryptBytesByKey.

ここでは、応答からさらに XNUMX バイトが分離され、そこから文字列が取得されます。 このようにして、メッセージを復号化するためのキーが選択されたことは明らかです。

    private static byte[] decryptBytesByKey(byte[] bytes) {
byte[] v0 = null;
if(bytes != null) {
try {
if(bytes.length < EncryptHelper.PREFIX_BYTES_SIZE) {
}
else if(bytes.length == EncryptHelper.PREFIX_BYTES_SIZE) {
return v0;
}
else {
byte[] prefix = new byte[EncryptHelper.PREFIX_BYTES_SIZE];  // 2 байта
System.arraycopy(bytes, 0, prefix, 0, prefix.length);
String keyId = c.ayR().d(ByteBuffer.wrap(prefix).getShort()); // Выбор ключа
if(keyId == null) {
return v0;
}
else {
a v2 = EncryptHelper.ayL();
if(v2 == null) {
return v0;
}
else {
byte[] enrypted = new byte[bytes.length - EncryptHelper.PREFIX_BYTES_SIZE];
System.arraycopy(bytes, EncryptHelper.PREFIX_BYTES_SIZE, enrypted, 0, enrypted.length);
return v2.l(keyId, enrypted);
}
}
}
}
catch(SecException v7_1) {
EncryptHelper.handleDecryptException(((Throwable)v7_1), v7_1.getErrorCode());
return v0;
}
catch(Throwable v7) {
EncryptHelper.handleDecryptException(v7, 2);
return v0;
}
}
return v0;
}

今後に注目して、この段階ではまだキーを取得しておらず、その「識別子」だけを取得していることに注意してください。 キーの取得は少し複雑です。

次のメソッドでは、既存のパラメータにさらに 16 つのパラメータが追加され、マジック ナンバー XNUMX、キー識別子、暗号化されたデータ、および理解できない文字列 (この場合は空) の XNUMX つが作成されます。

    public final byte[] l(String keyId, byte[] encrypted) throws SecException {
return this.ayJ().staticBinarySafeDecryptNoB64(16, keyId, encrypted, "");
}

一連の遷移を経て、メソッドに到達します。 staticBinarySafeDecryptNoB64 インターフェースの com.alibaba.wireless.security.open.staticdataencrypt.IStaticDataEncryptComponent。 メイン アプリケーション コードには、このインターフェイスを実装するクラスはありません。 ファイル内にそのようなクラスがあります lib/armeabi-v7a/libsgmain.so、実際には .so ではなく .jar です。 私たちが興味のあるメソッドは次のように実装されます。

package com.alibaba.wireless.security.a.i;
// ...
public class a implements IStaticDataEncryptComponent {
private ISecurityGuardPlugin a;
// ...
private byte[] a(int mode, int magicInt, int xzInt, String keyId, byte[] encrypted, String magicString) {
return this.a.getRouter().doCommand(10601, new Object[]{Integer.valueOf(mode), Integer.valueOf(magicInt), Integer.valueOf(xzInt), keyId, encrypted, magicString});
}
// ...
private byte[] b(int magicInt, String keyId, byte[] encrypted, String magicString) {
return this.a(2, magicInt, 0, keyId, encrypted, magicString);
}
// ...
public byte[] staticBinarySafeDecryptNoB64(int magicInt, String keyId, byte[] encrypted, String magicString) throws SecException {
if(keyId != null && keyId.length() > 0 && magicInt >= 0 && magicInt < 19 && encrypted != null && encrypted.length > 0) {
return this.b(magicInt, keyId, encrypted, magicString);
}
throw new SecException("", 301);
}
//...
}

ここでは、パラメータのリストにさらに 2 つの整数、0 と XNUMX が追加されています。
すべて、2 はメソッドのように復号化を意味します ファイナルをやる システムクラス javax.crypto.Cipher。 そして、これらすべては番号10601を持つ特定のルーターに転送されます-これは明らかにコマンド番号です。

次の一連の遷移の後、インターフェイスを実装するクラスが見つかります。 Iルーターコンポーネント と方法 doコマンド:

package com.alibaba.wireless.security.mainplugin;
import com.alibaba.wireless.security.framework.IRouterComponent;
import com.taobao.wireless.security.adapter.JNICLibrary;
public class a implements IRouterComponent {
public a() {
super();
}
public Object doCommand(int arg2, Object[] arg3) {
return JNICLibrary.doCommandNative(arg2, arg3);
}
}

そしてクラスも JNICライブラリ、ネイティブ メソッドが宣言されている doCommandネイティブ:

package com.taobao.wireless.security.adapter;
public class JNICLibrary {
public static native Object doCommandNative(int arg0, Object[] arg1);
}

これは、ネイティブ コードでメソッドを見つける必要があることを意味します doCommandネイティブ。 ここからが楽しみの始まりです。

マシンコードの難読化

ファイル内 libsgmain.so (これは実際には .jar であり、その中に暗号化関連のインターフェイスの実装が上記で見つかりました) ネイティブ ライブラリが XNUMX つあります。 libsgmainso-6.4.36.so。 IDA で開くと、エラーが表示されたダイアログ ボックスが多数表示されます。 問題は、セクションヘッダーテーブルが無効であることです。 これは分析を複雑にするために意図的に行われます。

しかし、これは必要ありません。ELF ファイルを正しくロードして分析するには、プログラム ヘッダー テーブルがあれば十分です。 したがって、単にセクション テーブルを削除し、ヘッダー内の対応するフィールドをゼロに設定します。

IDA でファイルを再度開きます。

Java コードでネイティブとして宣言されたメソッドの実装がネイティブ ライブラリ内のどこにあるかを Java 仮想マシンに正確に伝える方法は XNUMX つあります。 まずは種名を付けることです Java_パッケージ名_クラス名_メソッド名.

XNUMX つ目は、ライブラリをロードするときに (関数内で) 登録することです。 JNI_OnLoad)
関数呼び出しを使用する ネイティブを登録する.

私たちの場合、最初の方法を使用すると、名前は次のようになります。 Java_com_taobao_wireless_security_adapter_JNICLibrary_doCommandNative.

エクスポートされた関数の中にそのような関数はありません。つまり、呼び出しを探す必要があります。 ネイティブを登録する.
関数に行きましょう JNI_OnLoad そして、次の図が表示されます。

何が起きてる？ 一見すると、関数の開始と終了は ARM アーキテクチャの典型的なものです。 スタック上の最初の命令は、関数がその動作で使用するレジスター (この場合は R0、R1、および R2) の内容と、関数からの戻りアドレスを含む LR レジスターの内容を保管します。 。 最後の命令は保存されたレジスタを復元し、戻りアドレスが直ちに PC レジスタに配置されるため、関数から戻ります。 しかし、よく見ると、最後から XNUMX 番目の命令がスタックに格納されているリターン アドレスを変更していることに気づくでしょう。 その後どうなるかを計算してみましょう
コードの実行。 特定のアドレス 1xB0 が R130 にロードされ、そこから 5 が減算され、その後 R0 に転送され、それに 0x10 が加算されます。 0xB13B であることがわかります。 したがって、IDA は最後の命令が通常の関数リターンであると考えますが、実際には計算されたアドレス 0xB13B に移動します。

ここで、ARM プロセッサには ARM と Thumb という 0 つのモードと 13 つの命令セットがあることを思い出してください。 アドレスの最下位ビットは、どの命令セットが使用されているかをプロセッサに伝えます。 つまり、アドレスは実際には XNUMXxBXNUMXA で、最下位ビットの XNUMX つは Thumb モードを示します。

同様の「アダプター」がこのライブラリの各関数の先頭に追加されており、
ゴミコード。 これ以上詳しくは説明しません - ただ覚えているだけです
ほとんどすべての機能の本当の始まりはもう少し先だということです。

コードは明示的に 0xB13A にジャンプしないため、IDA 自体はコードがこの場所にあることを認識しませんでした。 同じ理由で、ライブラリ内のコードのほとんどがコードとして認識されないため、分析がやや困難になります。 IDA にこれがコードであると伝えると、次のことが起こります。

テーブルは明らかに 0xB144 から始まります。 sub_494C には何が入っていますか?

LR レジスタでこの関数を呼び出すと、前述のテーブルのアドレス (0xB144) が取得されます。 R0 - このテーブルのインデックス。 つまり、テーブルから値が取得され、LR に加算され、結果は次のようになります。
行き先の住所。 計算してみましょう: 0xB144 + [0xB144 + 8* 4] = 0xB144 + 0x120 = 0xB264。 受信したアドレスに移動すると、文字通りいくつかの有用な命令が表示され、再び 0xB140 に移動します。

これで、テーブルからのインデックス 0x20 のオフセットに遷移が存在します。

テーブルのサイズから判断すると、コード内にそのような遷移が多数あることがわかります。 アドレスを手動で計算せずに、何らかの方法でより自動的にこれに対処することができるかどうかという疑問が生じます。 そして、IDA のスクリプトとコードにパッチを適用する機能が役に立ちます。

def put_unconditional_branch(source, destination):
offset = (destination - source - 4) >> 1
if offset > 2097151 or offset < -2097152:
raise RuntimeError("Invalid offset")
if offset > 1023 or offset < -1024:
instruction1 = 0xf000 | ((offset >> 11) & 0x7ff)
instruction2 = 0xb800 | (offset & 0x7ff)
patch_word(source, instruction1)
patch_word(source + 2, instruction2)
else:
instruction = 0xe000 | (offset & 0x7ff)
patch_word(source, instruction)
ea = here()
if get_wide_word(ea) == 0xb503: #PUSH {R0,R1,LR}
ea1 = ea + 2
if get_wide_word(ea1) == 0xbf00: #NOP
ea1 += 2
if get_operand_type(ea1, 0) == 1 and get_operand_value(ea1, 0) == 0 and get_operand_type(ea1, 1) == 2:
index = get_wide_dword(get_operand_value(ea1, 1))
print "index =", hex(index)
ea1 += 2
if get_operand_type(ea1, 0) == 7:
table = get_operand_value(ea1, 0) + 4
elif get_operand_type(ea1, 1) == 2:
table = get_operand_value(ea1, 1) + 4
else:
print "Wrong operand type on", hex(ea1), "-", get_operand_type(ea1, 0), get_operand_type(ea1, 1)
table = None
if table is None:
print "Unable to find table"
else:
print "table =", hex(table)
offset = get_wide_dword(table + (index << 2))
put_unconditional_branch(ea, table + offset)
else:
print "Unknown code", get_operand_type(ea1, 0), get_operand_value(ea1, 0), get_operand_type(ea1, 1) == 2
else:
print "Unable to detect first instruction"

カーソルを行 0xB26A に置き、スクリプトを実行して、0xB4B0 への遷移を確認します。

IDAは再びこの領域をコードとして認識しませんでした。 私たちは彼女を手伝い、そこで別のデザインを確認します。

BLX の後の指示はあまり意味がないようで、ある種の移動のようなものです。 sub_4964 を見てみましょう。

実際、ここでは LR にあるアドレスで dword が取得され、このアドレスに追加され、その後、結果のアドレスの値が取得されてスタックに置かれます。 また、関数から戻った後、この同じオフセットがスキップされるように、LR に 4 が追加されます。 その後、POP {R1} コマンドは結果の値をスタックから取得します。 アドレス 0xB4BA + 0xEA = 0xB5A4 にあるものを見ると、アドレス テーブルのようなものが表示されます。

このデザインにパッチを適用するには、コードから XNUMX つのパラメーター、オフセットと結果を格納するレジスタ番号を取得する必要があります。 考えられるレジスタごとに、事前にコードを準備する必要があります。

patches = {}
patches[0] = (0x00, 0xbf, 0x01, 0x48, 0x00, 0x68, 0x02, 0xe0)
patches[1] = (0x00, 0xbf, 0x01, 0x49, 0x09, 0x68, 0x02, 0xe0)
patches[2] = (0x00, 0xbf, 0x01, 0x4a, 0x12, 0x68, 0x02, 0xe0)
patches[3] = (0x00, 0xbf, 0x01, 0x4b, 0x1b, 0x68, 0x02, 0xe0)
patches[4] = (0x00, 0xbf, 0x01, 0x4c, 0x24, 0x68, 0x02, 0xe0)
patches[5] = (0x00, 0xbf, 0x01, 0x4d, 0x2d, 0x68, 0x02, 0xe0)
patches[8] = (0x00, 0xbf, 0xdf, 0xf8, 0x06, 0x80, 0xd8, 0xf8, 0x00, 0x80, 0x01, 0xe0)
patches[9] = (0x00, 0xbf, 0xdf, 0xf8, 0x06, 0x90, 0xd9, 0xf8, 0x00, 0x90, 0x01, 0xe0)
patches[10] = (0x00, 0xbf, 0xdf, 0xf8, 0x06, 0xa0, 0xda, 0xf8, 0x00, 0xa0, 0x01, 0xe0)
patches[11] = (0x00, 0xbf, 0xdf, 0xf8, 0x06, 0xb0, 0xdb, 0xf8, 0x00, 0xb0, 0x01, 0xe0)
ea = here()
if (get_wide_word(ea) == 0xb082 #SUB SP, SP, #8
and get_wide_word(ea + 2) == 0xb503): #PUSH {R0,R1,LR}
if get_operand_type(ea + 4, 0) == 7:
pop = get_bytes(ea + 12, 4, 0)
if pop[1] == 'xbc':
register = -1
r = get_wide_byte(ea + 12)
for i in range(8):
if r == (1 << i):
register = i
break
if register == -1:
print "Unable to detect register"
else:
address = get_wide_dword(ea + 8) + ea + 8
for b in patches[register]:
patch_byte(ea, b)
ea += 1
if ea % 4 != 0:
ea += 2
patch_dword(ea, address)
elif pop[:3] == 'x5dxf8x04':
register = ord(pop[3]) >> 4
if register in patches:
address = get_wide_dword(ea + 8) + ea + 8
for b in patches[register]:
patch_byte(ea, b)
ea += 1
patch_dword(ea, address)
else:
print "POP instruction not found"
else:
print "Wrong operand type on +4:", get_operand_type(ea + 4, 0)
else:
print "Unable to detect first instructions"

置換する構造体の先頭 (0xB4B2) にカーソルを置き、スクリプトを実行します。

すでに述べた構造に加えて、コードには次のものも含まれています。

前のケースと同様に、BLX 命令の後にオフセットがあります。

LR からアドレスへのオフセットを取得し、それを LR に追加して、そこに移動します。 0x72044 + 0xC = 0x72050。 この設計のスクリプトは非常に単純です。

def put_unconditional_branch(source, destination):
offset = (destination - source - 4) >> 1
if offset > 2097151 or offset < -2097152:
raise RuntimeError("Invalid offset")
if offset > 1023 or offset < -1024:
instruction1 = 0xf000 | ((offset >> 11) & 0x7ff)
instruction2 = 0xb800 | (offset & 0x7ff)
patch_word(source, instruction1)
patch_word(source + 2, instruction2)
else:
instruction = 0xe000 | (offset & 0x7ff)
patch_word(source, instruction)
ea = here()
if get_wide_word(ea) == 0xb503: #PUSH {R0,R1,LR}
ea1 = ea + 6
if get_wide_word(ea + 2) == 0xbf00: #NOP
ea1 += 2
offset = get_wide_dword(ea1)
put_unconditional_branch(ea, (ea1 + offset) & 0xffffffff)
else:
print "Unable to detect first instruction"

スクリプトの実行結果:

関数内ですべてのパッチを適用したら、IDA をその本当の始まりに向けることができます。 すべての関数コードが結合され、HexRays を使用して逆コンパイルできます。

文字列のデコード

私たちはライブラリ内のマシンコードの難読化に対処する方法を学びました libsgmainso-6.4.36.so UCブラウザから機能コードを受信しました JNI_OnLoad.

int __fastcall real_JNI_OnLoad(JavaVM *vm)
{
int result; // r0
jclass clazz; // r0 MAPDST
int v4; // r0
JNIEnv *env; // r4
int v6; // [sp-40h] [bp-5Ch]
int v7; // [sp+Ch] [bp-10h]
v7 = *(_DWORD *)off_8AC00;
if ( !vm )
goto LABEL_39;
sub_7C4F4();
env = (JNIEnv *)sub_7C5B0(0);
if ( !env )
goto LABEL_39;
v4 = sub_72CCC();
sub_73634(v4);
sub_73E24(&unk_83EA6, &v6, 49);
clazz = (jclass)((int (__fastcall *)(JNIEnv *, int *))(*env)->FindClass)(env, &v6);
if ( clazz
&& (sub_9EE4(),
sub_71D68(env),
sub_E7DC(env) >= 0
&& sub_69D68(env) >= 0
&& sub_197B4(env, clazz) >= 0
&& sub_E240(env, clazz) >= 0
&& sub_B8B0(env, clazz) >= 0
&& sub_5F0F4(env, clazz) >= 0
&& sub_70640(env, clazz) >= 0
&& sub_11F3C(env) >= 0
&& sub_21C3C(env, clazz) >= 0
&& sub_2148C(env, clazz) >= 0
&& sub_210E0(env, clazz) >= 0
&& sub_41B58(env, clazz) >= 0
&& sub_27920(env, clazz) >= 0
&& sub_293E8(env, clazz) >= 0
&& sub_208F4(env, clazz) >= 0) )
{
result = (sub_B7B0(env, clazz) >> 31) | 0x10004;
}
else
{
LABEL_39:
result = -1;
}
return result;
}

次の行を詳しく見てみましょう。

  sub_73E24(&unk_83EA6, &v6, 49);
clazz = (jclass)((int (__fastcall *)(JNIEnv *, int *))(*env)->FindClass)(env, &v6);

機能中 サブ_73E24 クラス名は明らかに復号化されています。 この関数のパラメータとして、暗号化データと同様のデータへのポインタ、特定のバッファ、および数値が渡されます。 明らかに、関数を呼び出した後は、関数に渡されるため、バッファーに復号化された行が存在します。 クラスの検索、クラス名を XNUMX 番目のパラメータとして受け取ります。 したがって、この数値はバッファのサイズまたは行の長さになります。 クラス名を解読してみましょう。正しい方向に進んでいるかどうかがわかるはずです。 で何が起こるかを詳しく見てみましょう サブ_73E24。

int __fastcall sub_73E56(unsigned __int8 *in, unsigned __int8 *out, size_t size)
{
int v4; // r6
int v7; // r11
int v8; // r9
int v9; // r4
size_t v10; // r5
int v11; // r0
struc_1 v13; // [sp+0h] [bp-30h]
int v14; // [sp+1Ch] [bp-14h]
int v15; // [sp+20h] [bp-10h]
v4 = 0;
v15 = *(_DWORD *)off_8AC00;
v14 = 0;
v7 = sub_7AF78(17);
v8 = sub_7AF78(size);
if ( !v7 )
{
v9 = 0;
goto LABEL_12;
}
(*(void (__fastcall **)(int, const char *, int))(v7 + 12))(v7, "DcO/lcK+h?m3c*q@", 16);
if ( !v8 )
{
LABEL_9:
v4 = 0;
goto LABEL_10;
}
v4 = 0;
if ( !in )
{
LABEL_10:
v9 = 0;
goto LABEL_11;
}
v9 = 0;
if ( out )
{
memset(out, 0, size);
v10 = size - 1;
(*(void (__fastcall **)(int, unsigned __int8 *, size_t))(v8 + 12))(v8, in, v10);
memset(&v13, 0, 0x14u);
v13.field_4 = 3;
v13.field_10 = v7;
v13.field_14 = v8;
v11 = sub_6115C(&v13, &v14);
v9 = v11;
if ( v11 )
{
if ( *(_DWORD *)(v11 + 4) == v10 )
{
qmemcpy(out, *(const void **)v11, v10);
v4 = *(_DWORD *)(v9 + 4);
}
else
{
v4 = 0;
}
goto LABEL_11;
}
goto LABEL_9;
}
LABEL_11:
sub_7B148(v7);
LABEL_12:
if ( v8 )
sub_7B148(v8);
if ( v9 )
sub_7B148(v9);
return v4;
}

機能 サブ_7AF78 指定されたサイズのバイト配列のコンテナーのインスタンスを作成します (これらのコンテナーについては詳しく説明しません)。 ここでは、そのようなコンテナが XNUMX つ作成されます。XNUMX つは次の行を含みます。 「DcO/lcK+h?m3c*q@」 (これがキーであることは簡単に推測できます)、もう一方には暗号化されたデータが含まれています。 次に、両方のオブジェクトが特定の構造体に配置され、関数に渡されます。 サブ_6115C。 また、この構造体のフィールドに値 3 をマークして、次にこの構造体に何が起こるかを見てみましょう。

int __fastcall sub_611B4(struc_1 *a1, _DWORD *a2)
{
int v3; // lr
unsigned int v4; // r1
int v5; // r0
int v6; // r1
int result; // r0
int v8; // r0
*a2 = 820000;
if ( a1 )
{
v3 = a1->field_14;
if ( v3 )
{
v4 = a1->field_4;
if ( v4 < 0x19 )
{
switch ( v4 )
{
case 0u:
v8 = sub_6419C(a1->field_0, a1->field_10, v3);
goto LABEL_17;
case 3u:
v8 = sub_6364C(a1->field_0, a1->field_10, v3);
goto LABEL_17;
case 0x10u:
case 0x11u:
case 0x12u:
v8 = sub_612F4(
a1->field_0,
v4,
*(_QWORD *)&a1->field_8,
*(_QWORD *)&a1->field_8 >> 32,
a1->field_10,
v3,
a2);
goto LABEL_17;
case 0x14u:
v8 = sub_63A28(a1->field_0, v3);
goto LABEL_17;
case 0x15u:
sub_61A60(a1->field_0, v3, a2);
return result;
case 0x16u:
v8 = sub_62440(a1->field_14);
goto LABEL_17;
case 0x17u:
v8 = sub_6226C(a1->field_10, v3);
goto LABEL_17;
case 0x18u:
v8 = sub_63530(a1->field_14);
LABEL_17:
v6 = 0;
if ( v8 )
{
*a2 = 0;
v6 = v8;
}
return v6;
default:
LOWORD(v5) = 28032;
goto LABEL_5;
}
}
}
}
LOWORD(v5) = -27504;
LABEL_5:
HIWORD(v5) = 13;
v6 = 0;
*a2 = v5;
return v6;
}

switch パラメータは、以前に値 3 が割り当てられていた構造体フィールドです。ケース 3 を見てください: 関数へ サブ_6364C パラメータは、前の関数で追加された構造体、つまりキーと暗号化されたデータから渡されます。 よく見ると サブ_6364C、その中に RC4 アルゴリズムがあることがわかります。

アルゴリズムと鍵があります。 クラス名を解読してみましょう。 何が起こったかは次のとおりです。 com/taobao/wireless/security/adapter/JNICLibrary。 素晴らしい！ 私たちは正しい道を進んでいます。

コマンドツリー

今、私たちは課題を見つける必要があります ネイティブを登録する、関数を示します doCommandネイティブ。 から呼び出される関数を見てみましょう JNI_OnLoad、 そしてそれを見つけます サブ_B7B0:

int __fastcall sub_B7F6(JNIEnv *env, jclass clazz)
{
char signature[41]; // [sp+7h] [bp-55h]
char name[16]; // [sp+30h] [bp-2Ch]
JNINativeMethod method; // [sp+40h] [bp-1Ch]
int v8; // [sp+4Ch] [bp-10h]
v8 = *(_DWORD *)off_8AC00;
decryptString((unsigned __int8 *)&unk_83ED9, (unsigned __int8 *)name, 0x10u);// doCommandNative
decryptString((unsigned __int8 *)&unk_83EEA, (unsigned __int8 *)signature, 0x29u);// (I[Ljava/lang/Object;)Ljava/lang/Object;
method.name = name;
method.signature = signature;
method.fnPtr = sub_B69C;
return ((int (__fastcall *)(JNIEnv *, jclass, JNINativeMethod *, int))(*env)->RegisterNatives)(env, clazz, &method, 1) >> 31;
}

そして確かに、この名前のネイティブメソッドがここに登録されています doCommandネイティブ。 今、私たちは彼の住所を知っています。 彼が何をするのか見てみましょう。

int __fastcall doCommandNative(JNIEnv *env, jobject obj, int command, jarray args)
{
int v5; // r5
struc_2 *a5; // r6
int v9; // r1
int v11; // [sp+Ch] [bp-14h]
int v12; // [sp+10h] [bp-10h]
v5 = 0;
v12 = *(_DWORD *)off_8AC00;
v11 = 0;
a5 = (struc_2 *)malloc(0x14u);
if ( a5 )
{
a5->field_0 = 0;
a5->field_4 = 0;
a5->field_8 = 0;
a5->field_C = 0;
v9 = command % 10000 / 100;
a5->field_0 = command / 10000;
a5->field_4 = v9;
a5->field_8 = command % 100;
a5->field_C = env;
a5->field_10 = args;
v5 = sub_9D60(command / 10000, v9, command % 100, 1, (int)a5, &v11);
}
free(a5);
if ( !v5 && v11 )
sub_7CF34(env, v11, &byte_83ED7);
return v5;
}

名前から、ここが開発者がネイティブ ライブラリに移行することを決定したすべての関数のエントリ ポイントであることが推測できます。 私たちは関数番号 10601 に興味があります。

コードから、コマンド番号によって XNUMX つの数字が生成されることがわかります。 コマンド/10000, コマンド % 10000 / 100 и コマンド %10つまり、この場合は 1、6、1 です。これら XNUMX つの数字と、へのポインタです。 JNI環境 関数に渡された引数は構造体に追加されて渡されます。 取得した 1 つの数値 (N2、N3、NXNUMX とします) を使用して、コマンド ツリーが構築されます。

このようなもの：

ツリーは動的に埋められます JNI_OnLoad.
XNUMX つの数字がツリー内のパスをエンコードします。 ツリーの各リーフには、対応する関数のポッキング アドレスが含まれています。 キーは親ノードにあります。 使用されているすべての構造を理解していれば、必要な関数がツリーに追加されているコード内の場所を見つけることは難しくありません (すでにかなり大きな記事が肥大化しないように、構造については説明しません)。

さらなる難読化

トラフィックを復号化する必要がある関数のアドレス: 0x5F1AC を受け取りました。 しかし、喜ぶのは時期尚早です。UC ブラウザの開発者は、私たちに別のサプライズを用意してくれました。

Java コードで形成された配列からパラメータを受け取った後、次の結果を取得します。
アドレス 0x4D070 の関数に送信します。 そしてここで、別のタイプのコード難読化が私たちを待っています。

R7 と R4 に XNUMX つのインデックスを置きます。

最初のインデックスを R11 にシフトします。

テーブルからアドレスを取得するには、インデックスを使用します。

最初のアドレスに移動した後、R4 にある 230 番目のインデックスが使用されます。 テーブルには XNUMX 個の要素があります。

それについてどうすればよいでしょうか？ これがスイッチであることを IDA に伝えることができます。[編集] -> [その他] -> [スイッチ イディオムを指定] を選択します。

結果として得られるコードは恐ろしいものです。 しかし、ジャングルを抜けていくと、すでにおなじみの関数が呼び出されていることに気づくでしょう。 サブ_6115C:

ケース 3 では、RC4 アルゴリズムを使用した復号化が行われるスイッチがありました。 この場合、関数に渡される構造体には、関数に渡されたパラメータが入力されます。 doCommandネイティブ。 そこで何を食べたか思い出しましょう マジックイント 対応するケースを調べ、いくつかの遷移の後、アルゴリズムを識別できるコードを見つけます。

これがAESです！

アルゴリズムは存在します。残っているのは、そのパラメーター (モード、キー、および場合によっては初期化ベクトル) を取得することだけです (アルゴリズムの存在は AES アルゴリズムの動作モードによって異なります)。 これらを含む構造は、関数呼び出しの前のどこかで形成する必要があります。 サブ_6115Cしかし、コードのこの部分は特によく難読化されているため、復号化関数のすべてのパラメータがファイルにダンプされるようにコードにパッチを適用するというアイデアが生まれました。

パッチ

すべてのパッチ コードを手動でアセンブリ言語で記述しないようにするには、Android Studio を起動し、復号化関数と同じ入力パラメータを受け取り、ファイルに書き込む関数をそこに記述し、コンパイラが指定するコードをコピーして貼り付けます。生成する。

UC Browser チームの友人たちも、コードを追加する際の利便性を考慮してくれました。 各関数の先頭には、簡単に他の関数に置き換えることができるガベージ コードがあることを思い出してください。 非常に便利です 🙂 ただし、ターゲット関数の先頭には、すべてのパラメーターをファイルに保存するコードを配置するための十分なスペースがありません。 それを部分に分割し、隣接する関数のガベージ ブロックを使用する必要がありました。 全部でXNUMXつのパートがありました。

最初の部分：

ARM アーキテクチャでは、最初の 0 つの関数パラメータはレジスタ R3 ～ R0 を介して渡され、残りは (存在する場合) スタックを介して渡されます。 LR レジスタは戻りアドレスを保持します。 パラメータをダンプした後に関数が動作できるように、これらすべてを保存する必要があります。 また、プロセスで使用するすべてのレジスタを保存する必要があるため、PUSH.W {R10-R7,LR} を実行します。 RXNUMX では、スタック経由で関数に渡されるパラメーターのリストのアドレスを取得します。

機能の使用 フォペン ファイルを開いてみましょう /data/local/tmp/aes 「腹筋」モードで
つまり追加用です。 R0 にはファイル名のアドレスをロードし、R1 にはモードを示す行のアドレスをロードします。 ここでゴミコードは終了するので、次の関数に進みます。 動作し続けるために、最初に関数の実際のコードへの遷移を配置してガベージをバイパスし、ガベージの代わりにパッチの継続を追加します。

呼び出し フォペン.

関数の最初の XNUMX つのパラメータ エース タイプがある int型。 最初にレジスタをスタックに保存したので、単純に関数を渡すことができます。 書き込み スタック上のアドレス。

次に、データ サイズと、キー、初期化ベクトル、および暗号化データのデータへのポインターを含む XNUMX つの構造体があります。

最後に、ファイルを閉じ、レジスタを復元し、制御を実際の関数に移します。 エース.

パッチが適用されたライブラリを含む APK を収集し、署名し、デバイス/エミュレーターにアップロードして起動します。 ダンプが作成され、そこに大量のデータが書き込まれていることがわかります。 ブラウザはトラフィックだけでなく暗号化を使用し、すべての暗号化は当該の機能を通過します。 しかし、何らかの理由で必要なデータが存在せず、必要なリクエストがトラフィック内に表示されません。 UC ブラウザが必要なリクエストを行うようになるまで待たないように、以前に受信したサーバーから暗号化された応答を取得して、アプリケーションに再度パッチを適用しましょう。メイン アクティビティの onCreate に復号化を追加します。

    const/16 v1, 0x62
new-array v1, v1, [B
fill-array-data v1, :encrypted_data
const/16 v0, 0x1f
invoke-static {v0, v1}, Lcom/uc/browser/core/d/c/g;->j(I[B)[B
move-result-object v1
array-length v2, v1
invoke-static {v2}, Ljava/lang/String;->valueOf(I)Ljava/lang/String;
move-result-object v2
const-string v0, "ololo"
invoke-static {v0, v2}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I

私たちは組み立て、署名、設置、打ち上げを行います。 メソッドが null を返したため、NullPointerException を受け取ります。

コードをさらに分析すると、興味深い行「META-INF/」と「.RSA」を解読する関数が発見されました。 アプリケーションが証明書を検証しているようです。 あるいは、そこからキーを生成することもできます。 証明書で何が起こっているかについてはあまり扱いたくないので、正しい証明書を差し込むだけです。 暗号化された行にパッチを適用して、「META-INF/」の代わりに「BLABLINF/」を取得し、APK 内にその名前のフォルダーを作成し、そこにリス ブラウザ証明書を追加しましょう。

私たちは組み立て、署名、設置、打ち上げを行います。 ビンゴ！ 私たちは鍵を持っています！

MitM

キーとそのキーに等しい初期化ベクトルを受け取りました。 CBC モードでサーバー応答を復号化してみましょう。

MD5 に似たアーカイブ URL、「extract_unzipsize」と数字が表示されます。 アーカイブの MD5 が同じであり、解凍されたライブラリのサイズが同じであることを確認します。 このライブラリにパッチを適用してブラウザに提供しようとしています。 パッチを適用したライブラリがロードされたことを示すために、「PWNED!」というテキストを含む SMS を作成するインテントを起動します。 サーバーからの XNUMX つの応答を置き換えます。 puds.ucweb.com/upgrade/index.xhtml そしてアーカイブをダウンロードします。 5 つ目では MDXNUMX を置き換えます (解凍後もサイズは変わりません)。XNUMX つ目では、パッチを適用したライブラリを含むアーカイブを提供します。

ブラウザはアーカイブを数回ダウンロードしようとしますが、その後エラーが発生します。 どうやら何か
彼は好きじゃない。 この曖昧な形式を分析した結果、サーバーはアーカイブのサイズも送信していることが判明しました。

LEB128でエンコードされています。 パッチ後、ライブラリを含むアーカイブのサイズが少し変更されたため、ブラウザはアーカイブが不正にダウンロードされたと判断し、数回試行した後にエラーをスローしました。

アーカイブのサイズを調整します...そして、勝利! 🙂 結果はビデオにあります。

https://www.youtube.com/watch?v=Nfns7uH03J8

結果と開発者の反応

同様に、ハッカーは UC ブラウザの安全でない機能を利用して、悪意のあるライブラリを配布し、実行する可能性があります。 これらのライブラリはブラウザのコンテキストで動作するため、すべてのシステム権限を受け取ります。 その結果、フィッシング ウィンドウを表示できるだけでなく、データベースに保存されているログイン情報、パスワード、Cookie などのオレンジ色のチャイニーズ リスの作業ファイルにアクセスできるようになります。

私たちは UC Browser の開発者に連絡し、発見した問題について伝え、脆弱性とその危険性を指摘しようとしましたが、何も話してくれませんでした。 その間、ブラウザはその危険な機能を公然と誇示し続けました。 しかし、脆弱性の詳細が明らかになると、以前のように無視することはできなくなりました。 27月XNUMX日は
UC ブラウザの新しいバージョン 12.10.9.1193 がリリースされました。これは、HTTPS 経由でサーバーにアクセスしました。 puds.ucweb.com/upgrade/index.xhtml.

さらに、「修正」後、この記事を書いている時点まで、ブラウザで PDF を開こうとすると、「おっと、問題が発生しました!」というテキストのエラー メッセージが表示されました。 PDF を開こうとしたときにサーバーへのリクエストは行われませんでしたが、ブラウザの起動時にリクエストが行われました。これは、Google Play のルールに違反して実行可能コードをダウンロードする能力が継続的に存在することを示唆しています。

出所： habr.com