ვეძებთ დაუცველობას UC ბრაუზერში

შესავალი

მარტის ბოლოს ჩვენ იტყობინება, რომ მათ აღმოაჩინეს UC ბრაუზერში გადაუმოწმებელი კოდის ჩატვირთვისა და გაშვების ფარული შესაძლებლობა. დღეს ჩვენ დეტალურად განვიხილავთ, თუ როგორ ხდება ეს ჩამოტვირთვა და როგორ შეუძლიათ ჰაკერებს მისი გამოყენება საკუთარი მიზნებისთვის.

რამდენიმე ხნის წინ UC Browser-ის რეკლამირება და გავრცელება ძალიან აგრესიულად განხორციელდა: ის დაინსტალირებული იყო მომხმარებლების მოწყობილობებზე მავნე პროგრამების გამოყენებით, გავრცელდა სხვადასხვა საიტებიდან ვიდეო ფაილების საფარქვეშ (ანუ მომხმარებლები ფიქრობდნენ, რომ ჩამოტვირთავდნენ, მაგალითად, პორნო ვიდეოს, მაგრამ ამის ნაცვლად, მიიღო APK ამ ბრაუზერით), გამოიყენა საშინელი ბანერები შეტყობინებებით, რომ ბრაუზერი მოძველებულია, დაუცველი და მსგავსი რამ. ოფიციალური UC Browser ჯგუფში VK არის თემა, რომელშიც მომხმარებლებს შეუძლიათ უჩივიან უსამართლო რეკლამას, არსებობს უამრავი მაგალითი. 2016 წელს იყო კიდეც ვიდეო რეკლამა რუსულად (დიახ, რეკლამის დაბლოკვის ბრაუზერის რეკლამა).

წერის დროს, UC Browser-ს აქვს 500-ზე მეტი ინსტალაცია Google Play-ზე. ეს შთამბეჭდავია - მხოლოდ Google Chrome-ს აქვს მეტი. მიმოხილვებს შორის შეგიძლიათ იხილოთ საკმაოდ ბევრი პრეტენზია რეკლამასთან დაკავშირებით და გადამისამართება ზოგიერთ აპლიკაციაში Google Play-ზე. ეს იყო ჩვენი კვლევის მიზეზი: გადავწყვიტეთ გაგვეგო, აკეთებდა თუ არა UC Browser რაიმე ცუდს. და აღმოჩნდა, რომ ის აკეთებს!

აპლიკაციის კოდში აღმოაჩინეს შესრულებადი კოდის ჩამოტვირთვისა და გაშვების შესაძლებლობა, რაც ეწინააღმდეგება განაცხადების გამოქვეყნების წესს Google Play-ზე. გარდა შესრულებადი კოდის ჩამოტვირთვისა, UC Browser ამას აკეთებს არასაიმედო გზით, რომელიც შეიძლება გამოყენებულ იქნას MitM შეტევის გასაშვებად. ვნახოთ, შეგვიძლია თუ არა ასეთი თავდასხმის განხორციელება.

ქვემოთ მოყვანილი ყველაფერი შესაბამისია UC ბრაუზერის ვერსიისთვის, რომელიც ხელმისაწვდომი იყო Google Play-ზე კვლევის დროს:

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

შეტევის ვექტორი

UC ბრაუზერის მანიფესტში შეგიძლიათ იპოვოთ სერვისი თვითახსნადი სახელით com.uc.deployment.UpgradeDeployService.

    <service android_exported="false" android_name="com.uc.deployment.UpgradeDeployService" android_process=":deploy" />

როდესაც ეს სერვისი იწყება, ბრაუზერი აკეთებს POST მოთხოვნას puds.ucweb.com/upgrade/index.xhtml, რომელიც ჩანს ტრაფიკში დაწყებიდან რამდენიმე ხნის შემდეგ. საპასუხოდ, მან შეიძლება მიიღოს ბრძანება განახლების ან ახალი მოდულის ჩამოტვირთვის შესახებ. ანალიზის დროს სერვერმა არ გასცა ასეთი ბრძანებები, მაგრამ ჩვენ შევამჩნიეთ, რომ როდესაც ვცდილობთ PDF-ის გახსნას ბრაუზერში, ის მეორე მოთხოვნას აკეთებს ზემოთ მითითებულ მისამართზე, რის შემდეგაც ჩამოტვირთავს მშობლიურ ბიბლიოთეკას. თავდასხმის განსახორციელებლად გადავწყვიტეთ გამოგვეყენებინა UC 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", აქ უნდა გამოიძახოთ მეთოდი, რომელიც გაშიფვრავს სერვერის პასუხს.
გადავიდეთ მეთოდზე ჯ. გაითვალისწინეთ, რომ პირველი არგუმენტი არის ბაიტი ოფსეტზე 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. და ეს ყველაფერი გადაეცემა გარკვეულ როუტერს ნომრით 10601 - ეს აშკარად ბრძანების ნომერია.

გადასვლების შემდეგი ჯაჭვის შემდეგ ვპოულობთ კლასს, რომელიც ახორციელებს ინტერფეისს IRouterკომპონენტი და მეთოდი 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.ასე (რომელიც რეალურად არის .jar და რომელშიც აღმოვაჩინეთ დაშიფვრასთან დაკავშირებული ზოგიერთი ინტერფეისის დანერგვა ზემოთ) არის ერთი მშობლიური ბიბლიოთეკა: libsgmainso-6.4.36.so. ჩვენ ვხსნით მას IDA-ში და ვიღებთ უამრავ დიალოგურ ფანჯარას შეცდომებით. პრობლემა ის არის, რომ სექციის სათაურის ცხრილი არასწორია. ეს კეთდება მიზანმიმართულად, რათა გაართულოს ანალიზი.

მაგრამ ეს არ არის საჭირო: ELF ფაილის სწორად ჩატვირთვისა და მისი ანალიზისთვის საკმარისია პროგრამის სათაურის ცხრილი. ამიტომ, ჩვენ უბრალოდ ვშლით განყოფილების ცხრილს, სათაურში შესაბამისი ველების ნულიდან.

კვლავ გახსენით ფაილი IDA-ში.

არსებობს ორი გზა, რომ ვუთხრათ Java-ს ვირტუალურ მანქანას, თუ სად მდებარეობს ზუსტად მშობლიურ ბიბლიოთეკაში ჯავის კოდში გამოცხადებული მეთოდის იმპლემენტაცია, როგორც მშობლიური. პირველი არის მისთვის სახეობის სახელის მიცემა Java_package_name_ClassName_MethodName.

მეორე არის მისი რეგისტრაცია ბიბლიოთეკის ჩატვირთვისას (ფუნქციაში JNI_OnLoad)
ფუნქციის ზარის გამოყენებით რეგისტრაცია Natives.

ჩვენს შემთხვევაში, თუ პირველ მეთოდს გამოვიყენებთ, სახელი ასეთი უნდა იყოს: Java_com_taobao_wireless_security_adapter_JNICLlibrary_doCommandNative.

ექსპორტირებულ ფუნქციებს შორის ასეთი ფუნქცია არ არის, რაც ნიშნავს, რომ თქვენ უნდა მოძებნოთ ზარი რეგისტრაცია Natives.
მოდით გადავიდეთ ფუნქციაზე JNI_OnLoad და ჩვენ ვხედავთ ამ სურათს:

Რა ხდება აქ? ერთი შეხედვით, ფუნქციის დასაწყისი და დასასრული ტიპიურია ARM არქიტექტურისთვის. დასტაზე პირველი ინსტრუქცია ინახავს რეგისტრების შიგთავსს, რომელსაც ფუნქცია გამოიყენებს თავის ფუნქციონირებაში (ამ შემთხვევაში, R0, R1 და R2), ასევე LR რეგისტრის შიგთავსს, რომელიც შეიცავს ფუნქციიდან დაბრუნებულ მისამართს. . ბოლო ინსტრუქცია აღადგენს შენახულ რეგისტრებს და დაბრუნების მისამართი მაშინვე მოთავსებულია კომპიუტერის რეესტრში - რითაც ბრუნდება ფუნქციიდან. მაგრამ თუ კარგად დააკვირდებით, შეამჩნევთ, რომ ბოლო ინსტრუქცია ცვლის სტეკზე შენახულ დაბრუნების მისამართს. მოდით გამოვთვალოთ როგორი იქნება შემდეგ
კოდის შესრულება. გარკვეული მისამართი 1xB0 იტვირთება R130-ში, მას აკლდება 5, შემდეგ გადადის R0-ზე და ემატება 0x10. გამოდის 0xB13B. ამრიგად, IDA თვლის, რომ ბოლო ინსტრუქცია არის ნორმალური ფუნქციის დაბრუნება, მაგრამ სინამდვილეში ის მიდის გამოთვლილ მისამართზე 0xB13B.

აქ უნდა გავიხსენოთ, რომ ARM პროცესორებს აქვთ ორი რეჟიმი და ინსტრუქციების ორი ნაკრები: ARM და Thumb. მისამართის ყველაზე ნაკლებად მნიშვნელოვანი ნაწილი ეუბნება პროცესორს, რომელი ინსტრუქციების ნაკრები გამოიყენება. ანუ მისამართი რეალურად არის 0xB13A და ყველაზე ნაკლებად მნიშვნელოვანი ბიტიდან ერთი მიუთითებს Thumb რეჟიმში.

მსგავსი „ადაპტერი“ დაემატა ამ ბიბლიოთეკის თითოეული ფუნქციის დასაწყისში და
ნაგვის კოდი. ჩვენ მათზე დეტალურად აღარ ვისაუბრებთ - უბრალოდ გვახსოვს
რომ თითქმის ყველა ფუნქციის რეალური დასაწყისი ცოტა მოშორებით არის.

ვინაიდან კოდი აშკარად არ გადადის 0xB13A-ზე, თავად IDA-მ არ აღიარა, რომ კოდი მდებარეობდა ამ ადგილას. ამავე მიზეზით, ის არ ცნობს ბიბლიოთეკაში არსებული კოდის უმეტესობას კოდად, რაც გარკვეულწილად ართულებს ანალიზს. ჩვენ ვეუბნებით IDA-ს, რომ ეს არის კოდი და ასე ხდება:

ცხრილი აშკარად იწყება 0xB144-დან. რა არის sub_494C-ში?

ამ ფუნქციის LR რეესტრში გამოძახებისას ვიღებთ ადრე აღნიშნული ცხრილის მისამართს (0xB144). R0-ში - ინდექსი ამ ცხრილში. ანუ მნიშვნელობა აღებულია ცხრილიდან, ემატება LR-ს და შედეგი არის
მისამართი, რომელზეც უნდა წახვიდე. შევეცადოთ გამოვთვალოთ: 0xB144 + [0xB144 + 8* 4] = 0xB144 + 0x120 = 0xB264. ჩვენ მივდივართ მიღებულ მისამართზე და ვნახავთ სიტყვასიტყვით რამდენიმე სასარგებლო ინსტრუქციას და კვლავ გადავდივართ 0xB140-ზე:

ახლა იქნება ოფსეტზე გადასვლა ცხრილიდან 0x20 ინდექსით.

ცხრილის ზომით თუ ვიმსჯელებთ, კოდში ბევრი ასეთი გადასვლები იქნება. ჩნდება კითხვა, არის თუ არა შესაძლებელი ამ საკითხის გადაჭრა უფრო ავტომატურად, მისამართების ხელით გაანგარიშების გარეშე. და სკრიპტები და IDA-ში კოდის დაყენების შესაძლებლობა გვეხმარება:

def put_unconditional_branch(source, destination):
offset = (destination - source - 4) >> 1
if offset > 2097151 or offset < -2097152:
raise RuntimeError("Invalid offset")
if offset > 1023 or offset < -1024:
instruction1 = 0xf000 | ((offset >> 11) & 0x7ff)
instruction2 = 0xb800 | (offset & 0x7ff)
patch_word(source, instruction1)
patch_word(source + 2, instruction2)
else:
instruction = 0xe000 | (offset & 0x7ff)
patch_word(source, instruction)
ea = here()
if get_wide_word(ea) == 0xb503: #PUSH {R0,R1,LR}
ea1 = ea + 2
if get_wide_word(ea1) == 0xbf00: #NOP
ea1 += 2
if get_operand_type(ea1, 0) == 1 and get_operand_value(ea1, 0) == 0 and get_operand_type(ea1, 1) == 2:
index = get_wide_dword(get_operand_value(ea1, 1))
print "index =", hex(index)
ea1 += 2
if get_operand_type(ea1, 0) == 7:
table = get_operand_value(ea1, 0) + 4
elif get_operand_type(ea1, 1) == 2:
table = get_operand_value(ea1, 1) + 4
else:
print "Wrong operand type on", hex(ea1), "-", get_operand_type(ea1, 0), get_operand_type(ea1, 1)
table = None
if table is None:
print "Unable to find table"
else:
print "table =", hex(table)
offset = get_wide_dword(table + (index << 2))
put_unconditional_branch(ea, table + offset)
else:
print "Unknown code", get_operand_type(ea1, 0), get_operand_value(ea1, 0), get_operand_type(ea1, 1) == 2
else:
print "Unable to detect first instruction"

მოათავსეთ კურსორი 0xB26A ხაზზე, გაუშვით სკრიპტი და ნახეთ გადასვლა 0xB4B0-ზე:

IDA-მ კვლავ არ აღიარა ეს ტერიტორია კოდად. ჩვენ ვეხმარებით მას და ვნახავთ სხვა დიზაინს იქ:

BLX-ის შემდეგ ინსტრუქციებს, როგორც ჩანს, არ აქვს აზრი, ეს უფრო რაღაც გადაადგილებას ჰგავს. მოდით შევხედოთ sub_4964:

და მართლაც, აქ დვორდი აღებულია LR-ში მდებარე მისამართზე, ემატება ამ მისამართს, რის შემდეგაც მიღებული მისამართის მნიშვნელობა აღებულია და იდება სტეკზე. ასევე, 4 ემატება LR-ს ისე, რომ ფუნქციიდან დაბრუნების შემდეგ იგივე ოფსეტი გამოტოვებულია. რის შემდეგაც POP {R1} ბრძანება იღებს მიღებულ მნიშვნელობას დასტადან. თუ დააკვირდებით რა მდებარეობს მისამართზე 0xB4BA + 0xEA = 0xB5A4, ნახავთ მისამართების ცხრილის მსგავსს:

ამ დიზაინის დასაყენებლად, თქვენ უნდა მიიღოთ კოდიდან ორი პარამეტრი: ოფსეტი და რეესტრის ნომერი, რომელშიც გსურთ შედეგის ჩასმა. თითოეული შესაძლო რეესტრისთვის, თქვენ მოგიწევთ წინასწარ მოამზადოთ კოდი.

patches = {}
patches[0] = (0x00, 0xbf, 0x01, 0x48, 0x00, 0x68, 0x02, 0xe0)
patches[1] = (0x00, 0xbf, 0x01, 0x49, 0x09, 0x68, 0x02, 0xe0)
patches[2] = (0x00, 0xbf, 0x01, 0x4a, 0x12, 0x68, 0x02, 0xe0)
patches[3] = (0x00, 0xbf, 0x01, 0x4b, 0x1b, 0x68, 0x02, 0xe0)
patches[4] = (0x00, 0xbf, 0x01, 0x4c, 0x24, 0x68, 0x02, 0xe0)
patches[5] = (0x00, 0xbf, 0x01, 0x4d, 0x2d, 0x68, 0x02, 0xe0)
patches[8] = (0x00, 0xbf, 0xdf, 0xf8, 0x06, 0x80, 0xd8, 0xf8, 0x00, 0x80, 0x01, 0xe0)
patches[9] = (0x00, 0xbf, 0xdf, 0xf8, 0x06, 0x90, 0xd9, 0xf8, 0x00, 0x90, 0x01, 0xe0)
patches[10] = (0x00, 0xbf, 0xdf, 0xf8, 0x06, 0xa0, 0xda, 0xf8, 0x00, 0xa0, 0x01, 0xe0)
patches[11] = (0x00, 0xbf, 0xdf, 0xf8, 0x06, 0xb0, 0xdb, 0xf8, 0x00, 0xb0, 0x01, 0xe0)
ea = here()
if (get_wide_word(ea) == 0xb082 #SUB SP, SP, #8
and get_wide_word(ea + 2) == 0xb503): #PUSH {R0,R1,LR}
if get_operand_type(ea + 4, 0) == 7:
pop = get_bytes(ea + 12, 4, 0)
if pop[1] == 'xbc':
register = -1
r = get_wide_byte(ea + 12)
for i in range(8):
if r == (1 << i):
register = i
break
if register == -1:
print "Unable to detect register"
else:
address = get_wide_dword(ea + 8) + ea + 8
for b in patches[register]:
patch_byte(ea, b)
ea += 1
if ea % 4 != 0:
ea += 2
patch_dword(ea, address)
elif pop[:3] == 'x5dxf8x04':
register = ord(pop[3]) >> 4
if register in patches:
address = get_wide_dword(ea + 8) + ea + 8
for b in patches[register]:
patch_byte(ea, b)
ea += 1
patch_dword(ea, address)
else:
print "POP instruction not found"
else:
print "Wrong operand type on +4:", get_operand_type(ea + 4, 0)
else:
print "Unable to detect first instructions"

ჩვენ ვათავსებთ კურსორს სტრუქტურის დასაწყისში, რომლის შეცვლაც გვინდა - 0xB4B2 - და ვაწარმოებთ სკრიპტს:

გარდა ზემოთ აღნიშნული სტრუქტურებისა, კოდი შეიცავს შემდეგს:

როგორც წინა შემთხვევაში, BLX ინსტრუქციის შემდეგ ხდება ოფსეტური:

ჩვენ ვიღებთ ოფსეტს LR-დან მისამართზე, ვამატებთ LR-ს და მივდივართ იქ. 0x72044 + 0xC = 0x72050. ამ დიზაინის სკრიპტი საკმაოდ მარტივია:

def put_unconditional_branch(source, destination):
offset = (destination - source - 4) >> 1
if offset > 2097151 or offset < -2097152:
raise RuntimeError("Invalid offset")
if offset > 1023 or offset < -1024:
instruction1 = 0xf000 | ((offset >> 11) & 0x7ff)
instruction2 = 0xb800 | (offset & 0x7ff)
patch_word(source, instruction1)
patch_word(source + 2, instruction2)
else:
instruction = 0xe000 | (offset & 0x7ff)
patch_word(source, instruction)
ea = here()
if get_wide_word(ea) == 0xb503: #PUSH {R0,R1,LR}
ea1 = ea + 6
if get_wide_word(ea + 2) == 0xbf00: #NOP
ea1 += 2
offset = get_wide_dword(ea1)
put_unconditional_branch(ea, (ea1 + offset) & 0xffffffff)
else:
print "Unable to detect first instruction"

სკრიპტის შესრულების შედეგი:

მას შემდეგ, რაც ყველაფერი დაყენებულია ფუნქციაში, შეგიძლიათ მიუთითოთ IDA მის რეალურ საწყისზე. ის აერთიანებს ყველა ფუნქციის კოდს და მისი დეკომპილირება შესაძლებელია HexRays-ის გამოყენებით.

სიმების დეკოდირება

ჩვენ ვისწავლეთ ბიბლიოთეკაში მანქანური კოდის დაბინდვასთან გამკლავება libsgmainso-6.4.36.so UC ბრაუზერიდან და მიიღო ფუნქციის კოდი JNI_OnLoad.

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

მოდით უფრო ახლოს მივხედოთ შემდეგ სტრიქონებს:

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

ფუნქციაში sub_73E24 კლასის სახელი აშკარად გაშიფრულია. ამ ფუნქციის პარამეტრებად, გადაცემულია დაშიფრული მონაცემების მსგავსი მონაცემების მაჩვენებელი, გარკვეული ბუფერი და რიცხვი. ცხადია, ფუნქციის გამოძახების შემდეგ ბუფერში იქნება გაშიფრული ხაზი, რადგან ის გადადის ფუნქციაზე FindClass, რომელიც იღებს კლასის სახელს მეორე პარამეტრად. აქედან გამომდინარე, რიცხვი არის ბუფერის ზომა ან ხაზის სიგრძე. ვცადოთ კლასის სახელის გაშიფვრა, მან უნდა გვითხრას, მივდივართ თუ არა სწორი მიმართულებით. მოდით, უფრო ახლოს მივხედოთ რა ხდება მასში sub_73E24.

int __fastcall sub_73E56(unsigned __int8 *in, unsigned __int8 *out, size_t size)
{
int v4; // r6
int v7; // r11
int v8; // r9
int v9; // r4
size_t v10; // r5
int v11; // r0
struc_1 v13; // [sp+0h] [bp-30h]
int v14; // [sp+1Ch] [bp-14h]
int v15; // [sp+20h] [bp-10h]
v4 = 0;
v15 = *(_DWORD *)off_8AC00;
v14 = 0;
v7 = sub_7AF78(17);
v8 = sub_7AF78(size);
if ( !v7 )
{
v9 = 0;
goto LABEL_12;
}
(*(void (__fastcall **)(int, const char *, int))(v7 + 12))(v7, "DcO/lcK+h?m3c*q@", 16);
if ( !v8 )
{
LABEL_9:
v4 = 0;
goto LABEL_10;
}
v4 = 0;
if ( !in )
{
LABEL_10:
v9 = 0;
goto LABEL_11;
}
v9 = 0;
if ( out )
{
memset(out, 0, size);
v10 = size - 1;
(*(void (__fastcall **)(int, unsigned __int8 *, size_t))(v8 + 12))(v8, in, v10);
memset(&v13, 0, 0x14u);
v13.field_4 = 3;
v13.field_10 = v7;
v13.field_14 = v8;
v11 = sub_6115C(&v13, &v14);
v9 = v11;
if ( v11 )
{
if ( *(_DWORD *)(v11 + 4) == v10 )
{
qmemcpy(out, *(const void **)v11, v10);
v4 = *(_DWORD *)(v9 + 4);
}
else
{
v4 = 0;
}
goto LABEL_11;
}
goto LABEL_9;
}
LABEL_11:
sub_7B148(v7);
LABEL_12:
if ( v8 )
sub_7B148(v8);
if ( v9 )
sub_7B148(v9);
return v4;
}

ფუნქცია sub_7AF78 ქმნის კონტეინერის მაგალითს მითითებული ზომის ბაიტის მასივებისთვის (ამ კონტეინერებზე დეტალურად არ ვისაუბრებთ). აქ ორი ასეთი კონტეინერი იქმნება: ერთი შეიცავს ხაზს "DcO/lcK+h?m3c*q@" (ადვილი მისახვედრია, რომ ეს გასაღებია), მეორე შეიცავს დაშიფრულ მონაცემებს. შემდეგი, ორივე ობიექტი მოთავსებულია გარკვეულ სტრუქტურაში, რომელიც გადაეცემა ფუნქციას sub_6115C. მოდი, ამ სტრუქტურაში ასევე მონიშნოთ ველი 3 მნიშვნელობით. ვნახოთ, რა მოუვა ამ სტრუქტურას შემდეგ.

int __fastcall sub_611B4(struc_1 *a1, _DWORD *a2)
{
int v3; // lr
unsigned int v4; // r1
int v5; // r0
int v6; // r1
int result; // r0
int v8; // r0
*a2 = 820000;
if ( a1 )
{
v3 = a1->field_14;
if ( v3 )
{
v4 = a1->field_4;
if ( v4 < 0x19 )
{
switch ( v4 )
{
case 0u:
v8 = sub_6419C(a1->field_0, a1->field_10, v3);
goto LABEL_17;
case 3u:
v8 = sub_6364C(a1->field_0, a1->field_10, v3);
goto LABEL_17;
case 0x10u:
case 0x11u:
case 0x12u:
v8 = sub_612F4(
a1->field_0,
v4,
*(_QWORD *)&a1->field_8,
*(_QWORD *)&a1->field_8 >> 32,
a1->field_10,
v3,
a2);
goto LABEL_17;
case 0x14u:
v8 = sub_63A28(a1->field_0, v3);
goto LABEL_17;
case 0x15u:
sub_61A60(a1->field_0, v3, a2);
return result;
case 0x16u:
v8 = sub_62440(a1->field_14);
goto LABEL_17;
case 0x17u:
v8 = sub_6226C(a1->field_10, v3);
goto LABEL_17;
case 0x18u:
v8 = sub_63530(a1->field_14);
LABEL_17:
v6 = 0;
if ( v8 )
{
*a2 = 0;
v6 = v8;
}
return v6;
default:
LOWORD(v5) = 28032;
goto LABEL_5;
}
}
}
}
LOWORD(v5) = -27504;
LABEL_5:
HIWORD(v5) = 13;
v6 = 0;
*a2 = v5;
return v6;
}

გადართვის პარამეტრი არის სტრუქტურის ველი, რომელსაც ადრე მიენიჭა მნიშვნელობა 3. შეხედეთ შემთხვევას 3: ფუნქციას sub_6364C პარამეტრები გადაეცემა სტრუქტურიდან, რომელიც დამატებულია იქ წინა ფუნქციაში, ანუ გასაღები და დაშიფრული მონაცემები. თუ კარგად დააკვირდებით sub_6364Cმასში შეგიძლიათ ამოიცნოთ RC4 ალგორითმი.

ჩვენ გვაქვს ალგორითმი და გასაღები. ვცადოთ კლასის სახელის გაშიფვრა. აი რა მოხდა: com/taobao/wireless/security/adapter/JNICLlibrary. დიდი! ჩვენ სწორ გზაზე ვართ.

ბრძანების ხე

ახლა ჩვენ უნდა ვიპოვოთ გამოწვევა რეგისტრაცია Natives, რომელიც მიგვანიშნებს ფუნქციაზე doCommandNative. მოდით შევხედოთ გამოძახებულ ფუნქციებს JNI_OnLoad, და ჩვენ მასში ვპოულობთ sub_B7B0:

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

და მართლაც, აქ რეგისტრირებულია მშობლიური მეთოდი სახელით doCommandNative. ახლა ჩვენ ვიცით მისი მისამართი. ვნახოთ რას აკეთებს.

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

სახელით შეგიძლიათ გამოიცნოთ, რომ აქ არის ყველა ფუნქციის შესვლის წერტილი, რომელიც დეველოპერებმა გადაწყვიტეს მშობლიურ ბიბლიოთეკაში გადატანა. ჩვენ გვაინტერესებს ფუნქციის ნომერი 10601.

კოდიდან ხედავთ, რომ ბრძანების ნომერი აწარმოებს სამ რიცხვს: ბრძანება/10000, ბრძანება % 10000/100 и ბრძანება % 10, ანუ ჩვენს შემთხვევაში, 1, 6 და 1. ეს სამი რიცხვი, ისევე როგორც მაჩვენებელი JNIEnv და ფუნქციაზე გადაცემული არგუმენტები ემატება სტრუქტურას და გადაეცემა. მიღებული სამი რიცხვის გამოყენებით (აღვნიშნოთ ისინი N1, N2 და N3) აგებულია ბრძანების ხე.

Რაღაც მსგავსი:

ხე ივსება დინამიურად JNI_OnLoad.
ხეში გზას სამი რიცხვი შიფრავს. ხის ყოველი ფურცელი შეიცავს შესაბამისი ფუნქციის მისამართს. გასაღები არის მშობლის კვანძში. კოდში იმ ადგილის პოვნა, სადაც ჩვენთვის საჭირო ფუნქცია ემატება ხეს, არ არის რთული, თუ გესმით გამოყენებული ყველა სტრუქტურა (ჩვენ არ აღვწერთ მათ ისე, რომ არ გავფუჭოთ უკვე საკმაოდ დიდი სტატია).

მეტი დაბნეულობა

ჩვენ მივიღეთ ფუნქციის მისამართი, რომელმაც უნდა გაშიფროს ტრაფიკი: 0x5F1AC. მაგრამ ჯერ ადრეა გახარება: UC Browser-ის დეველოპერებმა მორიგი სიურპრიზი მოამზადეს ჩვენთვის.

პარამეტრების მიღების შემდეგ მასივიდან, რომელიც ჩამოყალიბდა Java კოდში, ვიღებთ
ფუნქციას მისამართზე 0x4D070. და აქ სხვა ტიპის კოდის დაბინდვა გველოდება.

ჩვენ ვაყენებთ ორ ინდექსს R7 და R4-ში:

ჩვენ გადავიტანთ პირველ ინდექსს R11-ზე:

ცხრილიდან მისამართის მისაღებად გამოიყენეთ ინდექსი:

პირველ მისამართზე გადასვლის შემდეგ გამოიყენება მეორე ინდექსი, რომელიც არის R4-ში. ცხრილში 230 ელემენტია.

რა უნდა გააკეთოს ამაზე? თქვენ შეგიძლიათ უთხრათ IDA-ს, რომ ეს არის გადამრთველი: Edit -> Other -> Specify switch idiom.

შედეგად მიღებული კოდი საშინელია. მაგრამ, მის ჯუნგლებში გავლისას, თქვენ შეამჩნევთ ჩვენთვის უკვე ნაცნობ ფუნქციაზე ზარს sub_6115C:

იყო ჩამრთველი, რომელშიც მე-3 შემთხვევაში მოხდა გაშიფვრა RC4 ალგორითმის გამოყენებით. და ამ შემთხვევაში, ფუნქციაზე გადაცემული სტრუქტურა ივსება გადაცემული პარამეტრებიდან doCommandNative. გავიხსენოთ რა გვქონდა იქ magicInt მნიშვნელობით 16. ვუყურებთ შესაბამის შემთხვევას - და რამდენიმე გადასვლის შემდეგ ვპოულობთ კოდს, რომლითაც შესაძლებელია ალგორითმის იდენტიფიცირება.

ეს არის AES!

ალგორითმი არსებობს, რჩება მხოლოდ მისი პარამეტრების მიღება: რეჟიმი, გასაღები და, შესაძლოა, ინიციალიზაციის ვექტორი (მისი არსებობა დამოკიდებულია AES ალგორითმის მუშაობის რეჟიმზე). მათთან სტრუქტურა სადღაც ფუნქციის გამოძახებამდე უნდა ჩამოყალიბდეს sub_6115C, მაგრამ კოდის ეს ნაწილი განსაკუთრებით კარგად არის ბუნდოვანი, ამიტომ ჩნდება იდეა კოდის დაყენება ისე, რომ გაშიფვრის ფუნქციის ყველა პარამეტრი გადაიტანოს ფაილში.

პატჩი

იმისათვის, რომ არ დაწეროთ ყველა პატჩი ასამბლეის ენაზე ხელით, შეგიძლიათ გაუშვათ Android Studio, დაწეროთ ფუნქცია, რომელიც მიიღებს იმავე შეყვანის პარამეტრებს, როგორც ჩვენი გაშიფვრის ფუნქციას და წერს ფაილში, შემდეგ დააკოპირეთ და ჩასვით კოდი, რომელსაც კომპილერი გააკეთებს. გენერირება.

ჩვენი მეგობრები UC Browser-ის გუნდიდან ასევე ზრუნავდნენ კოდის დამატების მოხერხებულობაზე. შეგახსენებთ, რომ ყოველი ფუნქციის დასაწყისში გვაქვს ნაგვის კოდი, რომელიც ადვილად შეიძლება შეიცვალოს ნებისმიერი სხვა. ძალიან მოსახერხებელია 🙂 თუმცა, სამიზნე ფუნქციის დასაწყისში არ არის საკმარისი ადგილი კოდისთვის, რომელიც ინახავს ყველა პარამეტრს ფაილში. მომიწია მისი ნაწილებად დაყოფა და მეზობელი ფუნქციების ნაგვის ბლოკების გამოყენება. სულ ოთხი ნაწილი იყო.

პირველი ნაწილი:

ARM არქიტექტურაში პირველი ოთხი ფუნქციის პარამეტრი გადაეცემა რეგისტრებში R0-R3, დანარჩენი, ასეთის არსებობის შემთხვევაში, გადადის სტეკის მეშვეობით. LR რეესტრი შეიცავს დაბრუნების მისამართს. ეს ყველაფერი უნდა იყოს შენახული, რათა ფუნქციამ იმუშაოს მას შემდეგ, რაც ჩვენ გადავაგდებთ მის პარამეტრებს. ჩვენ ასევე უნდა შევინახოთ ყველა რეგისტრი, რომელსაც გამოვიყენებთ პროცესში, ამიტომ ვაკეთებთ PUSH.W {R0-R10,LR}. R7-ში ვიღებთ სტეკის მეშვეობით ფუნქციაზე გადაცემული პარამეტრების სიის მისამართს.

ფუნქციის გამოყენებით გაშლილი გავხსნათ ფაილი /data/local/tmp/aes "აბ" რეჟიმში
ანუ დასამატებლად. R0-ში ვტვირთავთ ფაილის სახელის მისამართს, R1-ში - რეჟიმის აღმნიშვნელი ხაზის მისამართი. და აქ ნაგვის კოდი მთავრდება, ამიტომ გადავდივართ შემდეგ ფუნქციაზე. იმისთვის, რომ მან გააგრძელოს მუშაობა, თავიდან ვათავსებთ ფუნქციის რეალურ კოდზე გადასვლას ნაგვის გვერდის ავლით და ნაგვის ნაცვლად ვამატებთ პაჩის გაგრძელებას.

რეკავს გაშლილი.

ფუნქციის პირველი სამი პარამეტრი Aes აქვს ტიპი int. ვინაიდან რეგისტრები თავიდანვე შევინახეთ სტეკში, შეგვიძლია უბრალოდ გადავიტანოთ ფუნქცია დაწერე მათი მისამართები დასტაზე.

შემდეგი, ჩვენ გვაქვს სამი სტრუქტურა, რომელიც შეიცავს მონაცემთა ზომას და მითითებულ მონაცემებს გასაღებისთვის, ინიციალიზაციის ვექტორისთვის და დაშიფრული მონაცემებისთვის.

დასასრულს, დახურეთ ფაილი, აღადგინეთ რეგისტრები და გადაიტანეთ კონტროლი რეალურ ფუნქციაზე Aes.

ჩვენ ვაგროვებთ APK-ს დაყენებული ბიბლიოთეკით, ხელს ვაწერთ მას, ვტვირთავთ მოწყობილობაზე/ემულატორზე და გავუშვით. ჩვენ ვხედავთ, რომ ჩვენი ნაგავსაყრელი იქმნება და იქ უამრავი მონაცემი იწერება. ბრაუზერი იყენებს დაშიფვრას არა მხოლოდ ტრაფიკისთვის, და ყველა დაშიფვრა გადის მოცემულ ფუნქციაზე. მაგრამ რატომღაც საჭირო მონაცემები არ არის და საჭირო მოთხოვნა არ ჩანს ტრაფიკში. იმისათვის, რომ არ დაველოდოთ UC Browser-ის მიერ საჭირო მოთხოვნის განსახორციელებლად, ავიღოთ დაშიფრული პასუხი ადრე მიღებული სერვერიდან და კვლავ დავაყენოთ აპლიკაცია: დავამატოთ გაშიფვრა onCreate-ზე მთავარი აქტივობა.

    const/16 v1, 0x62
new-array v1, v1, [B
fill-array-data v1, :encrypted_data
const/16 v0, 0x1f
invoke-static {v0, v1}, Lcom/uc/browser/core/d/c/g;->j(I[B)[B
move-result-object v1
array-length v2, v1
invoke-static {v2}, Ljava/lang/String;->valueOf(I)Ljava/lang/String;
move-result-object v2
const-string v0, "ololo"
invoke-static {v0, v2}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I

ვაწყობთ, ვაწერთ ხელს, ვაყენებთ, გავუშვით. ჩვენ ვიღებთ NullPointerException, რადგან მეთოდმა დააბრუნა null.

კოდის შემდგომი ანალიზის დროს აღმოჩნდა ფუნქცია, რომელიც გაშიფრავს საინტერესო ხაზებს: “META-INF/” და “.RSA”. როგორც ჩანს, აპლიკაცია ამოწმებს თავის სერტიფიკატს. ან თუნდაც მისგან კლავიშების გენერირებას. მე ნამდვილად არ მსურს შევეხო იმას, რაც ხდება სერთიფიკატთან დაკავშირებით, ასე რომ, ჩვენ მას მხოლოდ სწორ სერთიფიკატს გადავცემთ. მოდით დავაყენოთ დაშიფრული ხაზი ისე, რომ "META-INF/"-ის ნაცვლად მივიღოთ "BLABLINF/", შევქმნათ საქაღალდე ამ სახელით APK-ში და დავამატოთ squirrel ბრაუზერის სერტიფიკატი.

ვაწყობთ, ვაწერთ ხელს, ვაყენებთ, გავუშვით. ბინგო! ჩვენ გვაქვს გასაღები!

MitM

მივიღეთ გასაღები და გასაღების ტოლი ინიციალიზაციის ვექტორი. შევეცადოთ სერვერის პასუხის გაშიფვრა CBC რეჟიმში.

ჩვენ ვხედავთ არქივის URL-ს, MD5-ის მსგავსს, „extract_unzipsize“ და რიცხვს. ჩვენ ვამოწმებთ: არქივის MD5 იგივეა, შეუფუთავი ბიბლიოთეკის ზომა იგივეა. ჩვენ ვცდილობთ დავაყენოთ ეს ბიბლიოთეკა და მივცეთ იგი ბრაუზერს. იმის საჩვენებლად, რომ ჩვენი დაყენებული ბიბლიოთეკა ჩატვირთულია, ჩვენ გავუშვით SMS-ის შექმნის განზრახვა ტექსტით „PWNED!“ ჩვენ შევცვლით სერვერის ორ პასუხს: puds.ucweb.com/upgrade/index.xhtml და ჩამოტვირთეთ არქივი. პირველში ვცვლით MD5-ს (ზომა არ იცვლება შეფუთვის შემდეგ), მეორეში ვაძლევთ არქივს შეფუთული ბიბლიოთეკით.

ბრაუზერი რამდენჯერმე ცდილობს არქივის ჩამოტვირთვას, რის შემდეგაც შეცდომას უშვებს. აშკარად რაღაც
მას არ მოსწონს. ამ ბუნდოვანი ფორმატის გაანალიზების შედეგად, აღმოჩნდა, რომ სერვერი ასევე გადასცემს არქივის ზომას:

ის დაშიფრულია LEB128-ში. პატჩის შემდეგ, ბიბლიოთეკის არქივის ზომა ოდნავ შეიცვალა, ამიტომ ბრაუზერმა ჩათვალა, რომ არქივი არასწორად იყო გადმოწერილი და რამდენიმე მცდელობის შემდეგ მან შეცდომა დაუშვა.

ვასწორებთ არქივის ზომას... და – გამარჯვება! 🙂 შედეგი არის ვიდეოში.

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

შედეგები და დეველოპერის რეაქცია

ანალოგიურად, ჰაკერებს შეუძლიათ გამოიყენონ 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