UC 브라우저의 취약점 찾기

소개

XNUMX월 말에 우리는 보고, 그들은 UC 브라우저에서 확인되지 않은 코드를 로드하고 실행하는 숨겨진 기능을 발견했습니다. 오늘 우리는 이 다운로드가 어떻게 이루어지는지, 그리고 해커가 자신의 목적을 위해 이를 어떻게 사용할 수 있는지 자세히 살펴보겠습니다.

얼마 전 UC Browser는 매우 공격적으로 광고 및 배포되었습니다. 악성 코드를 사용하여 사용자 장치에 설치되었으며, 비디오 파일로 위장하여 다양한 사이트에서 배포되었습니다(예: 사용자는 포르노 비디오 등을 다운로드한다고 생각했지만, 대신 이 브라우저로 APK를 받았습니다), 브라우저가 오래되고 취약하다는 메시지가 포함된 무서운 배너를 사용했습니다. VK의 공식 UC 브라우저 그룹에는 다음이 있습니다. 테마, 사용자가 부당한 광고에 대해 불만을 제기할 수 있는 경우에는 많은 예가 있습니다. 2016년에는 심지어 비디오 광고 러시아어로(예, 광고 차단 브라우저 광고).

이 글을 쓰는 시점에 UC Browser는 Google Play에서 500억 건 이상 설치되었습니다. 이는 인상적입니다. Google Chrome에만 더 많은 기능이 있습니다. 리뷰 중에는 광고에 대한 불만 사항과 Google Play의 일부 애플리케이션으로의 리디렉션을 볼 수 있습니다. 이것이 우리 연구의 이유였습니다. 우리는 UC 브라우저가 뭔가 나쁜 일을 하고 있는지 알아보기로 결정했습니다. 그리고 그가 그랬다는 것이 밝혀졌습니다!

애플리케이션 코드에서는 실행 가능한 코드를 다운로드하고 실행하는 기능이 발견됐고, 이는 애플리케이션 게시 규칙에 위배됩니다. Google Play에서. 실행 가능한 코드를 다운로드하는 것 외에도 UC Browser는 안전하지 않은 방식으로 다운로드를 수행하므로 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를 열려고 하면 위에 지정된 주소로 두 번째 요청을 한 후 기본 라이브러리를 다운로드한다는 것을 발견했습니다. 공격을 수행하기 위해 우리는 UC 브라우저의 기능인 APK에 없고 필요한 경우 인터넷에서 다운로드하는 기본 라이브러리를 사용하여 PDF를 여는 기능을 사용하기로 결정했습니다. 이론적으로 UC 브라우저는 브라우저가 시작된 후 실행되는 요청에 대해 올바른 형식의 응답을 제공하는 경우 사용자 상호 작용 없이 강제로 무언가를 다운로드할 수 있다는 점에 주목할 가치가 있습니다. 하지만 이렇게 하려면 서버와의 상호 작용 프로토콜을 더 자세히 연구해야 하므로 가로채는 응답을 편집하고 PDF 작업을 위해 라이브러리를 교체하는 것이 더 쉬울 것이라고 결정했습니다.

따라서 사용자가 브라우저에서 직접 PDF를 열려고 하면 트래픽에서 다음 요청이 표시될 수 있습니다.

먼저 POST 요청이 있습니다. puds.ucweb.com/upgrade/index.xhtml그 후
PDF 및 Office 형식을 볼 수 있는 라이브러리가 포함된 아카이브가 다운로드됩니다. 첫 번째 요청이 시스템에 대한 정보(적어도 필요한 라이브러리를 제공하기 위한 아키텍처)를 전송하고 이에 대한 응답으로 브라우저가 다운로드해야 하는 라이브러리에 대한 일부 정보(주소 및 가능한 경우)를 수신한다고 가정하는 것이 논리적입니다. , 다른 것. 문제는 이 요청이 암호화되어 있다는 것입니다.

조각 요청

답변 조각

라이브러리 자체는 ZIP으로 패키지되어 있으며 암호화되지 않습니다.

트래픽 복호화 코드 검색

서버 응답을 해독해 보겠습니다. 클래스 코드를 살펴보자 com.uc.deployment.UpgradeDeployService: 메소드에서 시작 명령 이동 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인지, 세 번째 바이트가 0xD1인지, 두 번째 바이트가 11, 0 또는 1x0F인지 확인합니다. 서버의 응답을 살펴보겠습니다. 60바이트는 0x1, 두 번째 바이트는 0x60F, 세 번째 바이트는 XNUMXxXNUMX입니다. 우리에게 꼭 필요한 것 같군요. 행(예: "up_decrypt")으로 판단하면 서버의 응답을 해독하는 메서드가 여기에서 호출되어야 합니다.
방법으로 넘어 갑시다 gj. 첫 번째 인수는 오프셋 2(예: 우리의 경우 0x1F)에 있는 바이트이고 두 번째 인수는 오프셋이 없는 서버 응답입니다.
처음 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와 동일한 경우는 세 가지 가능한 옵션 중 하나를 나타냅니다.

우리는 계속해서 코드를 분석합니다. 몇 번의 점프 후에 우리는 설명이 필요 없는 이름을 가진 메소드에 도달하게 되었습니다. decryptBytesByKey.

여기에서는 응답에서 두 바이트가 더 분리되고 그로부터 문자열이 얻어집니다. 이런 방식으로 메시지를 해독하기 위한 키가 선택된다는 것은 분명합니다.

    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)로 보완됩니다.
모든 것, 2는 메서드에서와 같이 암호 해독을 의미합니다. doFinal 시스템 클래스 javax.crypto.Cipher. 그리고 이 모든 것은 번호 10601을 가진 특정 라우터로 전송됩니다. 이것은 분명히 명령 번호입니다.

다음 전환 체인 후에 인터페이스를 구현하는 클래스를 찾습니다. IRouterComponent 및 방법 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도서관, 네이티브 메소드가 선언됨 doCommandNative:

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

이는 네이티브 코드에서 메서드를 찾아야 함을 의미합니다. doCommandNative. 그리고 이것이 재미가 시작되는 곳입니다.

기계어 코드 난독화

파일에서 libsgmain.so (실제로는 .jar이고 바로 위에서 일부 암호화 관련 인터페이스의 구현을 찾았습니다.) 하나의 기본 라이브러리가 있습니다. libsgmainso-6.4.36.so. IDA에서 열면 오류가 있는 대화 상자가 많이 나타납니다. 문제는 섹션 헤더 테이블이 유효하지 않다는 것입니다. 이는 분석을 복잡하게 만들기 위해 의도적으로 수행됩니다.

그러나 이는 필요하지 않습니다. ELF 파일을 올바르게 로드하고 분석하려면 프로그램 헤더 테이블이면 충분합니다. 따라서 섹션 테이블을 삭제하고 헤더의 해당 필드를 XNUMX으로 만듭니다.

IDA에서 파일을 다시 엽니다.

Java 코드에서 네이티브로 선언된 메소드의 구현이 네이티브 라이브러리의 정확히 어디에 있는지 Java 가상 머신에 알려주는 방법에는 두 가지가 있습니다. 첫 번째는 종 이름을 지정하는 것입니다. Java_package_name_ClassName_MethodName.

두 번째는 라이브러리를 로드할 때 등록하는 것입니다(함수에서 JNI_OnLoad)
함수 호출을 사용하여 등록원주민.

우리의 경우 첫 번째 방법을 사용하면 이름은 다음과 같아야 합니다. Java_com_taobao_wireless_security_adapter_JNICLibrary_doCommandNative.

내보낸 함수 중에는 해당 함수가 없으므로 호출을 찾아야 함을 의미합니다. 등록원주민.
함수로 가보자 JNI_OnLoad 그리고 우리는 이 사진을 봅니다:

여기서 무슨 일이 일어나고 있는 걸까요? 언뜻 보기에 함수의 시작과 끝은 ARM 아키텍처에서 일반적입니다. 스택의 첫 번째 명령어는 함수가 작업에 사용할 레지스터(이 경우 R0, R1 및 R2)의 내용과 함수의 반환 주소가 포함된 LR 레지스터의 내용을 저장합니다. . 마지막 명령어는 저장된 레지스터를 복원하고 반환 주소는 즉시 PC 레지스터에 배치되므로 함수에서 반환됩니다. 그러나 자세히 살펴보면 끝에서 두 번째 명령어가 스택에 저장된 반환 주소를 변경한다는 것을 알 수 있습니다. 나중에 어떻게 될지 계산해 봅시다
코드 실행. 특정 주소 1xB0이 R130에 로드되고 거기에서 5를 뺀 다음 R0으로 전송되고 0x10이 추가됩니다. 0xB13B로 나타납니다. 따라서 IDA는 마지막 명령어가 정상적인 함수 리턴이라고 생각하지만 실제로는 계산된 주소 0xB13B로 가는 것입니다.

여기서 ARM 프로세서에는 ARM과 Thumb이라는 두 가지 모드와 두 가지 명령어 세트가 있다는 점을 기억할 가치가 있습니다. 주소의 최하위 비트는 어떤 명령어 세트가 사용되고 있는지 프로세서에 알려줍니다. 즉, 실제 주소는 0xB13A이고 최하위 비트 중 하나는 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에 위치한 것을 보면 주소 테이블과 비슷한 것을 볼 수 있습니다:

이 디자인을 패치하려면 코드에서 두 개의 매개변수, 즉 오프셋과 결과를 넣을 레지스터 번호를 가져와야 합니다. 가능한 각 등록에 대해 미리 코드를 준비해야 합니다.

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 Browser에서 함수 코드를 받았습니다. 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);

기능 중 sub_73E24 클래스 이름이 분명히 해독되고 있습니다. 이 함수의 매개변수로는 암호화된 데이터와 유사한 데이터에 대한 포인터, 특정 버퍼 및 숫자가 전달됩니다. 분명히 함수를 호출한 후에는 함수에 전달되기 때문에 버퍼에 해독된 라인이 있을 것입니다. 클래스 찾기, 클래스 이름을 두 번째 매개변수로 사용합니다. 따라서 숫자는 버퍼의 크기 또는 줄의 길이입니다. 클래스 이름을 해독해 봅시다. 클래스 이름은 우리가 올바른 방향으로 가고 있는지 알려줄 것입니다. 에서 무슨 일이 일어나는지 자세히 살펴 보겠습니다. sub_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;
}

기능 sub_7AF78 지정된 크기의 바이트 배열에 대한 컨테이너 인스턴스를 생성합니다(이러한 컨테이너에 대해서는 자세히 설명하지 않습니다). 여기에 두 개의 컨테이너가 생성됩니다. 하나는 다음 줄을 포함합니다. "DcO/lcK+h?m3c*q@" (이것은 키라고 추측하기 쉽습니다), 다른 하나는 암호화된 데이터를 포함합니다. 다음으로, 두 객체 모두 특정 구조에 배치되고, 이는 함수에 전달됩니다. sub_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;
}

스위치 매개변수는 이전에 값 3이 할당된 구조 필드입니다. 사례 3을 살펴보세요. sub_6364C 매개변수는 이전 함수에 추가된 구조(예: 키 및 암호화된 데이터)에서 전달됩니다. 자세히 살펴보면 sub_6364C, RC4 알고리즘을 인식할 수 있습니다.

우리에게는 알고리즘과 키가 있습니다. 클래스 이름을 해독해 봅시다. 일어난 일은 다음과 같습니다. com/taobao/wireless/security/adapter/JNICLibrary. 엄청난! 우리는 올바른 길을 가고 있습니다.

명령 트리

이제 우리는 도전을 찾아야 합니다 등록원주민, 이는 우리에게 함수를 알려줄 것입니다 doCommandNative. 호출되는 함수를 살펴보겠습니다. JNI_OnLoad, 그리고 우리는 그것을 발견합니다 sub_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;
}

그리고 실제로 여기에 이름이 붙은 네이티브 메소드가 등록되어 있습니다. doCommandNative. 이제 우리는 그의 주소를 알고 있습니다. 그가 무엇을 하는지 봅시다.

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에 관심이 있습니다.

코드에서 명령 번호가 세 개의 숫자를 생성하는 것을 볼 수 있습니다. 명령/10000, 명령 % 10000 / 100 и 명령 % 10, 즉, 우리의 경우에는 1, 6, 1입니다. 이 세 숫자와 포인터는 다음과 같습니다. JNIEnv 함수에 전달된 인수는 구조에 추가되어 전달됩니다. 얻은 세 개의 숫자(N1, N2 및 N3로 표시)를 사용하여 명령 트리가 구축됩니다.

이 같은:

트리는 동적으로 채워집니다. JNI_OnLoad.
세 개의 숫자가 트리의 경로를 인코딩합니다. 트리의 각 잎에는 해당 함수의 포켓 주소가 포함되어 있습니다. 키는 상위 노드에 있습니다. 사용된 모든 구조를 이해한다면 코드에서 필요한 함수가 트리에 추가되는 위치를 찾는 것이 어렵지 않습니다(이미 큰 문서를 부풀리지 않기 위해 설명하지 않습니다).

더 난독화

트래픽을 해독해야 하는 함수의 주소: 0x5F1AC를 받았습니다. 하지만 기뻐하기에는 아직 이르습니다. UC 브라우저 개발자가 우리를 위해 또 다른 놀라움을 준비했습니다.

Java 코드로 구성된 배열에서 매개변수를 수신한 후 다음을 얻습니다.
주소 0x4D070의 함수에. 그리고 또 다른 유형의 코드 난독화가 우리를 기다리고 있습니다.

R7과 R4에 두 개의 인덱스를 넣습니다.

첫 번째 인덱스를 R11로 이동합니다.

테이블에서 주소를 얻으려면 인덱스를 사용하십시오.

첫 번째 주소로 이동한 후 R4에 있는 두 번째 인덱스가 사용됩니다. 테이블에는 230개의 요소가 있습니다.

어떻게 해야 할까요? 편집 -> 기타 -> 스위치 관용어 지정을 통해 IDA에 이것이 스위치임을 알릴 수 있습니다.

결과 코드는 무섭습니다. 하지만 정글을 헤쳐나가다 보면 이미 우리에게 친숙한 함수가 호출되는 것을 볼 수 있습니다. sub_6115C:

사례 3의 경우 RC4 알고리즘을 사용하여 암호를 해독하는 스위치가 있었습니다. 그리고 이 경우 함수에 전달된 구조는 전달된 매개변수로 채워집니다. doCommandNative. 우리가 거기에서 무엇을 가졌는지 기억하자 매직인트 값은 16입니다. 해당 사례를 살펴보고 여러 번의 전환 후에 알고리즘을 식별할 수 있는 코드를 찾습니다.

AES 입니다!

알고리즘은 존재하며, 남은 것은 해당 매개변수(모드, 키 및 초기화 벡터)를 얻는 것뿐입니다(해당 존재 여부는 AES 알고리즘의 작동 모드에 따라 다름). 이를 포함하는 구조는 함수 호출 이전 어딘가에 형성되어야 합니다. sub_6115C, 그러나 코드의 이 부분은 특히 난독화되어 있으므로 해독 기능의 모든 매개변수가 파일에 덤프되도록 코드를 패치하는 아이디어가 떠오릅니다.

패치

모든 패치 코드를 어셈블리 언어로 수동으로 작성하지 않으려면 Android Studio를 실행하고 복호화 함수와 동일한 입력 매개변수를 수신하여 파일에 쓰는 함수를 작성한 다음 컴파일러가 수행할 코드를 복사하여 붙여넣을 수 있습니다. 생성하다.

UC 브라우저 팀의 친구들도 코드 추가의 편의성을 고려했습니다. 각 함수의 시작 부분에는 다른 함수로 쉽게 대체될 수 있는 가비지 코드가 있다는 것을 기억하세요. 매우 편리합니다 🙂 하지만 대상 함수 시작 부분에 모든 매개변수를 파일에 저장하는 코드를 위한 공간이 부족합니다. 나는 그것을 여러 부분으로 나누고 인접한 기능의 가비지 블록을 사용해야 했습니다. 총 XNUMX개의 부분이 있었습니다.

Первая의 часть :

ARM 아키텍처에서 처음 0개의 함수 매개변수는 레지스터 R3-R0을 통해 전달되고, 나머지는 스택을 통해 전달됩니다. LR 레지스터는 복귀 주소를 전달합니다. 매개변수를 덤프한 후 함수가 작동할 수 있도록 이 모든 것을 저장해야 합니다. 또한 프로세스에서 사용할 모든 레지스터를 저장해야 하므로 PUSH.W {R10-R7,LR}을 수행합니다. RXNUMX에서는 스택을 통해 함수에 전달된 매개변수 목록의 주소를 얻습니다.

기능 사용 포펜 파일을 열어보자 /데이터/로컬/tmp/aes "ab" 모드에서
즉, 추가를 위해. R0에서는 파일 이름의 주소를 로드하고, R1에서는 모드를 나타내는 줄의 주소를 로드합니다. 여기서 가비지 코드가 종료되므로 다음 기능으로 넘어갑니다. 계속 작동하기 위해 우리는 처음에 가비지를 우회하여 함수의 실제 코드로의 전환을 배치하고 가비지 대신 패치의 연속을 추가합니다.

부름 포펜.

함수의 처음 세 매개변수 에이스 유형이 있다 INT. 처음에 레지스터를 스택에 저장했으므로 간단히 함수를 전달할 수 있습니다. 쓰기 스택에 있는 주소입니다.

다음으로 데이터 크기와 키, 초기화 벡터 및 암호화된 데이터에 대한 데이터에 대한 포인터를 포함하는 세 가지 구조가 있습니다.

마지막으로 파일을 닫고 레지스터를 복원한 후 제어권을 실제 기능으로 이전합니다. 에이스.

패치된 라이브러리가 포함된 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에 해당 이름의 폴더를 생성하고 거기에 Squirrel 브라우저 인증서를 추가해 보겠습니다.

우리는 조립, 서명, 설치, 출시를 진행합니다. 빙고! 우리는 열쇠를 가지고 있습니다!

MitM

우리는 키와 키와 동일한 초기화 벡터를 받았습니다. CBC 모드에서 서버 응답의 암호를 해독해 보겠습니다.

MD5, "extract_unzipsize" 및 숫자와 유사한 아카이브 URL이 표시됩니다. 확인합니다: 아카이브의 MD5가 동일하고, 압축을 푼 라이브러리의 크기가 동일합니다. 우리는 이 라이브러리를 패치하여 브라우저에 제공하려고 합니다. 패치된 라이브러리가 로드되었음을 보여주기 위해 "PWNED!"라는 텍스트가 포함된 SMS를 생성하려는 인텐트를 실행합니다. 서버의 두 가지 응답을 대체합니다. puds.ucweb.com/upgrade/index.xhtml 그리고 아카이브를 다운로드합니다. 첫 번째에서는 MD5를 교체하고(압축을 푼 후에도 크기는 변경되지 않음) 두 번째에서는 패치된 라이브러리로 아카이브를 제공합니다.

브라우저가 아카이브를 여러 번 다운로드하려고 시도한 후 오류가 발생합니다. 분명히 뭔가
그는 좋아하지 않는다. 이 불분명한 형식을 분석한 결과 서버가 아카이브의 크기도 전송하는 것으로 나타났습니다.

LEB128로 인코딩됩니다. 패치 이후에는 라이브러리가 포함된 아카이브의 크기가 조금 변경되어 브라우저에서는 해당 아카이브가 비뚤게 다운로드된 것으로 간주하여 여러 번 시도한 끝에 오류가 발생했습니다.

아카이브의 크기를 조정합니다... 그리고 – 승리! 🙂 결과는 영상에 있습니다.

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

결과 및 개발자 반응

마찬가지로 해커는 UC 브라우저의 안전하지 않은 기능을 이용해 악성 라이브러리를 배포하고 실행할 수 있습니다. 이러한 라이브러리는 브라우저의 컨텍스트에서 작동하므로 모든 시스템 권한을 받게 됩니다. 결과적으로 피싱 창을 표시하는 기능과 데이터베이스에 저장된 로그인, 비밀번호 및 쿠키를 포함하여 주황색 중국 다람쥐의 작업 파일에 대한 액세스 기능이 제공됩니다.

우리는 UC 브라우저 개발자에게 연락하여 우리가 발견한 문제에 대해 알리고 취약점과 위험성을 지적하려고 노력했지만 그들은 우리와 아무런 논의도 하지 않았습니다. 한편, 브라우저는 눈에 잘 띄는 위험한 기능을 계속해서 과시했습니다. 하지만 일단 취약점의 세부사항이 공개되자 더 이상 예전처럼 이를 무시할 수 없었습니다. 27월 XNUMX일은
HTTPS를 통해 서버에 액세스하는 UC Browser 12.10.9.1193의 새 버전이 출시되었습니다. puds.ucweb.com/upgrade/index.xhtml.

또한 "수정" 이후 이 기사를 작성할 때까지 브라우저에서 PDF를 열려고 하면 "죄송합니다. 문제가 발생했습니다!"라는 텍스트와 함께 오류 메시지가 표시되었습니다. PDF를 열려고 할 때 서버에 대한 요청이 이루어지지 않았지만 브라우저가 시작될 때 요청이 이루어졌습니다. 이는 Google Play 규칙을 위반하여 실행 가능한 코드를 계속 다운로드할 수 있음을 암시합니다.

출처 : habr.com