🥇 UC ब्राउजरमा कमजोरीहरू खोज्दै

परिचय

मार्चको अन्त्यमा हामीले रिपोर्ट गरियो, कि तिनीहरूले UC ब्राउजरमा अप्रमाणित कोड लोड गर्न र चलाउने लुकेको क्षमता पत्ता लगाए। आज हामी यो डाउनलोड कसरी हुन्छ र ह्याकरहरूले यसलाई आफ्नै उद्देश्यका लागि कसरी प्रयोग गर्न सक्छन् भनेर विस्तृत रूपमा हेर्नेछौं।

केहि समय पहिले, UC ब्राउजरको विज्ञापन गरिएको थियो र धेरै आक्रामक रूपमा वितरण गरिएको थियो: यो प्रयोगकर्ताहरूको उपकरणहरूमा मालवेयर प्रयोग गरेर स्थापना गरिएको थियो, भिडियो फाइलहरूको आडमा विभिन्न साइटहरूबाट वितरण गरिएको थियो (अर्थात, प्रयोगकर्ताहरूले सोचेका थिए कि उनीहरू डाउनलोड गर्दैछन्, उदाहरणका लागि, एक अश्लील भिडियो, तर। यसको सट्टामा यस ब्राउजरको साथ एक APK प्राप्त भयो), ब्राउजर पुरानो, कमजोर, र यस्तै सामानहरू भएको सन्देशहरूका साथ डरलाग्दो ब्यानरहरू प्रयोग गरियो। VK मा आधिकारिक UC ब्राउजर समूह मा छ विषय, जसमा प्रयोगकर्ताहरूले अनुचित विज्ञापनको बारेमा गुनासो गर्न सक्छन्, त्यहाँ धेरै उदाहरणहरू छन्। 2016 मा त्यहाँ पनि थियो भिडियो विज्ञापन रूसीमा (हो, विज्ञापन-ब्लकिङ ब्राउजरको लागि विज्ञापन)।

लेख्ने समयमा, UC ब्राउजरसँग गुगल प्लेमा 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" />

जब यो सेवा सुरु हुन्छ, ब्राउजरले POST अनुरोध गर्दछ puds.ucweb.com/upgrade/index.xhtml, जुन सुरु भएको केहि समय पछि ट्राफिकमा देख्न सकिन्छ। प्रतिक्रियामा, उसले केहि अपडेट वा नयाँ मोड्युल डाउनलोड गर्न आदेश प्राप्त गर्न सक्छ। विश्लेषणको क्रममा, सर्भरले त्यस्ता आदेशहरू दिएन, तर हामीले देख्यौं कि जब हामी ब्राउजरमा पीडीएफ खोल्ने प्रयास गर्छौं, यसले माथि निर्दिष्ट ठेगानामा दोस्रो अनुरोध गर्दछ, त्यसपछि यसले मूल पुस्तकालय डाउनलोड गर्दछ। आक्रमण गर्न, हामीले UC ब्राउजरको यो सुविधा प्रयोग गर्ने निर्णय गर्‍यौं: नेटिभ लाइब्रेरी प्रयोग गरेर PDF खोल्ने क्षमता, जुन APK मा छैन र जुन आवश्यक भएमा इन्टरनेटबाट डाउनलोड हुन्छ। यो ध्यान दिन लायक छ कि, सैद्धान्तिक रूपमा, UC ब्राउजर प्रयोगकर्ता अन्तरक्रिया बिना केहि डाउनलोड गर्न बाध्य हुन सक्छ - यदि तपाइँ ब्राउजर सुरु भएपछि कार्यान्वयन भएको अनुरोधलाई राम्रोसँग बनाइएको प्रतिक्रिया प्रदान गर्नुहुन्छ। तर यो गर्नको लागि, हामीले सर्भरसँगको अन्तरक्रियाको प्रोटोकललाई थप विस्तारमा अध्ययन गर्न आवश्यक छ, त्यसैले हामीले निर्णय गर्यौं कि अवरोधित प्रतिक्रिया सम्पादन गर्न र PDF सँग काम गर्नको लागि पुस्तकालय बदल्न सजिलो हुनेछ।

त्यसोभए, जब प्रयोगकर्ताले ब्राउजरमा सीधा PDF खोल्न चाहन्छ, निम्न अनुरोधहरू ट्राफिकमा देख्न सकिन्छ:

पहिले त्यहाँ POST अनुरोध छ puds.ucweb.com/upgrade/index.xhtmlजस पछि
PDF र अफिस ढाँचाहरू हेर्नको लागि पुस्तकालयको साथ एउटा अभिलेख डाउनलोड गरिएको छ। यो मान्न तार्किक छ कि पहिलो अनुरोधले प्रणालीको बारेमा जानकारी पठाउँछ (कम्तीमा आवश्यक पुस्तकालय प्रदान गर्नको लागि वास्तुकला), र यसको प्रतिक्रियामा ब्राउजरले डाउनलोड गर्न आवश्यक पुस्तकालयको बारेमा केही जानकारी प्राप्त गर्दछ: ठेगाना र, सम्भवतः। , अरु केही। समस्या यो अनुरोध इन्क्रिप्टेड छ।

टुक्रा अनुरोध गर्नुहोस्

उत्तर टुक्रा

पुस्तकालय आफै 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। ध्यान दिनुहोस् कि पहिलो तर्क अफसेट 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 होइन, तर a .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_package_name_ClassName_MethodName.

दोस्रो पुस्तकालय लोड गर्दा यसलाई दर्ता गर्नु हो (प्रकार्यमा JNI_Onload)
एक प्रकार्य कल प्रयोग गर्दै दर्ता निवासीहरू.

हाम्रो अवस्थामा, यदि हामीले पहिलो विधि प्रयोग गर्छौं भने, नाम यस्तो हुनुपर्छ: Java_com_taobao_wireless_security_adapter_JNICLlibrary_doCommandNative.

निर्यात गरिएका प्रकार्यहरू बीचमा त्यस्तो कुनै प्रकार्य छैन, जसको मतलब तपाईंले कल खोज्नु पर्छ दर्ता निवासीहरू.
समारोहमा जाऔं JNI_Onload र हामी यो तस्वीर देख्छौं:

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

यहाँ याद गर्न लायक छ कि ARM प्रोसेसरहरूसँग दुई मोडहरू र निर्देशनहरूको दुई सेटहरू छन्: ARM र थम्ब। ठेगानाको न्यूनतम महत्त्वपूर्ण बिटले प्रोसेसरलाई कुन निर्देशन सेट प्रयोग भइरहेको छ भनी बताउँछ। त्यो हो, ठेगाना वास्तवमा 0xB13A हो, र कम्तिमा महत्त्वपूर्ण बिटमा एउटाले थम्ब मोडलाई संकेत गर्दछ।

यस पुस्तकालयमा प्रत्येक प्रकार्यको सुरुमा समान "एडाप्टर" थपिएको छ र
फोहोर कोड। हामी तिनीहरूलाई थप विवरणमा बस्ने छैनौं - हामी केवल सम्झन्छौं
लगभग सबै प्रकार्यहरूको वास्तविक सुरुवात अलि टाढा छ।

कोड स्पष्ट रूपमा 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 मा संक्रमण हेर्नुहोस्:

आईडीएले फेरि यो क्षेत्रलाई कोडको रूपमा पहिचान गरेन। हामी उनलाई मद्दत गर्छौं र त्यहाँ अर्को डिजाइन देख्छौं:

BLX पछि निर्देशनहरू धेरै अर्थ लाग्दैन, यो केहि प्रकारको विस्थापन जस्तै हो। sub_4964 हेरौं:

र वास्तवमा, यहाँ LR मा रहेको ठेगानामा dword लिइएको छ, यो ठेगानामा थपिएको छ, त्यसपछि नतिजा ठेगानामा मान लिइन्छ र स्ट्याकमा राखिन्छ। साथै, 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 लाई यसको वास्तविक सुरुवातमा देखाउन सक्नुहुन्छ। यसले सबै प्रकार्य कोडहरू सँगै टुक्रा गर्नेछ, र यसलाई हेक्सरे प्रयोग गरेर डिकम्पाइल गर्न सकिन्छ।

डिकोडिङ स्ट्रिङहरू

हामीले पुस्तकालयमा मेसिन कोडको अस्पष्टतासँग सम्झौता गर्न सिकेका छौं 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 कक्षाको नाम स्पष्ट रूपमा डिक्रिप्ट गरिएको छ। यस प्रकार्यको प्यारामिटरहरूको रूपमा, एन्क्रिप्टेड डाटा, एक निश्चित बफर र नम्बरहरू जस्तै डेटाको लागि एक सूचक पास गरिन्छ। स्पष्ट रूपमा, प्रकार्यलाई कल गरेपछि, त्यहाँ बफरमा डिक्रिप्टेड लाइन हुनेछ, किनकि यो प्रकार्यमा पास हुन्छ। क्लास खोज्नुहोस्, जसले कक्षाको नामलाई दोस्रो प्यारामिटरको रूपमा लिन्छ। त्यसकारण, संख्या बफरको आकार वा रेखाको लम्बाइ हो। कक्षाको नाम बुझाउने प्रयास गरौं, यसले हामीलाई सही दिशामा गइरहेको छ कि छैन भनेर बताउनुपर्छ। आउनुहोस् एक नजिकबाट के हुन्छ मा हेरौं 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_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 ब्राउजरका विकासकर्ताहरूले हाम्रो लागि अर्को आश्चर्य तयार पारेका छन्।

जाभा कोडमा बनाइएको एरेबाट प्यारामिटरहरू प्राप्त गरेपछि, हामीले पाउँछौं
ठेगाना 0x4D070 मा समारोहमा। र यहाँ अर्को प्रकारको कोड अस्पष्टता हामीलाई पर्खिरहेको छ।

हामीले R7 र R4 मा दुई सूचकहरू राख्छौं:

हामी पहिलो अनुक्रमणिकालाई R11 मा स्थानान्तरण गर्छौं:

तालिकाबाट ठेगाना प्राप्त गर्न, अनुक्रमणिका प्रयोग गर्नुहोस्:

पहिलो ठेगानामा गएपछि, दोस्रो अनुक्रमणिका प्रयोग गरिन्छ, जुन R4 मा छ। तालिकामा 230 तत्वहरू छन्।

यसमा के गर्ने ? तपाईंले IDA लाई यो स्विच हो भनी बताउन सक्नुहुन्छ: सम्पादन -> अन्य -> स्विच मुहावरा निर्दिष्ट गर्नुहोस्।

नतिजा कोड भयानक छ। तर, यसको जङ्गलबाट आफ्नो बाटो बनाउँदै, तपाईंले हामीलाई पहिले नै परिचित समारोहमा कल देख्न सक्नुहुन्छ sub_6115C:

त्यहाँ एउटा स्विच थियो जसमा केस 3 मा RC4 एल्गोरिदम प्रयोग गरेर डिक्रिप्शन थियो। र यस अवस्थामा, प्रकार्यमा पास गरिएको संरचनालाई पास गरिएको प्यारामिटरहरूबाट भरिएको छ doCommandNative। हामी त्यहाँ के थियो सम्झौं magicInt मान 16 को साथ। हामी सम्बन्धित केस हेर्छौं - र धेरै संक्रमण पछि हामी कोड फेला पार्छौं जसद्वारा एल्गोरिथ्म पहिचान गर्न सकिन्छ।

यो AES हो!

एल्गोरिथ्म अवस्थित छ, बाँकी सबै यसको प्यारामिटरहरू प्राप्त गर्न हो: मोड, कुञ्जी र, सम्भवतः, प्रारम्भिक भेक्टर (यसको उपस्थिति AES एल्गोरिथ्मको अपरेटिङ मोडमा निर्भर गर्दछ)। तिनीहरूसँगको संरचना प्रकार्य कल अघि कतै गठन हुनुपर्छ sub_6115C, तर कोडको यो भाग विशेष गरी राम्रोसँग अस्पष्ट छ, त्यसैले कोड प्याच गर्ने विचार उत्पन्न हुन्छ ताकि डिक्रिप्शन प्रकार्यका सबै प्यारामिटरहरू फाइलमा डम्प हुन्छन्।

प्याच

सबै प्याच कोडहरू असेंबली भाषामा म्यानुअल रूपमा नलेख्नको लागि, तपाईंले एन्ड्रोइड स्टुडियो सुरु गर्न सक्नुहुन्छ, त्यहाँ एउटा प्रकार्य लेख्नुहोस् जसले हाम्रो डिक्रिप्शन प्रकार्यको रूपमा समान इनपुट प्यारामिटरहरू प्राप्त गर्दछ र फाइलमा लेख्छ, त्यसपछि कम्पाइलरले कोड प्रतिलिपि गरेर टाँस्नुहोस्। उत्पन्न गर्नुहोस्।

UC ब्राउजर टोलीका हाम्रा साथीहरूले पनि कोड थप्ने सुविधाको ख्याल गरे। हामीलाई याद गरौं कि प्रत्येक प्रकार्यको सुरुमा हामीसँग फोहोर कोड छ जुन सजिलैसँग कुनै पनि अन्यसँग बदल्न सकिन्छ। धेरै सुविधाजनक 🙂 यद्यपि, लक्ष्य प्रकार्यको सुरुमा त्यहाँ कोडको लागि पर्याप्त ठाउँ छैन जसले फाइलमा सबै प्यारामिटरहरू बचत गर्दछ। मैले यसलाई भागहरूमा विभाजन गर्नुपर्‍यो र छिमेकी कार्यहरूबाट फोहोर ब्लकहरू प्रयोग गर्नुपर्‍यो। जम्मा चार भाग थिए ।

पहिलो भाग:

एआरएम आर्किटेक्चरमा, पहिलो चार प्रकार्य प्यारामिटरहरू दर्ताहरू R0-R3 मार्फत पारित गरिन्छ, बाँकी, यदि कुनै छ भने, स्ट्याक मार्फत पारित गरिन्छ। LR दर्ताले फिर्ती ठेगाना राख्छ। यो सबै बचत गर्न आवश्यक छ ताकि हामीले यसको प्यारामिटरहरू डम्प गरेपछि प्रकार्यले काम गर्न सक्छ। हामीले प्रक्रियामा प्रयोग गर्ने सबै दर्ताहरू पनि बचत गर्न आवश्यक छ, त्यसैले हामी PUSH.W {R0-R10,LR} गर्छौं। R7 मा हामीले स्ट्याक मार्फत प्रकार्यमा पास गरिएको प्यारामिटरहरूको सूचीको ठेगाना पाउँछौं।

प्रकार्य प्रयोग गर्दै fopen फाइल खोलौं /data/local/tmp/aes "ab" मोडमा
अर्थात् थपको लागि। R0 मा हामी फाइल नामको ठेगाना लोड गर्छौं, R1 मा - मोड संकेत गर्ने लाइनको ठेगाना। र यहाँ गार्बेज कोड समाप्त हुन्छ, त्यसैले हामी अर्को प्रकार्यमा जान्छौं। यसलाई काम गर्न जारी राख्नको लागि, हामीले सुरुमा फंक्शनको वास्तविक कोडमा ट्रान्जिसन राख्छौं, फोहोरलाई बाइपास गर्दै, र फोहोरको सट्टा हामी प्याचको निरन्तरता थप्छौं।

कल गर्दै fopen.

प्रकार्यको पहिलो तीन प्यारामिटरहरू एईएस प्रकार छ int। हामीले सुरुमा स्ट्याकमा दर्ताहरू बचत गरेकाले, हामी केवल प्रकार्य पास गर्न सक्छौं fwrite स्ट्याकमा तिनीहरूको ठेगानाहरू।

अर्को हामीसँग डाटा साइज र कुञ्जी, प्रारम्भिक भेक्टर र इन्क्रिप्टेड डाटाको लागि डेटाको लागि सूचक समावेश गर्ने तीन संरचनाहरू छन्।

अन्तमा, फाइल बन्द गर्नुहोस्, दर्ताहरू पुनर्स्थापना गर्नुहोस् र वास्तविक प्रकार्यमा नियन्त्रण स्थानान्तरण गर्नुहोस् एईएस.

हामी प्याच गरिएको पुस्तकालयको साथ एपीके सङ्कलन गर्छौं, त्यसमा हस्ताक्षर गर्छौं, यन्त्र/इम्युलेटरमा अपलोड गर्छौं, र यसलाई लन्च गर्छौं। हामी देख्छौं कि हाम्रो डम्प सिर्जना भइरहेको छ, र त्यहाँ धेरै डाटा लेखिएको छ। ब्राउजरले ट्राफिकको लागि मात्र नभई एन्क्रिप्शन प्रयोग गर्दछ, र सबै इन्क्रिप्शन प्रश्नमा रहेको प्रकार्य मार्फत जान्छ। तर कुनै कारणले आवश्यक डाटा त्यहाँ छैन, र आवश्यक अनुरोध ट्राफिकमा देखिँदैन। 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 ब्राउजर 12.10.9.1193 को नयाँ संस्करण जारी गरिएको थियो, जसले HTTPS मार्फत सर्भर पहुँच गर्यो: puds.ucweb.com/upgrade/index.xhtml.

थप रूपमा, "फिक्स" पछि र यो लेख लेख्ने समय सम्म, ब्राउजरमा पीडीएफ खोल्ने प्रयास गर्दा "उफ, केहि गलत भयो!" पाठको साथ त्रुटि सन्देश आयो। पीडीएफ खोल्ने प्रयास गर्दा सर्भरलाई अनुरोध गरिएको थिएन, तर ब्राउजर सुरू गर्दा अनुरोध गरिएको थियो, जसले Google Play नियमहरूको उल्लङ्घनमा कार्यान्वयन योग्य कोड डाउनलोड गर्ने निरन्तर क्षमतामा सङ्केत गर्छ।

स्रोत: www.habr.com

UC ब्राउजरमा कमजोरीहरू खोज्दै