מחפש נקודות תורפה בדפדפן UC

מבוא

בסוף מרץ אנחנו דיווח, שהם גילו יכולת נסתרת לטעון ולהריץ קוד לא מאומת בדפדפן UC. היום נבחן בפירוט כיצד הורדה זו מתרחשת וכיצד האקרים יכולים להשתמש בה למטרותיהם.

לפני זמן מה, UC Browser פורסם והופץ בצורה מאוד אגרסיבית: הוא הותקן על מכשירי המשתמשים באמצעות תוכנות זדוניות, שהופץ מאתרים שונים במסווה של קבצי וידאו (כלומר, משתמשים חשבו שהם מורידים, למשל, סרטון פורנו, אבל במקום זאת קיבל APK עם הדפדפן הזה), השתמש באנרים מפחידים עם הודעות שהדפדפן מיושן, פגיע ודברים כאלה. בקבוצת הדפדפנים הרשמית של UC ב-VK יש נושא, שבו משתמשים יכולים להתלונן על פרסום לא הוגן, יש שם דוגמאות רבות. ב-2016 היה אפילו פרסום וידאו ברוסית (כן, פרסום לדפדפן חוסם פרסומות).

בזמן הכתיבה, ל-UC Browser יש יותר מ-500 התקנות ב-Google Play. זה מרשים - רק לגוגל כרום יש יותר. בין הביקורות ניתן לראות לא מעט תלונות על פרסום והפניות לחלק מהאפליקציות ב-Google Play. זו הייתה הסיבה למחקר שלנו: החלטנו לראות אם UC Browser עושה משהו רע. והתברר שכן!

בקוד האפליקציה, התגלתה היכולת להוריד ולהפעיל קוד הפעלה, דבר המנוגד לכללי פרסום בקשות ב-Google Play. בנוסף לעובדה ש-UC Browser מוריד קוד הפעלה, הוא עושה זאת בצורה לא מאובטחת, שבאמצעותה ניתן לבצע מתקפת MitM. בוא נראה אם ​​נוכל לבצע פיגוע כזה.

כל מה שנכתב להלן רלוונטי לגרסה של דפדפן UC שהייתה זמינה ב-Google Play בזמן המחקר:

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: היכולת לפתוח PDF באמצעות ספרייה מקורית, שאינה ב-APK ואשר היא מורידה מהאינטרנט במידת הצורך. ראוי לציין כי באופן תיאורטי, ניתן לאלץ את UC Browser להוריד משהו ללא אינטראקציה של המשתמש - אם תספק תגובה מעוצבת היטב לבקשה שמתבצעת לאחר הפעלת הדפדפן. אבל כדי לעשות זאת, עלינו ללמוד את פרוטוקול האינטראקציה עם השרת ביתר פירוט, אז החלטנו שיהיה קל יותר לערוך את התגובה המיירטת ולהחליף את הספרייה לעבודה עם PDF.

לכן, כאשר משתמש רוצה לפתוח קובץ PDF ישירות בדפדפן, ניתן לראות את הבקשות הבאות בתנועה:

ראשית יש בקשת POST ל puds.ucweb.com/upgrade/index.xhtmlאז
הורדה של ארכיון עם ספרייה לצפייה בפורמטים של PDF ו-Office. הגיוני להניח שהבקשה הראשונה מעבירה מידע על המערכת (לפחות הארכיטקטורה לספק את הספרייה הנדרשת), ובתגובה לה הדפדפן מקבל מידע מסוים על הספרייה שצריך להוריד: הכתובת ואפשר , משהו אחר. הבעיה היא שהבקשה הזו מוצפנת.

בקש קטע

קטע תשובה

הספרייה עצמה ארוזה ב-ZIP ואינה מוצפנת.

חפש קוד פענוח תעבורה

בואו ננסה לפענח את תגובת השרת. בואו נסתכל על קוד הכיתה com.uc.deployment.UpgradeDeployService: מתוך שיטה onStartCommand לך ל 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");
}
}

השיטה לוקחת מערך של בתים כקלט ובודקת שהבייט האפס הוא 0x60 או שהבייט השלישי הוא 0xD0, והבייט השני הוא 1, 11 או 0x1F. אנו מסתכלים על התגובה מהשרת: הבת האפס הוא 0x60, השני הוא 0x1F, השלישי הוא 0x60. נשמע כמו מה שאנחנו צריכים. אם לשפוט לפי השורות ("up_decrypt", למשל), יש לקרוא כאן שיטה שתפענח את תגובת השרת.
נעבור לשיטה gj. שימו לב שהארגומנט הראשון הוא ה-byte ב-offset 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, מזהה המפתח, הנתונים המוצפנים ומחרוזת בלתי מובנת (במקרה שלנו, ריקה).

    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, אלא .צנצנת. השיטה שאנו מעוניינים בה מיושמת באופן הבא:

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 ושיטה doCommand:

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);
}
}

וגם כיתה JNICLibrary, שבו מוצהרת השיטה המקורית 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 ולנתח אותו, מספיקה טבלת כותרות של תוכנית. לכן, אנו פשוט מוחקים את טבלת הסעיפים, ומאפסים את השדות המתאימים בכותרת.

פתח שוב את הקובץ ב-IDA.

ישנן שתי דרכים לומר למכונה הוירטואלית של Java היכן בדיוק בספרייה המקורית נמצא היישום של שיטה המוצהרת בקוד Java כ-native. הראשון הוא לתת לו שם מין Java_package_name_ClassName_MethodName.

השני הוא לרשום אותו בעת טעינת הספרייה (בפונקציה JNI_OnLoad)
באמצעות קריאת פונקציה RegisterNatives.

במקרה שלנו, אם נשתמש בשיטה הראשונה, השם צריך להיות כך: Java_com_taobao_wireless_security_adapter_JNICLibrary_doCommandNative.

אין פונקציה כזו בין הפונקציות המיוצאות, מה שאומר שאתה צריך לחפש שיחה RegisterNatives.
בוא נלך לפונקציה 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, מתווספת לכתובת זו, ולאחר מכן לוקחים את הערך בכתובת המתקבלת ומעלים אותה על הערימה. כמו כן, 4 מתווסף ל-LR כך שאחרי החזרה מהפונקציה, אותו היסט ידלג. לאחר מכן הפקודה 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 וקיבל את קוד הפונקציה 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 שם המחלקה מפוענח בבירור. כפרמטרים לפונקציה זו, מעבירים מצביע לנתונים הדומים לנתונים מוצפנים, מאגר מסוים ומספר. ברור שלאחר קריאה לפונקציה תהיה שורה מפוענחת במאגר, מכיוון שהיא מועברת לפונקציה FindClass, אשר לוקח את שם המחלקה כפרמטר השני. לכן, המספר הוא גודל המאגר או אורך הקו. בואו ננסה לפענח את שם הכיתה, הוא אמור להגיד לנו אם אנחנו הולכים בכיוון הנכון. בואו נסתכל מקרוב על מה שקורה ב 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. גדול! אנחנו בדרך הנכונה.

עץ פקודות

עכשיו אנחנו צריכים למצוא אתגר RegisterNatives, שיכוון אותנו לפונקציה 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 Browser הכינו לנו הפתעה נוספת.

לאחר קבלת הפרמטרים מהמערך שנוצר בקוד ה-Java, אנו מקבלים
לפונקציה בכתובת 0x4D070. והנה עוד סוג של ערפול קוד מחכה לנו.

שמנו שני מדדים ב-R7 ו-R4:

אנו מעבירים את המדד הראשון ל-R11:

כדי לקבל כתובת מטבלה, השתמש באינדקס:

לאחר מעבר לכתובת הראשונה, נעשה שימוש באינדקס השני, שהוא ב-R4. יש 230 אלמנטים בטבלה.

מה לעשות בנידון? אתה יכול להגיד ל-IDA שזהו מתג: ערוך -> אחר -> ציין לשון מתג.

הקוד שנוצר מפחיד. אבל כשאתה עושה את דרכך בג'ונגל שלו, אתה יכול להבחין בקריאה לפונקציה שכבר מוכרת לנו sub_6115C:

היה מתג שבו במקרה 3 היה פענוח באמצעות אלגוריתם RC4. ובמקרה זה, המבנה המועבר לפונקציה מתמלא מהפרמטרים שהועברו אליו doCommandNative. בואו נזכור מה היה לנו שם magicInt עם הערך 16. אנו מסתכלים על המקרה המתאים - ולאחר מספר מעברים אנו מוצאים את הקוד שבאמצעותו ניתן לזהות את האלגוריתם.

זה AES!

האלגוריתם קיים, כל שנותר הוא להשיג את הפרמטרים שלו: מצב, מפתח ואולי גם וקטור האתחול (נוכחותו תלויה במצב הפעולה של אלגוריתם AES). המבנה איתם חייב להיווצר איפשהו לפני קריאת הפונקציה sub_6115C, אבל החלק הזה של הקוד מעורפל היטב, ולכן עולה הרעיון לתקן את הקוד כך שכל הפרמטרים של פונקציית הפענוח ייזרקו לקובץ.

תיקון

כדי לא לכתוב את כל קוד התיקון בשפת assembly באופן ידני, אפשר להפעיל את Android Studio, לכתוב שם פונקציה שמקבלת את אותם פרמטרי קלט כמו פונקציית הפענוח שלנו וכותבת לקובץ, ואז להעתיק ולהדביק את הקוד שהקומפיילר יעשה. לִיצוֹר.

חברינו מצוות דפדפן UC דאגו גם הם לנוחות של הוספת קוד. בואו נזכור שבתחילת כל פונקציה יש לנו קוד זבל שניתן להחליף בקלות בכל קוד אחר. נוח מאוד 🙂 עם זאת, בתחילת פונקציית המטרה אין מספיק מקום לקוד ששומר את כל הפרמטרים לקובץ. נאלצתי לפצל אותו לחלקים ולהשתמש בלוקי אשפה מפונקציות שכנות. היו ארבעה חלקים בסך הכל.

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

בארכיטקטורת ARM, ארבעת הפרמטרים הראשונים של הפונקציה מועברים דרך האוגרים R0-R3, השאר, אם בכלל, מועברים דרך המחסנית. פנקס LR נושא את כתובת ההחזרה. כל זה צריך להישמר כדי שהפונקציה תוכל לעבוד לאחר שנשמט את הפרמטרים שלה. אנחנו צריכים גם לשמור את כל הרגיסטרים שבהם נשתמש בתהליך, אז אנחנו עושים PUSH.W {R0-R10,LR}. ב-R7 נקבל את הכתובת של רשימת הפרמטרים המועברים לפונקציה דרך המחסנית.

באמצעות פונקציה פופ בואו נפתח את הקובץ /data/local/tmp/aes במצב "ab".
כלומר לתוספת. ב-R0 אנו טוענים את הכתובת של שם הקובץ, ב-R1 - הכתובת של השורה המציינת את המצב. וכאן מסתיים קוד הזבל, אז נעבור לפונקציה הבאה. כדי שזה ימשיך לעבוד, שמנו בהתחלה את המעבר לקוד האמיתי של הפונקציה, עוקף את הזבל, ובמקום הזבל מוסיפים המשך של התיקון.

יִעוּד פופ.

שלושת הפרמטרים הראשונים של הפונקציה AES יש סוג int. מכיוון ששמרנו את הרשמים לערימה בהתחלה, אנחנו יכולים פשוט להעביר את הפונקציה לכתוב הכתובות שלהם על הערימה.

לאחר מכן יש לנו שלושה מבנים המכילים את גודל הנתונים ומצביע לנתונים עבור המפתח, וקטור האתחול ונתונים מוצפנים.

בסיום, סגור את הקובץ, שחזר את האוגרים והעביר את השליטה לפונקציה האמיתית AES.

אנו אוספים APK עם ספריית תיקון, חותמים עליו, מעלים אותו למכשיר/האמולטור ומפעילים אותו. אנחנו רואים שהמזבלה שלנו נוצרת, ונכתבים שם הרבה נתונים. הדפדפן משתמש בהצפנה לא רק לתעבורה, וכל ההצפנה עוברת דרך הפונקציה המדוברת. אבל משום מה הנתונים הדרושים אינם שם, והבקשה הנדרשת אינה נראית בתנועה. כדי לא לחכות עד ש- UC Browser יעשה את הבקשה הדרושה, בואו ניקח את התגובה המוצפנת מהשרת שהתקבלה קודם לכן ונתקן שוב את האפליקציה: הוסף את הפענוח ל-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

אנחנו מרכיבים, חותמים, מתקינים, משיקים. אנו מקבלים NullPointerException כי השיטה החזירה null.

במהלך ניתוח נוסף של הקוד, התגלתה פונקציה המפענחת שורות מעניינות: "META-INF/" ו-".RSA". נראה שהאפליקציה מאמתת את האישור שלה. או אפילו מייצר מפתחות ממנו. אני לא באמת רוצה להתעסק במה שקורה עם התעודה, אז פשוט נשליך לה את התעודה הנכונה. בואו נתקן את השורה המוצפנת כך שבמקום "META-INF/" נקבל את "BLABLINF/", ניצור תיקיה בשם זה ב-APK ונוסיף שם את תעודת דפדפן הסנאי.

אנחנו מרכיבים, חותמים, מתקינים, משיקים. בינגו! יש לנו את המפתח!

MitM

קיבלנו מפתח ווקטור אתחול השווים למפתח. בואו ננסה לפענח את תגובת השרת במצב CBC.

אנו רואים את כתובת האתר של הארכיון, משהו דומה ל-MD5, "extract_unzipsize" ומספר. אנחנו בודקים: ה-MD5 של הארכיון זהה, גודל הספרייה הלא-ארוזה זהה. אנחנו מנסים לתקן את הספרייה הזו ולתת אותה לדפדפן. כדי להראות שספריית התיקון שלנו נטענה, נשיק כוונה ליצירת SMS עם הטקסט "PWNED!" נחליף שתי תגובות מהשרת: puds.ucweb.com/upgrade/index.xhtml ולהורדת הארכיון. בראשון אנו מחליפים MD5 (הגודל אינו משתנה לאחר פירוק), בשני אנו נותנים את הארכיון עם ספריית התיקון.

הדפדפן מנסה להוריד את הארכיון מספר פעמים, ולאחר מכן הוא נותן שגיאה. כנראה משהו
הוא לא אוהב. כתוצאה מניתוח הפורמט העכור הזה, התברר שהשרת משדר גם את גודל הארכיון:

הוא מקודד ב-LEB128. לאחר התיקון, גודל הארכיון עם הספרייה השתנה מעט, כך שהדפדפן חשב שהארכיון הורד בצורה עקומה, ולאחר מספר ניסיונות הוא זרק שגיאה.

אנחנו מתאימים את גודל הארכיון... וגם – ניצחון! 🙂 התוצאה בסרטון.

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

השלכות ותגובת מפתח

באותו אופן, האקרים יכולים להשתמש בתכונה הלא מאובטחת של דפדפן UC כדי להפיץ ולהפעיל ספריות זדוניות. ספריות אלו יעבדו בהקשר של הדפדפן, כך שהן יקבלו את כל הרשאות המערכת שלו. כתוצאה מכך, היכולת להציג חלונות דיוג, כמו גם גישה לקבצי העבודה של הסנאי הסיני הכתום, כולל כניסות, סיסמאות ועוגיות המאוחסנות במסד הנתונים.

יצרנו קשר עם מפתחי UC Browser ויידענו אותם על הבעיה שמצאנו, ניסינו להצביע על הפגיעות והסכנה שבה, אך הם לא דנו איתנו על דבר. בינתיים, הדפדפן המשיך להתהדר בתכונה המסוכנת שלו לעין. אבל ברגע שחשפנו את פרטי הפגיעות, כבר לא ניתן היה להתעלם ממנה כמו קודם. 27 במרץ היה
שוחררה גרסה חדשה של UC Browser 12.10.9.1193, אשר ניגשה לשרת באמצעות HTTPS: puds.ucweb.com/upgrade/index.xhtml.

בנוסף, לאחר ה"תיקון" ועד למועד כתיבת מאמר זה, ניסיון לפתוח קובץ PDF בדפדפן הביא להודעת שגיאה עם הטקסט "אופס, משהו השתבש!" לא הוגשה בקשה לשרת בעת ניסיון לפתוח קובץ PDF, אך עם הפעלת הדפדפן הוגשה בקשה, מה שמרמז על המשך היכולת להוריד קוד הפעלה בניגוד לכללי Google Play.

מקור: www.habr.com