UC ब्राउझरमध्ये भेद्यता शोधत आहे

परिचय

मार्चच्या शेवटी आम्ही नोंदवले, त्यांना UC ब्राउझरमध्ये असत्यापित कोड लोड करण्याची आणि चालवण्याची लपलेली क्षमता सापडली. आज आपण हे डाउनलोड कसे होते आणि हॅकर्स त्यांच्या स्वतःच्या हेतूंसाठी ते कसे वापरू शकतात याबद्दल तपशीलवारपणे पाहू.

काही काळापूर्वी, UC ब्राउझरची जाहिरात केली गेली आणि अतिशय आक्रमकपणे वितरीत केले गेले: ते मालवेअर वापरून वापरकर्त्यांच्या डिव्हाइसवर स्थापित केले गेले, व्हिडिओ फाइल्सच्या वेषात विविध साइट्सवरून वितरित केले गेले (म्हणजे, वापरकर्त्यांना वाटले की ते डाउनलोड करत आहेत, उदाहरणार्थ, एक अश्लील व्हिडिओ, परंतु त्याऐवजी या ब्राउझरसह एक APK प्राप्त झाले), ब्राउझर जुना, असुरक्षित आणि तत्सम गोष्टींसह संदेश असलेले भितीदायक बॅनर वापरले. व्हीकेवरील अधिकृत यूसी ब्राउझर गटात आहे थीम, ज्यामध्ये वापरकर्ते अयोग्य जाहिरातीबद्दल तक्रार करू शकतात, तेथे अनेक उदाहरणे आहेत. 2016 मध्ये सम होती व्हिडिओ जाहिरात रशियनमध्ये (होय, जाहिरात-ब्लॉकिंग ब्राउझरसाठी जाहिरात).

लेखनाच्या वेळी, UC ब्राउझरची Google Play वर 500 पेक्षा जास्त स्थापना आहेत. हे प्रभावी आहे - फक्त Google Chrome मध्ये अधिक आहे. पुनरावलोकनांमध्ये आपण जाहिरातींबद्दल आणि Google Play वरील काही अनुप्रयोगांवर पुनर्निर्देशित करण्याबद्दल बर्‍याच तक्रारी पाहू शकता. हे आमच्या संशोधनाचे कारण होते: आम्ही UC ब्राउझर काहीतरी वाईट करत आहे की नाही हे पाहण्याचा निर्णय घेतला. आणि असे झाले की तो करतो!

अनुप्रयोग कोडमध्ये, एक्झिक्युटेबल कोड डाउनलोड आणि चालवण्याची क्षमता शोधली गेली, जे अर्ज प्रकाशित करण्याच्या नियमांच्या विरुद्ध आहे Google Play वर. एक्झिक्युटेबल कोड डाउनलोड करण्याव्यतिरिक्त, UC ब्राउझर हे असुरक्षित पद्धतीने करतो, ज्याचा वापर 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" />

ही सेवा सुरू झाल्यावर, ब्राउझर पोस्ट करण्याची विनंती करतो puds.ucweb.com/upgrade/index.xhtml, जे सुरू झाल्यानंतर काही वेळाने रहदारीमध्ये दिसू शकते. प्रतिसादात, त्याला काही अपडेट किंवा नवीन मॉड्यूल डाउनलोड करण्यासाठी कमांड प्राप्त होऊ शकते. विश्लेषणादरम्यान, सर्व्हरने अशा आज्ञा दिल्या नाहीत, परंतु आमच्या लक्षात आले की जेव्हा आम्ही ब्राउझरमध्ये पीडीएफ उघडण्याचा प्रयत्न करतो, तेव्हा ते वर निर्दिष्ट केलेल्या पत्त्यावर दुसरी विनंती करते, त्यानंतर ते मूळ लायब्ररी डाउनलोड करते. हल्ला करण्यासाठी, आम्ही UC ब्राउझरचे हे वैशिष्ट्य वापरण्याचे ठरविले: मूळ लायब्ररी वापरून PDF उघडण्याची क्षमता, जी एपीकेमध्ये नाही आणि आवश्यक असल्यास ती इंटरनेटवरून डाउनलोड करते. हे लक्षात घेण्यासारखे आहे की, सैद्धांतिकदृष्ट्या, UC ब्राउझरला वापरकर्त्याच्या परस्परसंवादाशिवाय काहीतरी डाउनलोड करण्यास भाग पाडले जाऊ शकते - जर तुम्ही ब्राउझर लाँच केल्यानंतर अंमलात आणलेल्या विनंतीला योग्य प्रतिसाद दिला तर. परंतु हे करण्यासाठी, आम्हाला सर्व्हरशी परस्परसंवादाच्या प्रोटोकॉलचा अधिक तपशीलवार अभ्यास करणे आवश्यक आहे, म्हणून आम्ही निर्णय घेतला की खंडित प्रतिसाद संपादित करणे आणि PDF सह कार्य करण्यासाठी लायब्ररी बदलणे सोपे होईल.

म्हणून, जेव्हा वापरकर्ता थेट ब्राउझरमध्ये PDF उघडू इच्छितो, तेव्हा खालील विनंत्या रहदारीमध्ये दिसू शकतात:

प्रथम एक POST विनंती आहे puds.ucweb.com/upgrade/index.xhtml, नंतर
पीडीएफ आणि ऑफिस फॉरमॅट पाहण्यासाठी लायब्ररीसह एक संग्रह डाउनलोड केला जातो. हे गृहीत धरणे तर्कसंगत आहे की प्रथम विनंती सिस्टमबद्दल माहिती प्रसारित करते (किमान आवश्यक लायब्ररी प्रदान करण्यासाठी आर्किटेक्चर), आणि त्यास प्रतिसाद म्हणून ब्राउझरला डाउनलोड करणे आवश्यक असलेल्या लायब्ररीबद्दल काही माहिती प्राप्त होते: पत्ता आणि, शक्यतो , काहीतरी. समस्या अशी आहे की ही विनंती एनक्रिप्ट केलेली आहे.

तुकडा विनंती

उत्तराचा तुकडा

लायब्ररी स्वतः झिपमध्ये पॅकेज केलेली आहे आणि एनक्रिप्ट केलेली नाही.

रहदारी डिक्रिप्शन कोड शोधा

सर्व्हरच्या प्रतिसादाचा उलगडा करण्याचा प्रयत्न करूया. चला वर्ग कोड पाहू 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);
}

आम्ही येथे पोस्ट विनंतीची निर्मिती पाहतो. आम्ही 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. लक्षात घ्या की पहिला युक्तिवाद ऑफसेट 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 नाही तर .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 म्हणजे डिक्रिप्शन, पद्धतीप्रमाणे अंतिम प्रणाली वर्ग 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);
}
}

आणि वर्ग देखील JNICL लायब्ररी, ज्यामध्ये मूळ पद्धत घोषित केली आहे 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 कोडमध्ये घोषित केलेल्या पद्धतीची अंमलबजावणी नेमकी कुठे आहे. प्रथम त्याला प्रजातीचे नाव देणे आहे Java_package_name_ClassName_MethodName.

दुसरे म्हणजे लायब्ररी लोड करताना त्याची नोंदणी करणे (फंक्शनमध्ये JNI_ऑनलोड)
फंक्शन कॉल वापरणे नोंदणीकृत निवासी.

आमच्या बाबतीत, आम्ही पहिली पद्धत वापरल्यास, नाव असे असावे: Java_com_taobao_wireless_security_adapter_JNICLlibrary_doCommandNative.

निर्यात केलेल्या फंक्शन्समध्ये असे कोणतेही फंक्शन नाही, याचा अर्थ आपल्याला कॉल शोधण्याची आवश्यकता आहे नोंदणीकृत निवासी.
चला फंक्शनला जाऊया JNI_ऑनलोड आणि आम्ही हे चित्र पाहतो:

इथे काय चालले आहे? पहिल्या दृष्टीक्षेपात, फंक्शनची सुरुवात आणि शेवट एआरएम आर्किटेक्चरसाठी वैशिष्ट्यपूर्ण आहेत. स्टॅकवरील पहिली सूचना रजिस्टर्सची सामग्री संग्रहित करते जी फंक्शन त्याच्या ऑपरेशनमध्ये वापरेल (या प्रकरणात, R0, R1 आणि R2), तसेच LR रजिस्टरची सामग्री, ज्यामध्ये फंक्शनचा परतावा पत्ता असतो. . शेवटची सूचना जतन केलेली नोंदणी पुनर्संचयित करते आणि परतीचा पत्ता ताबडतोब पीसी रजिस्टरमध्ये ठेवला जातो - अशा प्रकारे फंक्शनमधून परत येतो. परंतु तुम्ही बारकाईने पाहिल्यास, तुमच्या लक्षात येईल की अंतिम सूचना स्टॅकवर संग्रहित रिटर्न पत्ता बदलते. नंतर ते कसे असेल ते मोजूया
कोडची अंमलबजावणी. एक विशिष्ट पत्ता 1xB0 R130 मध्ये लोड केला जातो, त्यातून 5 वजा केला जातो, नंतर तो R0 वर हस्तांतरित केला जातो आणि त्यात 0x10 जोडला जातो. हे 0xB13B बाहेर वळते. अशा प्रकारे, IDA ला वाटते की शेवटची सूचना ही एक सामान्य फंक्शन रिटर्न आहे, परंतु प्रत्यक्षात ती गणना केलेल्या पत्त्यावर 0xB13B आहे.

येथे हे लक्षात ठेवण्यासारखे आहे की एआरएम प्रोसेसरमध्ये दोन मोड आणि सूचनांचे दोन संच आहेत: एआरएम आणि थंब. पत्त्यातील सर्वात कमी महत्त्वाचा भाग प्रोसेसरला सांगते की कोणता निर्देश संच वापरला जात आहे. म्हणजेच, पत्ता प्रत्यक्षात 0xB13A आहे आणि कमीतकमी लक्षणीय बिटपैकी एक थंब मोड दर्शवतो.

या लायब्ररीतील प्रत्येक फंक्शनच्या सुरूवातीला एक समान “अॅडॉप्टर” जोडले गेले आहे आणि
कचरा कोड. आम्ही त्यांच्यावर अधिक तपशीलवार राहणार नाही - आम्हाला फक्त आठवते
की जवळजवळ सर्व फंक्शन्सची खरी सुरुवात थोडी दूर आहे.

कोड स्पष्टपणे 0xB13A वर जात नसल्यामुळे, IDA ने स्वतः ओळखले नाही की कोड या स्थानावर आहे. त्याच कारणास्तव, ते लायब्ररीतील बहुतेक कोड कोड म्हणून ओळखत नाही, ज्यामुळे विश्लेषण काहीसे कठीण होते. आम्ही IDA ला सांगतो की हा कोड आहे आणि हे असे होते:

टेबल स्पष्टपणे 0xB144 पासून सुरू होते. sub_494C मध्ये काय आहे?

एलआर रजिस्टरमध्ये या फंक्शनला कॉल करताना, आम्हाला पूर्वी नमूद केलेल्या टेबलचा पत्ता (0xB144) मिळतो. R0 मध्ये - या टेबलमधील अनुक्रमणिका. म्हणजेच, मूल्य टेबलमधून घेतले जाते, एलआरमध्ये जोडले जाते आणि परिणाम होतो
जाण्यासाठी पत्ता. चला त्याची गणना करण्याचा प्रयत्न करूया: 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 निर्देशानंतर एक ऑफसेट आहे:

आम्ही ऑफसेट एलआर वरून पत्त्यावर घेतो, तो एलआरमध्ये जोडतो आणि तिथे जातो. 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 ला त्याची खरी सुरुवात दर्शवू शकता. हे सर्व फंक्शन कोड एकत्र करेल आणि हेक्सरे वापरून ते विघटित केले जाऊ शकते.

डीकोडिंग स्ट्रिंग

आम्ही लायब्ररीमध्ये मशीन कोडच्या अस्पष्टतेला सामोरे जाण्यास शिकलो आहोत libsgmainso-6.4.36.so UC ब्राउझर वरून आणि फंक्शन कोड प्राप्त केला JNI_ऑनलोड.

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/JNICLlibrary. छान! आम्ही योग्य मार्गावर आहोत.

आज्ञा वृक्ष

आता आपल्याला आव्हान शोधण्याची गरज आहे नोंदणीकृत निवासी, जे आपल्याला फंक्शनकडे निर्देशित करेल doCommandNative. पासून कॉल केलेल्या फंक्शन्स पाहू JNI_ऑनलोड, आणि आम्हाला ते सापडते 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_ऑनलोड.
तीन संख्या झाडातील मार्ग एन्कोड करतात. झाडाच्या प्रत्येक पानामध्ये संबंधित कार्याचा पोक केलेला पत्ता असतो. की पॅरेंट नोडमध्ये आहे. जर आपल्याला वापरलेल्या सर्व रचना समजल्या असतील तर कोडमध्ये आपल्याला आवश्यक असलेले फंक्शन जोडलेले स्थान शोधणे कठीण नाही (आम्ही त्यांचे वर्णन करत नाही जेणेकरून आधीच मोठा लेख फुगवू नये).

अधिक गोंधळ

आम्हाला फंक्शनचा पत्ता प्राप्त झाला ज्याने रहदारी डिक्रिप्ट केली पाहिजे: 0x5F1AC. परंतु आनंद करणे खूप लवकर आहे: UC ब्राउझरच्या विकसकांनी आमच्यासाठी आणखी एक आश्चर्य तयार केले आहे.

Java कोडमध्ये तयार केलेल्या अॅरेमधून पॅरामीटर्स प्राप्त केल्यानंतर, आम्हाला मिळते
0x4D070 पत्त्यावरील कार्यासाठी. आणि इथे आणखी एक प्रकारचा कोड गोंधळ आपली वाट पाहत आहे.

आम्ही R7 आणि R4 मध्ये दोन निर्देशांक ठेवतो:

आम्ही पहिला निर्देशांक R11 वर शिफ्ट करतो:

टेबलवरून पत्ता मिळविण्यासाठी, अनुक्रमणिका वापरा:

पहिल्या पत्त्यावर गेल्यानंतर, दुसरा निर्देशांक वापरला जातो, जो R4 मध्ये आहे. टेबलमध्ये 230 घटक आहेत.

त्याबद्दल काय करावे? तुम्ही IDA ला सांगू शकता की हे एक स्विच आहे: संपादित करा -> इतर -> स्विच आयडिओम निर्दिष्ट करा.

परिणामी कोड भयंकर आहे. परंतु, जंगलातून मार्ग काढत असताना, आपल्याला आधीच परिचित असलेल्या फंक्शनचा कॉल लक्षात येईल sub_6115C:

एक स्विच होता ज्यामध्ये केस 3 मध्ये RC4 अल्गोरिदम वापरून डिक्रिप्शन होते. आणि या प्रकरणात, फंक्शनला पास केलेली रचना पास केलेल्या पॅरामीटर्समधून भरली जाते doCommandNative. आपण तेथे काय होते ते लक्षात ठेवूया magicInt मूल्यासह 16. आम्ही संबंधित केस पाहतो - आणि अनेक संक्रमणांनंतर आम्हाला कोड सापडतो ज्याद्वारे अल्गोरिदम ओळखला जाऊ शकतो.

हे एईएस आहे!

अल्गोरिदम अस्तित्वात आहे, फक्त त्याचे पॅरामीटर्स मिळवणे बाकी आहे: मोड, की आणि शक्यतो, इनिशिएलायझेशन वेक्टर (त्याची उपस्थिती AES अल्गोरिदमच्या ऑपरेटिंग मोडवर अवलंबून असते). त्यांच्यासह रचना फंक्शन कॉलच्या आधी कुठेतरी तयार करणे आवश्यक आहे sub_6115C, परंतु कोडचा हा भाग विशेषतः अस्पष्ट आहे, म्हणून कोड पॅच करण्याची कल्पना उद्भवते जेणेकरून डिक्रिप्शन फंक्शनचे सर्व पॅरामीटर्स फाइलमध्ये टाकले जातील.

पॅच

सर्व पॅच कोड असेंब्ली भाषेत मॅन्युअली लिहू नये म्हणून, तुम्ही अँड्रॉइड स्टुडिओ लाँच करू शकता, तेथे एक फंक्शन लिहू शकता जे आमच्या डिक्रिप्शन फंक्शनसारखेच इनपुट पॅरामीटर्स प्राप्त करते आणि फाइलवर लिहिते, त्यानंतर कंपाइलर करेल तो कोड कॉपी-पेस्ट करा. उत्पन्न करा.

UC ब्राउझर टीममधील आमच्या मित्रांनी देखील कोड जोडण्याच्या सोयीची काळजी घेतली. आपण लक्षात ठेवूया की प्रत्येक फंक्शनच्या सुरुवातीला आपल्याकडे कचरा कोड असतो जो सहजपणे इतर कोणत्याही बरोबर बदलला जाऊ शकतो. खूप सोयीस्कर 🙂 तथापि, लक्ष्य फंक्शनच्या सुरूवातीस कोडसाठी पुरेशी जागा नाही जी फाइलमध्ये सर्व पॅरामीटर्स जतन करते. मला ते भागांमध्ये विभाजित करावे लागले आणि शेजारच्या फंक्शन्समधील कचरा ब्लॉक्स वापरावे लागले. एकूण चार भाग होते.

पहिला भागः

एआरएम आर्किटेक्चरमध्ये, पहिले चार फंक्शन पॅरामीटर्स नोंदणी R0-R3 मधून पास केले जातात, बाकीचे, असल्यास, स्टॅकमधून पास केले जातात. एलआर रजिस्टरमध्ये परतीचा पत्ता असतो. हे सर्व जतन करणे आवश्यक आहे जेणेकरून आम्ही त्याचे पॅरामीटर्स टाकल्यानंतर फंक्शन कार्य करू शकेल. आम्ही प्रक्रियेत वापरणार असलेल्या सर्व रजिस्टर्स देखील सेव्ह करणे आवश्यक आहे, म्हणून आम्ही PUSH.W {R0-R10,LR} करतो. R7 मध्ये आपल्याला स्टॅकद्वारे फंक्शनला पास केलेल्या पॅरामीटर्सच्या सूचीचा पत्ता मिळतो.

फंक्शन वापरणे fopen फाईल उघडू /data/local/tmp/aes "ab" मोडमध्ये
म्हणजे जोडण्यासाठी. R0 मध्ये आम्ही फाइल नावाचा पत्ता लोड करतो, R1 मध्ये - मोड दर्शविणाऱ्या ओळीचा पत्ता. आणि येथे कचरा कोड संपतो, म्हणून आपण पुढील फंक्शनकडे जाऊ. ते कार्य करणे सुरू ठेवण्यासाठी, आम्ही सुरुवातीला फंक्शनच्या वास्तविक कोडमध्ये संक्रमण ठेवले, कचरा बायपास करतो आणि कचराऐवजी आम्ही पॅचची निरंतरता जोडतो.

कॉल करत आहे fopen.

फंक्शनचे पहिले तीन पॅरामीटर्स aes प्रकार आहे int. आम्ही सुरुवातीला स्टॅकमध्ये रजिस्टर सेव्ह केल्यामुळे, आम्ही फंक्शन फक्त पास करू शकतो लिहा स्टॅकवर त्यांचे पत्ते.

पुढे आमच्याकडे तीन स्ट्रक्चर्स आहेत ज्यात डेटा आकार आणि की, इनिशिएलायझेशन व्हेक्टर आणि एनक्रिप्टेड डेटासाठी डेटासाठी पॉइंटर आहे.

शेवटी, फाइल बंद करा, रजिस्टर्स पुनर्संचयित करा आणि वास्तविक कार्यावर नियंत्रण हस्तांतरित करा aes.

आम्ही पॅच केलेल्या लायब्ररीसह 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

आम्ही एकत्र करतो, साइन इन करतो, स्थापित करतो, लॉन्च करतो. आम्हाला NullPointerException प्राप्त झाला कारण पद्धत शून्य झाली.

कोडच्या पुढील विश्लेषणादरम्यान, एक फंक्शन सापडले जे मनोरंजक ओळींचा उलगडा करते: “META-INF/” आणि “.RSA”. असे दिसते की अनुप्रयोग त्याच्या प्रमाणपत्राची पडताळणी करत आहे. किंवा त्यातून कळाही निर्माण करतो. प्रमाणपत्रासोबत जे घडत आहे ते मला खरोखर हाताळायचे नाही, म्हणून आम्ही ते योग्य प्रमाणपत्र स्लिप करू. चला एनक्रिप्टेड लाईन पॅच करू या जेणेकरून “META-INF/” ऐवजी आम्हाला “BLABLINF/” मिळेल, APK मध्ये त्या नावाचे फोल्डर तयार करा आणि तेथे गिलहरी ब्राउझर प्रमाणपत्र जोडा.

आम्ही एकत्र करतो, साइन इन करतो, स्थापित करतो, लॉन्च करतो. बिंगो! आमच्याकडे किल्ली आहे!

MitM

आम्हाला एक की आणि कीच्या बरोबरीचा इनिशिएलायझेशन वेक्टर मिळाला. CBC मोडमध्ये सर्व्हर प्रतिसाद डिक्रिप्ट करण्याचा प्रयत्न करूया.

आम्ही संग्रहण URL पाहतो, MD5 सारखे काहीतरी, “extract_unzipsize” आणि संख्या. आम्ही तपासतो: संग्रहणाचा MD5 समान आहे, अनपॅक केलेल्या लायब्ररीचा आकार समान आहे. आम्ही ही लायब्ररी पॅच करून ब्राउझरला देण्याचा प्रयत्न करत आहोत. आमची पॅच केलेली लायब्ररी लोड झाली आहे हे दाखवण्यासाठी, आम्ही “PWNED!” या मजकुरासह एसएमएस तयार करण्याचा हेतू लाँच करू. आम्ही सर्व्हरवरून दोन प्रतिसाद बदलू: puds.ucweb.com/upgrade/index.xhtml आणि संग्रह डाउनलोड करण्यासाठी. प्रथम आम्ही MD5 पुनर्स्थित करतो (अनपॅक केल्यानंतर आकार बदलत नाही), दुसऱ्यामध्ये आम्ही पॅच केलेल्या लायब्ररीसह संग्रहण देतो.

ब्राउझर अनेक वेळा संग्रहण डाउनलोड करण्याचा प्रयत्न करतो, त्यानंतर तो त्रुटी देतो. वरवर पाहता काहीतरी
त्याला आवडत नाही. या गोंधळलेल्या स्वरूपाचे विश्लेषण केल्यामुळे, असे दिसून आले की सर्व्हर संग्रहणाचा आकार देखील प्रसारित करतो:

हे LEB128 मध्ये एन्कोड केलेले आहे. पॅचनंतर, लायब्ररीसह संग्रहणाचा आकार थोडा बदलला, म्हणून ब्राउझरने असे मानले की संग्रहण कुटिलपणे डाउनलोड केले गेले होते आणि अनेक प्रयत्नांनंतर त्यात त्रुटी आली.

आम्ही संग्रहणाचा आकार समायोजित करतो... आणि - विजय! 🙂 परिणाम व्हिडिओमध्ये आहे.

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

परिणाम आणि विकसक प्रतिक्रिया

त्याच प्रकारे, हॅकर्स दुर्भावनापूर्ण लायब्ररी वितरित आणि चालविण्यासाठी UC ब्राउझरच्या असुरक्षित वैशिष्ट्याचा वापर करू शकतात. ही लायब्ररी ब्राउझरच्या संदर्भात काम करतील, त्यामुळे त्यांना त्याच्या सर्व सिस्टम परवानग्या मिळतील. परिणामी, फिशिंग विंडो प्रदर्शित करण्याची क्षमता, तसेच डेटाबेसमध्ये संग्रहित लॉगिन, पासवर्ड आणि कुकीजसह ऑरेंज चायनीज गिलहरीच्या कार्यरत फाइल्समध्ये प्रवेश.

आम्ही UC ब्राउझरच्या विकसकांशी संपर्क साधला आणि आम्हाला आढळलेल्या समस्येबद्दल त्यांना माहिती दिली, असुरक्षितता आणि त्याचा धोका दर्शविण्याचा प्रयत्न केला, परंतु त्यांनी आमच्याशी काहीही चर्चा केली नाही. दरम्यान, ब्राउझरने त्याचे धोकादायक वैशिष्ट्य साध्या दृष्टीक्षेपात दाखवणे सुरू ठेवले. पण एकदा आम्ही असुरक्षिततेचे तपशील उघड केल्यावर, पूर्वीसारखे दुर्लक्ष करणे शक्य नव्हते. 27 मार्च होता
UC ब्राउझर 12.10.9.1193 ची नवीन आवृत्ती रिलीझ झाली, ज्याने HTTPS द्वारे सर्व्हरवर प्रवेश केला: puds.ucweb.com/upgrade/index.xhtml.

याव्यतिरिक्त, "निराकरण" नंतर आणि हा लेख लिहिण्याच्या वेळेपर्यंत, ब्राउझरमध्ये पीडीएफ उघडण्याचा प्रयत्न केल्यामुळे "अरेरे, काहीतरी चूक झाली!" मजकुरासह एक त्रुटी संदेश आला. पीडीएफ उघडण्याचा प्रयत्न करताना सर्व्हरला विनंती केली गेली नव्हती, परंतु ब्राउझर लॉन्च केल्यावर विनंती केली गेली होती, जी Google Play नियमांचे उल्लंघन करून एक्झिक्युटेबल कोड डाउनलोड करण्याची सतत क्षमता दर्शवते.

स्त्रोत: www.habr.com