កំពុងរកមើលភាពងាយរងគ្រោះនៅក្នុង UC Browser

សេចក្តីណែនាំ

នៅចុងខែមីនាយើង រាយការណ៍ដែលពួកគេបានរកឃើញសមត្ថភាពលាក់កំបាំងក្នុងការផ្ទុក និងដំណើរការកូដដែលមិនបានផ្ទៀងផ្ទាត់នៅក្នុង UC Browser ។ ថ្ងៃនេះយើងនឹងពិនិត្យមើលលម្អិតអំពីរបៀបដែលការទាញយកនេះកើតឡើង និងរបៀបដែលពួក Hacker អាចប្រើវាសម្រាប់គោលបំណងផ្ទាល់ខ្លួនរបស់ពួកគេ។

មួយរយៈមុន UC Browser ត្រូវបានផ្សព្វផ្សាយ និងចែកចាយយ៉ាងគឃ្លើន៖ វាត្រូវបានដំឡើងនៅលើឧបករណ៍របស់អ្នកប្រើប្រាស់ដោយប្រើប្រាស់មេរោគ ចែកចាយពីគេហទំព័រផ្សេងៗក្រោមការក្លែងបន្លំឯកសារវីដេអូ (ឧទាហរណ៍ អ្នកប្រើប្រាស់គិតថាពួកគេកំពុងទាញយក ជាឧទាហរណ៍ វីដេអូអាសអាភាស ប៉ុន្តែ ជំនួសឱ្យការទទួលបាន APK ជាមួយកម្មវិធីរុករកតាមអ៊ីនធឺណិតនេះ) បានប្រើបដាដ៏គួរឱ្យខ្លាចដែលមានសារដែលកម្មវិធីរុករកតាមអ៊ីនធឺណិតហួសសម័យ ងាយរងគ្រោះ និងអ្វីៗដូចនោះ។ នៅក្នុងក្រុមកម្មវិធីរុករក UC ផ្លូវការនៅលើ VK មាន ប្រធានបទដែលក្នុងនោះអ្នកប្រើប្រាស់អាចត្អូញត្អែរអំពីការផ្សាយពាណិជ្ជកម្មមិនយុត្តិធម៌ មានឧទាហរណ៍ជាច្រើននៅទីនោះ។ នៅឆ្នាំ 2016 មានសូម្បីតែ វីដេអូផ្សាយពាណិជ្ជកម្ម ជាភាសារុស្សី (បាទ ការផ្សាយពាណិជ្ជកម្មសម្រាប់កម្មវិធីរុករកតាមអ៊ីនធឺណិត)។

នៅពេលសរសេរ UC Browser មានការដំឡើងជាង 500 នៅលើ Google Play ។ នេះគួរឱ្យចាប់អារម្មណ៍ណាស់ - មានតែ Google Chrome ប៉ុណ្ណោះដែលមានច្រើនទៀត។ ក្នុងចំណោមការពិនិត្យ អ្នកអាចមើលឃើញការត្អូញត្អែរជាច្រើនអំពីការផ្សាយពាណិជ្ជកម្ម និងការបញ្ជូនបន្តទៅកាន់កម្មវិធីមួយចំនួននៅលើ Google Play ។ នេះជាហេតុផលសម្រាប់ការស្រាវជ្រាវរបស់យើង៖ យើងបានសម្រេចចិត្តមើលថាតើ UC Browser កំពុងតែធ្វើអ្វីមិនល្អ។ ហើយវាបានប្រែក្លាយថាគាត់ធ្វើ!

នៅក្នុងកូដកម្មវិធី សមត្ថភាពក្នុងការទាញយក និងដំណើរការកូដដែលអាចប្រតិបត្តិបានត្រូវបានរកឃើញ។ ដែលផ្ទុយនឹងច្បាប់សម្រាប់ការបោះពុម្ពកម្មវិធី នៅលើ Google Play ។ បន្ថែមពីលើការទាញយកកូដដែលអាចប្រតិបត្តិបាន UC Browser ធ្វើដូច្នេះក្នុងលក្ខណៈអសន្តិសុខ ដែលអាចត្រូវបានប្រើដើម្បីបើកការវាយប្រហារ MitM ។ ចាំមើលថាតើយើងអាចធ្វើការវាយប្រហារបែបនេះបានដែរឬទេ?

អ្វីគ្រប់យ៉ាងដែលបានសរសេរខាងក្រោមគឺពាក់ព័ន្ធសម្រាប់កំណែរបស់ UC Browser ដែលមាននៅលើ Google Play នៅពេលសិក្សា៖

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

វ៉ិចទ័រវាយប្រហារ

នៅក្នុង UC Browser manifest អ្នកអាចស្វែងរកសេវាកម្មដែលមានឈ្មោះពន្យល់ដោយខ្លួនឯង។ 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 Browser៖ សមត្ថភាពក្នុងការបើក PDF ដោយប្រើបណ្ណាល័យដើម ដែលមិនមាននៅក្នុង APK និងដែលវាទាញយកពីអ៊ីនធឺណិតប្រសិនបើចាំបាច់។ គួរកត់សម្គាល់ថាតាមទ្រឹស្តី UC Browser អាចត្រូវបានបង្ខំឱ្យទាញយកអ្វីមួយដោយគ្មានអន្តរកម្មអ្នកប្រើប្រាស់ - ប្រសិនបើអ្នកផ្តល់ការឆ្លើយតបដែលមានទម្រង់ល្អចំពោះសំណើដែលត្រូវបានប្រតិបត្តិបន្ទាប់ពីកម្មវិធីរុករកត្រូវបានបើកដំណើរការ។ ប៉ុន្តែដើម្បីធ្វើដូច្នេះ យើងត្រូវសិក្សាពីពិធីការនៃអន្តរកម្មជាមួយម៉ាស៊ីនមេឱ្យកាន់តែលម្អិត ដូច្នេះយើងបានសម្រេចចិត្តថាវានឹងកាន់តែងាយស្រួលក្នុងការកែសម្រួលការឆ្លើយតបដែលត្រូវបានស្ទាក់ចាប់ ហើយជំនួសបណ្ណាល័យសម្រាប់ធ្វើការជាមួយ 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 តំណាងឱ្យជម្រើសមួយក្នុងចំណោមជម្រើសបី។

យើងបន្តវិភាគកូដ។ បន្ទាប់ពីការលោតពីរបីដង យើងរកឃើញខ្លួនយើងនៅក្នុងវិធីសាស្រ្តមួយដែលមានឈ្មោះពន្យល់ដោយខ្លួនឯង។ ឌិគ្រីបBytesByKey.

នៅទីនេះពីរបៃទៀតត្រូវបានបំបែកចេញពីការឆ្លើយតបរបស់យើង ហើយខ្សែអក្សរមួយត្រូវបានទទួលពីពួកគេ។ វាច្បាស់ណាស់ថាតាមរបៀបនេះគន្លឹះសម្រាប់ការឌិគ្រីបសារត្រូវបានជ្រើសរើស។

    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 មានន័យថាការឌិគ្រីប, ដូចនៅក្នុងវិធីសាស្រ្ត doFinal ថ្នាក់ប្រព័ន្ធ javax.crypto.Cipher. ហើយទាំងអស់នេះត្រូវបានផ្ទេរទៅ Router ជាក់លាក់មួយដែលមានលេខ 10601 - នេះច្បាស់ជាលេខបញ្ជា។

បន្ទាប់ពីខ្សែសង្វាក់បន្ទាប់នៃការផ្លាស់ប្តូរយើងរកឃើញថ្នាក់ដែលអនុវត្តចំណុចប្រទាក់ សមាសធាតុ IRouter និងវិធីសាស្រ្ត បញ្ជា:

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_OnLoad)
ដោយប្រើមុខងារហៅ ការចុះឈ្មោះជនជាតិដើម.

ក្នុងករណីរបស់យើង ប្រសិនបើយើងប្រើវិធីទីមួយ ឈ្មោះគួរតែដូចនេះ៖ Java_com_taobao_wireless_security_adapter_JNICLibrary_doCommandNative.

មិនមានមុខងារបែបនេះក្នុងចំណោមមុខងារដែលបាននាំចេញទេ ដែលមានន័យថាអ្នកត្រូវរកមើលការហៅទូរសព្ទ ការចុះឈ្មោះជនជាតិដើម.
តោះទៅមុខងារ JNI_OnLoad ហើយយើងឃើញរូបភាពនេះ៖

តើមានអ្វីកើតឡើងនៅទីនេះ? នៅ glance ដំបូង ការចាប់ផ្តើម និងចុងបញ្ចប់នៃមុខងារគឺជាតួយ៉ាងសម្រាប់ស្ថាបត្យកម្ម ARM ។ ការណែនាំដំបូងនៅលើជង់រក្សាទុកមាតិកានៃការចុះឈ្មោះដែលមុខងារនឹងប្រើក្នុងប្រតិបត្តិការរបស់វា (ក្នុងករណីនេះ R0, R1 និង R2) ក៏ដូចជាមាតិកានៃការចុះឈ្មោះ LR ដែលមានអាសយដ្ឋានត្រឡប់ពីមុខងារ . ការណែនាំចុងក្រោយស្ដារការចុះឈ្មោះដែលបានរក្សាទុកហើយអាសយដ្ឋានត្រឡប់មកវិញត្រូវបានដាក់ភ្លាមៗនៅក្នុងការចុះឈ្មោះកុំព្យូទ័រ - ដូច្នេះត្រឡប់ពីមុខងារ។ ប៉ុន្តែប្រសិនបើអ្នកក្រឡេកមើលឱ្យជិត អ្នកនឹងសម្គាល់ឃើញថា ការណែនាំចុងក្រោយផ្លាស់ប្តូរអាសយដ្ឋានត្រឡប់មកវិញដែលរក្សាទុកនៅលើជង់។ ចូរយើងគណនាថាតើវានឹងទៅជាយ៉ាងណាបន្ទាប់ពីនោះ។
ការអនុវត្តកូដ។ អាសយដ្ឋានជាក់លាក់ 1xB0 ត្រូវបានផ្ទុកទៅក្នុង R130, 5 ត្រូវបានដកចេញពីវា បន្ទាប់មកវាត្រូវបានផ្ទេរទៅ R0 ហើយ 0x10 ត្រូវបានបន្ថែមទៅវា។ វាប្រែចេញ 0xB13B ។ ដូច្នេះ IDA គិតថាការណែនាំចុងក្រោយគឺជាការត្រឡប់មុខងារធម្មតា ប៉ុន្តែតាមពិតវានឹងទៅអាសយដ្ឋានដែលបានគណនា 0xB13B។

វាគួរអោយចងចាំនៅទីនេះថា ARM processors មានរបៀបពីរ និងការណែនាំពីរគឺ ARM និង Thumb ។ អាស័យដ្ឋានដែលសំខាន់តិចបំផុតប្រាប់ processor ថាតើសំណុំការណែនាំមួយណាកំពុងត្រូវបានប្រើប្រាស់។ នោះគឺជាអាសយដ្ឋានពិតប្រាកដគឺ 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៖

IDA ម្តងទៀតមិនបានទទួលស្គាល់តំបន់នេះជាលេខកូដទេ។ យើងជួយនាង ហើយមើលការរចនាមួយទៀតនៅទីនោះ៖

ការណែនាំបន្ទាប់ពី BLX ហាក់ដូចជាមិនមានអត្ថន័យច្រើនទេ វាដូចជាការផ្លាស់ទីលំនៅមួយចំនួន។ តោះមើល sub_4964៖

ហើយជាការពិត នៅទីនេះ dword មួយត្រូវបានគេយកនៅអាសយដ្ឋានដែលស្ថិតនៅក្នុង 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 Browser ហើយបានទទួលកូដមុខងារ JNI_OnLoad.

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

ចូរយើងពិនិត្យមើលឱ្យកាន់តែច្បាស់នូវបន្ទាត់ខាងក្រោម៖

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

នៅក្នុងមុខងារ sub_73E24 ឈ្មោះថ្នាក់ត្រូវបានឌិគ្រីបយ៉ាងច្បាស់។ ជាប៉ារ៉ាម៉ែត្រនៃមុខងារនេះ ទ្រនិចទៅទិន្នន័យស្រដៀងនឹងទិន្នន័យដែលបានអ៊ិនគ្រីប សតិបណ្ដោះអាសន្នជាក់លាក់ និងលេខមួយត្រូវបានឆ្លងកាត់។ ជាក់ស្តែង បន្ទាប់ពីហៅមុខងាររួច វានឹងមានបន្ទាត់ឌិគ្រីបនៅក្នុងសតិបណ្ដោះអាសន្ន ព្រោះវាត្រូវបានបញ្ជូនទៅមុខងារ ស្វែងរកថ្នាក់ដែលយកឈ្មោះថ្នាក់ជាប៉ារ៉ាម៉ែត្រទីពីរ។ ដូច្នេះលេខគឺជាទំហំនៃសតិបណ្ដោះអាសន្ន ឬប្រវែងនៃបន្ទាត់។ ចូរយើងព្យាយាម decipher ឈ្មោះថ្នាក់ វាគួរតែប្រាប់យើងថាតើយើងកំពុងដើរក្នុងទិសដៅត្រឹមត្រូវឬអត់ ចូរយើងពិនិត្យមើលឱ្យកាន់តែច្បាស់នូវអ្វីដែលកើតឡើងនៅក្នុង 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 algorithm នៅក្នុងវា។

យើងមានក្បួនដោះស្រាយ និងគន្លឹះមួយ។ តោះ​ព្យាយាម​ឌិគ្រីប​ឈ្មោះ​ថ្នាក់។ នេះជាអ្វីដែលបានកើតឡើង៖ com/taobao/wireless/security/adapter/JNICLibrary. អស្ចារ្យ! យើងស្ថិតនៅលើផ្លូវត្រូវ។

ដើមឈើបញ្ជា

ឥឡូវនេះយើងត្រូវស្វែងរកបញ្ហាប្រឈមមួយ។ ការចុះឈ្មោះជនជាតិដើមដែលនឹងចង្អុលយើងទៅមុខងារ doCommandNative. តោះមើលមុខងារដែលហៅថាពី JNI_OnLoad, ហើយយើងរកឃើញវានៅក្នុង sub_B7B0:

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

ហើយជាការពិតណាស់ វិធីសាស្ត្រដើមដែលមានឈ្មោះត្រូវបានចុះឈ្មោះនៅទីនេះ doCommandNative. ឥឡូវនេះយើងដឹងពីអាសយដ្ឋានរបស់គាត់។ តោះមើលអ្វីដែលគាត់ធ្វើ។

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

តាមឈ្មោះអ្នកអាចទាយបានថានេះគឺជាចំណុចចូលនៃមុខងារទាំងអស់ដែលអ្នកអភិវឌ្ឍន៍បានសម្រេចចិត្តផ្ទេរទៅបណ្ណាល័យដើម។ យើងចាប់អារម្មណ៍លើមុខងារ 10601 ។

អ្នកអាចមើលឃើញពីកូដដែលលេខបញ្ជាបង្កើតលេខបី៖ ពាក្យបញ្ជា / 10000, ពាក្យបញ្ជា % 10000 / 100 и ពាក្យបញ្ជា % 10ឧ. ក្នុងករណីរបស់យើង 1, 6 និង 1។ លេខទាំងបីនេះ ក៏ដូចជាទ្រនិចទៅ JNIEnv ហើយអាគុយម៉ង់ដែលបានបញ្ជូនទៅអនុគមន៍ត្រូវបានបន្ថែមទៅរចនាសម្ព័ន្ធមួយហើយបញ្ជូនបន្ត។ ដោយ​ប្រើ​លេខ​បី​ដែល​ទទួល​បាន (សូម​បញ្ជាក់​ពួកវា N1, N2 និង N3) មែកធាង​ពាក្យ​បញ្ជា​ត្រូវ​បាន​បង្កើត​ឡើង។

អ្វីមួយ​ដូចនេះ:

ដើមឈើត្រូវបានបំពេញដោយថាមវន្ត JNI_OnLoad.
លេខបីបានអ៊ិនកូដផ្លូវនៅក្នុងដើមឈើ។ ស្លឹកនីមួយៗនៃមែកធាងមានអាសយដ្ឋាន pocked នៃមុខងារដែលត្រូវគ្នា។ គន្លឹះគឺនៅក្នុងថ្នាំងមេ។ ការស្វែងរកកន្លែងនៅក្នុងកូដដែលមុខងារដែលយើងត្រូវការត្រូវបានបន្ថែមទៅមែកធាងមិនពិបាកទេ ប្រសិនបើអ្នកយល់ពីរចនាសម្ព័ន្ធទាំងអស់ដែលបានប្រើ (យើងមិនពណ៌នាពួកវាដើម្បីកុំឱ្យអត្ថបទធំជាងនេះ)។

ភាពច្របូកច្របល់បន្ថែមទៀត

យើងបានទទួលអាសយដ្ឋាននៃមុខងារដែលគួរឌិគ្រីបចរាចរណ៍៖ 0x5F1AC ។ ប៉ុន្តែវាលឿនពេកក្នុងការរីករាយ៖ អ្នកអភិវឌ្ឍន៍ UC Browser បានរៀបចំការភ្ញាក់ផ្អើលមួយទៀតសម្រាប់ពួកយើង។

បន្ទាប់ពីទទួលបានប៉ារ៉ាម៉ែត្រពីអារេដែលត្រូវបានបង្កើតឡើងនៅក្នុងកូដ Java យើងទទួលបាន
ទៅមុខងារនៅអាសយដ្ឋាន 0x4D070 ។ ហើយនៅទីនេះ ប្រភេទនៃការលាក់បាំងកូដមួយផ្សេងទៀតកំពុងរង់ចាំយើង។

យើងដាក់សន្ទស្សន៍ពីរក្នុង R7 និង R4៖

យើងប្តូរសន្ទស្សន៍ទីមួយទៅ R11៖

ដើម្បីទទួលបានអាសយដ្ឋានពីតារាង សូមប្រើលិបិក្រម៖

បន្ទាប់ពីចូលទៅកាន់អាសយដ្ឋានទីមួយ លិបិក្រមទីពីរត្រូវបានប្រើ ដែលស្ថិតនៅក្នុង R4។ មាន 230 ធាតុនៅក្នុងតារាង។

អ្វីដែលត្រូវធ្វើអំពីវា? អ្នកអាចប្រាប់ IDA ថានេះគឺជាកុងតាក់៖ កែសម្រួល -> ផ្សេងទៀត -> បញ្ជាក់ការប្តូរ idiom ។

លេខកូដលទ្ធផលគឺគួរឱ្យខ្លាច។ ប៉ុន្តែ ការ​ធ្វើ​ផ្លូវ​កាត់​ព្រៃ​របស់​វា អ្នក​អាច​សម្គាល់​ឃើញ​ការ​ហៅ​ទៅ​មុខងារ​ដែល​យើង​ធ្លាប់​ស្គាល់​រួច​ហើយ។ sub_6115C:

មានកុងតាក់ដែលក្នុងករណីទី 3 មានការឌិគ្រីបដោយប្រើក្បួនដោះស្រាយ RC4 ។ ហើយក្នុងករណីនេះរចនាសម្ព័ន្ធដែលបានបញ្ជូនទៅមុខងារត្រូវបានបំពេញពីប៉ារ៉ាម៉ែត្រដែលបានបញ្ជូនទៅ doCommandNative. ចូរយើងចងចាំនូវអ្វីដែលយើងមាននៅទីនោះ វេទមន្តអ៊ីន ជាមួយនឹងតម្លៃ 16. យើងពិនិត្យមើលករណីដែលត្រូវគ្នា ហើយបន្ទាប់ពីការផ្លាស់ប្តូរជាច្រើន យើងរកឃើញកូដដែលក្បួនដោះស្រាយអាចត្រូវបានកំណត់អត្តសញ្ញាណ។

នេះគឺជា AES!

ក្បួនដោះស្រាយមានហើយ អ្វីដែលនៅសេសសល់គឺដើម្បីទទួលបានប៉ារ៉ាម៉ែត្ររបស់វា៖ របៀប គន្លឹះ និង វ៉ិចទ័រការចាប់ផ្តើម (វត្តមានរបស់វាអាស្រ័យលើរបៀបប្រតិបត្តិការនៃក្បួនដោះស្រាយ AES) ។ រចនាសម្ព័ន្ធជាមួយពួកគេត្រូវតែត្រូវបានបង្កើតឡើងនៅកន្លែងណាមួយមុនពេលការហៅមុខងារ sub_6115Cប៉ុន្តែផ្នែកនៃកូដនេះមានភាពច្របូកច្របល់យ៉ាងខ្លាំង ដូច្នេះគំនិតកើតឡើងដើម្បីជួសជុលកូដ ដើម្បីឱ្យប៉ារ៉ាម៉ែត្រទាំងអស់នៃមុខងារឌិគ្រីបត្រូវបានបោះចោលទៅក្នុងឯកសារ។

បំណះ

ដើម្បីកុំឱ្យសរសេរកូដបំណះទាំងអស់ជាភាសាដំឡើងដោយដៃ អ្នកអាចបើកដំណើរការ Android Studio សរសេរមុខងារនៅទីនោះដែលទទួលប៉ារ៉ាម៉ែត្របញ្ចូលដូចគ្នានឹងមុខងារឌិគ្រីបរបស់យើង ហើយសរសេរទៅឯកសារ បន្ទាប់មកចម្លង-បិទភ្ជាប់កូដដែលអ្នកចងក្រងនឹង បង្កើត។

មិត្តភ័ក្តិរបស់យើងមកពីក្រុម UC Browser ក៏បានយកចិត្តទុកដាក់លើភាពងាយស្រួលនៃការបន្ថែមកូដផងដែរ។ ចូរយើងចាំថានៅដើមនៃមុខងារនីមួយៗ យើងមានលេខកូដសំរាមដែលអាចជំនួសបានដោយងាយស្រួល។ ងាយស្រួលណាស់ 🙂 ទោះយ៉ាងណាក៏ដោយនៅដើមមុខងារគោលដៅមិនមានកន្លែងគ្រប់គ្រាន់សម្រាប់កូដដែលរក្សាទុកប៉ារ៉ាម៉ែត្រទាំងអស់ទៅក្នុងឯកសារមួយ។ ខ្ញុំ​ត្រូវ​បំបែក​វា​ជា​ផ្នែក ហើយ​ប្រើ​ប្លុក​សំរាម​ពី​មុខងារ​ជិតខាង។ សរុបមានបួនផ្នែក។

ផ្នែកដំបូង៖

នៅក្នុងស្ថាបត្យកម្ម ARM ប៉ារ៉ាម៉ែត្រមុខងារបួនដំបូងត្រូវបានឆ្លងកាត់ការចុះឈ្មោះ R0-R3 នៅសល់ប្រសិនបើមានត្រូវបានឆ្លងកាត់ជង់។ ការចុះឈ្មោះ LR ផ្ទុកអាសយដ្ឋានត្រឡប់មកវិញ។ ទាំងអស់នេះចាំបាច់ត្រូវរក្សាទុកដើម្បីឱ្យមុខងារអាចដំណើរការបន្ទាប់ពីយើងបោះចោលប៉ារ៉ាម៉ែត្ររបស់វា។ យើងក៏ត្រូវរក្សាទុកការចុះឈ្មោះទាំងអស់ដែលយើងនឹងប្រើក្នុងដំណើរការ ដូច្នេះយើងធ្វើ PUSH.W {R0-R10,LR}។ នៅក្នុង R7 យើងទទួលបានអាសយដ្ឋាននៃបញ្ជីប៉ារ៉ាម៉ែត្រដែលបានបញ្ជូនទៅមុខងារតាមរយៈជង់។

ការប្រើប្រាស់មុខងារ fopen តោះបើកឯកសារ /data/local/tmp/aes នៅក្នុងរបៀប "ab"
i.e. សម្រាប់ការបន្ថែម។ នៅក្នុង R0 យើងផ្ទុកអាសយដ្ឋាននៃឈ្មោះឯកសារនៅក្នុង R1 - អាសយដ្ឋាននៃបន្ទាត់ដែលបង្ហាញពីរបៀប។ ហើយនៅទីនេះលេខកូដសំរាមបញ្ចប់ ដូច្នេះយើងបន្តទៅមុខងារបន្ទាប់។ ដើម្បីឱ្យវាបន្តដំណើរការ យើងបានដាក់នៅដើមដំបូងនូវការផ្លាស់ប្តូរទៅកូដពិតនៃមុខងារ ដោយឆ្លងកាត់សំរាម ហើយជំនួសឱ្យសំរាមយើងបន្ថែមការបន្តនៃបំណះ។

ការហៅទូរសព្ទ fopen.

ប៉ារ៉ាម៉ែត្របីដំបូងនៃមុខងារ 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 ។

ក្នុងអំឡុងពេលនៃការវិភាគបន្ថែមនៃកូដ មុខងារមួយត្រូវបានគេរកឃើញដែល deciphers បន្ទាត់គួរឱ្យចាប់អារម្មណ៍: "META-INF/" និង ".RSA" ។ វាហាក់ដូចជាកម្មវិធីកំពុងផ្ទៀងផ្ទាត់វិញ្ញាបនបត្ររបស់វា។ ឬសូម្បីតែបង្កើតសោពីវា។ ខ្ញុំពិតជាមិនចង់ដោះស្រាយជាមួយនឹងអ្វីដែលកំពុងកើតឡើងជាមួយវិញ្ញាបនបត្រទេ ដូច្នេះយើងនឹងគ្រាន់តែទម្លាក់វានូវវិញ្ញាបនបត្រត្រឹមត្រូវ។ តោះជួសជុលបន្ទាត់ដែលបានអ៊ិនគ្រីប ដូច្នេះជំនួសឱ្យ "META-INF/" យើងទទួលបាន "BLABLINF/" បង្កើតថតឯកសារដែលមានឈ្មោះនោះនៅក្នុង APK ហើយបន្ថែមវិញ្ញាបនបត្រកម្មវិធីរុករកតាមអ៊ីនធឺណិតនៅទីនោះ។

យើងប្រមូលផ្តុំ ចុះហត្ថលេខា ដំឡើង បើកដំណើរការ។ ប៊ីងហ្គោ! យើងមានគន្លឹះ!

មីធីអឹម

យើងបានទទួលកូនសោមួយ និងវ៉ិចទ័រចាប់ផ្តើមស្មើនឹងកូនសោ។ តោះព្យាយាមឌិគ្រីបការឆ្លើយតបរបស់ម៉ាស៊ីនមេនៅក្នុងរបៀប CBC ។

យើងឃើញប័ណ្ណសារ URL ដែលស្រដៀងនឹង MD5 “extract_unzipsize” និងលេខមួយ។ យើងពិនិត្យ៖ MD5 នៃបណ្ណសារគឺដូចគ្នា ទំហំនៃបណ្ណាល័យដែលមិនបានវេចខ្ចប់គឺដូចគ្នា។ យើងកំពុងព្យាយាមជួសជុលបណ្ណាល័យនេះ ហើយផ្តល់ឱ្យវាទៅកម្មវិធីរុករក។ ដើម្បីបង្ហាញថាបណ្ណាល័យដែលបានបំណះរបស់យើងបានផ្ទុក យើងនឹងបើកដំណើរការ Intent ដើម្បីបង្កើតសារ SMS ដែលមានអក្សរ “PWNED!” យើងនឹងជំនួសការឆ្លើយតបពីរពីម៉ាស៊ីនមេ៖ puds.ucweb.com/upgrade/index.xhtml និងដើម្បីទាញយកប័ណ្ណសារ។ ដំបូងយើងជំនួស MD5 (ទំហំមិនផ្លាស់ប្តូរបន្ទាប់ពីការពន្លា) នៅទីពីរយើងផ្តល់ប័ណ្ណសារជាមួយបណ្ណាល័យដែលបានជួសជុល។

កម្មវិធីរុករកតាមអ៊ីនធឺណិតព្យាយាមទាញយកបណ្ណសារជាច្រើនដង បន្ទាប់ពីនោះវាផ្តល់កំហុស។ ជាក់ស្តែងអ្វីមួយ
គាត់​មិន​ចូលចិត្ត។ ជាលទ្ធផលនៃការវិភាគទម្រង់ដែលស្រពិចស្រពិលនេះ វាបានប្រែក្លាយថាម៉ាស៊ីនមេក៏បញ្ជូនទំហំនៃប័ណ្ណសារផងដែរ៖

វាត្រូវបានអ៊ិនកូដនៅក្នុង LEB128 ។ បន្ទាប់ពីបំណះ ទំហំនៃប័ណ្ណសារជាមួយបណ្ណាល័យបានផ្លាស់ប្តូរបន្តិចបន្តួច ដូច្នេះកម្មវិធីរុករកបានចាត់ទុកថាបណ្ណសារត្រូវបានទាញយកដោយអចេតនា ហើយបន្ទាប់ពីការព្យាយាមជាច្រើនដង វាបានបង្កកំហុស។

យើងកែសម្រួលទំហំនៃបណ្ណសារ... ហើយ - ជ័យជំនះ! 🙂 លទ្ធផលគឺនៅក្នុងវីដេអូ។

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

ផលវិបាក និងប្រតិកម្មរបស់អ្នកអភិវឌ្ឍន៍

ដូចគ្នាដែរ ពួក Hacker អាចប្រើប្រាស់មុខងារមិនមានសុវត្ថិភាពរបស់ UC Browser ដើម្បីចែកចាយ និងដំណើរការបណ្ណាល័យដែលមានគំនិតអាក្រក់។ បណ្ណាល័យទាំងនេះនឹងដំណើរការនៅក្នុងបរិបទនៃកម្មវិធីរុករក ដូច្នេះពួកគេនឹងទទួលបានការអនុញ្ញាតប្រព័ន្ធទាំងអស់របស់វា។ ជាលទ្ធផល សមត្ថភាពក្នុងការបង្ហាញបង្អួចបន្លំ ក៏ដូចជាការចូលទៅកាន់ឯកសារការងាររបស់សត្វកំប្រុកចិនពណ៌ទឹកក្រូច រួមទាំងការចូល ពាក្យសម្ងាត់ និងខូគីដែលរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យ។

យើងបានទាក់ទងអ្នកអភិវឌ្ឍន៍ UC Browser និងជូនដំណឹងពួកគេអំពីបញ្ហាដែលយើងបានរកឃើញ ព្យាយាមចង្អុលបង្ហាញពីភាពងាយរងគ្រោះ និងគ្រោះថ្នាក់របស់វា ប៉ុន្តែពួកគេមិនបានពិភាក្សាអ្វីជាមួយយើងទេ។ ទន្ទឹមនឹងនេះ កម្មវិធីរុករកតាមអ៊ីនធឺណិតបានបន្តបង្ហាញពីលក្ខណៈពិសេសដ៏គ្រោះថ្នាក់របស់វានៅក្នុងការមើលឃើញធម្មតា។ ប៉ុន្តែនៅពេលដែលយើងបង្ហាញព័ត៌មានលម្អិតនៃភាពងាយរងគ្រោះនោះ វាមិនអាចមិនអើពើវាដូចពីមុនទៀតទេ។ ថ្ងៃទី 27 ខែមីនា
កំណែថ្មីនៃ UC Browser 12.10.9.1193 ត្រូវបានចេញផ្សាយ ដែលចូលប្រើម៉ាស៊ីនមេតាមរយៈ HTTPS៖ puds.ucweb.com/upgrade/index.xhtml.

លើសពីនេះទៀតបន្ទាប់ពី "ជួសជុល" និងរហូតដល់ពេលនៃការសរសេរអត្ថបទនេះ ការព្យាយាមបើក PDF នៅក្នុងកម្មវិធីរុករកបានបណ្តាលឱ្យមានសារកំហុសជាមួយអត្ថបទ "អូ! មានអ្វីខុស!" សំណើទៅកាន់ម៉ាស៊ីនមេមិនត្រូវបានធ្វើឡើងនៅពេលព្យាយាមបើក PDF នោះទេ ប៉ុន្តែសំណើមួយត្រូវបានធ្វើឡើងនៅពេលដែលកម្មវិធីរុករកត្រូវបានបើកដំណើរការ ដែលបង្ហាញពីលទ្ធភាពបន្តក្នុងការទាញយកកូដដែលអាចប្រតិបត្តិបានដោយបំពានច្បាប់ Google Play ។

ប្រភព: www.habr.com