Proguard Observations: bundling assets in assets not raw (since Android Studio)

I love Proguard. For years I stuck religiously to C and C++. After some of my work got loose in the wild I began to appreciate the commercial merits of Java. At the very least in Android.

When your C code tombstones might as well have occurred in some one else's code you are depending on it makes sense to stick with the hurd, that's Java. My mixed mode apps did not focus on making my Java private, I had relied on C and C++ for that. Android Studio abandoned C / C++ development.

Proguard can be made to work very easily in Android Studio. Me saying this and you observing are 2 completely different things so I encourage you to learn about reverse engineering with apktool. You will probably have already used Google's own reverse engineering tools day to day when you view read-only source code from a decompiled library.

Apktool produces smali that is architecturally equivalent to the original obfuscated Java. Obfuscation is Proguard's thing. Smali has the distinct advantage of being amenable to direct recompilation from apktool itself. Apktool is the most frequently updated reverse engineering tool external to Google (developed by iBotPeaches from XDA). Smali is still obscure though. I've seen so little of it in books and tutorials that I wonder just how removed from Java byte code it can actually be. Keep your sanity and relevance, without having to learn smali. Other tools, especially dex2jar and JD-GUI do the business of reverse engineering. Using these I was able to make the following observations about proguard and Android Studio.

Problem

I have an html file in res/raw:

By default res/raw links from generated 'R' files are broken by proguard. Trying the following option doesn't help this

-keep class *.R

Eric Lafortune alluded to there being reasons for Proguard's default behaviour somewhere on SO. The following is needed but it means all aliases from the massive 'R' file are readily accessible to a decompiler:

-keep class *.R
-keepclasseswithmembers class **.R$* {public static <fields>;}

Solution 1: try using res/assets instead of res/raw

myWebView.loadUrl("file:///android_asset/help.html");

This has exactly the same effect. The page doesn't load after proguard. I know I can hard link the HTML string but for now I need to document this bug so I don't return to it later.

To be thorough, I tried just

-keepclasseswithmembers class **.R$* {public static <fields>;}

and using the asset (assets) directory. This time I can see that all the R$* classes are present in the rev-eng'd project. All except the R$raw I'd just obviated. No R$assets? No nothing. I must be doing something wrong, and I was.

Ignoring CommonsWare earlier advice:

I am asking this because if you have a button with an id btnSaveArticle, for a hacker it becomes too easy to grasp what the code around is doing by looking at the name.

Using Hierarchy View, it would take them less than 30 seconds to determine the actual ID of the "Save Article" button, no matter what you name it. And I can envision even faster solutions with a bit of custom tooling.

am I wasting my time?

IMHO, yes.

answered Aug 16 '13 at 12:54

CommonsWare

On a seperate thread his wisdom shone:

Since Android Studio uses the new Gradle-based build system, you should be putting assets/ inside of the source sets (e.g., src/main/assets/), if I understand correctly.

Of course I am still wasting mine and my user's time because placing the html in assets prevents it from accessing other folders, where, for example, icons might be found.

Or they might not.

MLais M52 Teardown

I got stuck trying to swap SIMs and decided the put on engineers that delivered this bargain machine for £85 had not tested this and that the pins had some how bent to deny me access. As will become apparent it was the metal girdle pressing the SIM card against the contacts that was the culprit, or, more specifically, a wayward curl of plastic from the SIM itself blocking (easily removed with a sharp blade).

Anyway, on with the teardown:

The boards are visible after the usual procedure to remove the back plastic:

1. battery out, then hold the power to short any residual charge
2. undo screws (about a dozen on this monster) including one with a security sticker on it, they can be tight so have a good bit
3. nails or if they matter plastic like a toothpick

Both camera modules are instantly accessible and should their interface ever become standardised (#ahem# #project ara# #ahem#) we could find drop in replacements. I've been looking at many camera modules, for many uses, mostly for quad copters, and sadly nothing is standardised at the level of integration of flagship phone cameras.

Got your cameras out and away from dust and harm? Good. These are the locations (drawn in mauve) of the electrical connections that must be unfastened for the circuit board to be levered out.

That's showing them undone. I should go through them one by one so you needn't sweat it about breaking any when you try. Does anyone still do this or is it just the Know-How team at PC World when they grade their computers refurbished? Here goes, clockwise from the power button at the bottom left.

1. Power button - tricky this as you kneed a sharp blade slid precisely along the plastic shell to lever up the flexible button. It will retain most of its stickyness and has mechanical fixation by other means.
2. Wide ribbon - flip up the black lever where the cable enters.
3. Main camera module - lift directly up applying even force if you're careful.
4. Goodix orange chip ribbon - flip the black lever at the back where it pins the ribbon.
5. Front camera - pull connector directly upwards, don't worry about the black tape on top, it isn't connected elsewhere
6. Volume button ribbon - afforded its own ribbon connector! No expense spared! Like the Goodix connector of similar size, flip the black lever from the opposite side of cable entry

Next undo the screws, again they can be tight for a mobile phone. There are 3 in the photo but I struggled for a long time prising up the PCB because another screw is hidden under the silver tape where the connector for the volume button ribbon is opened. Carefully peel the tape back, using a sharp blade for a clean initial purchase. Don't worry too much, it's quite sticky still and there isn't really an alternative. It helps keep temperatures down.

With the 4 screws removed one proceeds to lever the PCB up from the top, be very careful at the bottom because there is a broad ribbon I couldn't find a way to disconnect running behind the battery. I must record here, because it isn't in any of  my pictures, that I couldn't find how to undo this last connector, on my Lenovo teardown it's a vertical plug in connector like the two camera modules here.

This is the rear of the PCB in all its glory. The blue square is very likely masking the MT6572, I can see the beginning of an M and it is right the size and place with enough attention given to cooling. Trying to remove the blue foam leaves a layer on the chip which isn't convenient when all the while that stubborn last ribbon is the last link between PCB and phone. With more experience and motivation I'm sure I could deal with both obstacles.

The chip models might be some use to ROM developers so here they all are beginning from the front:

What's this? Behind a heatsink the inscription,
6671122.1
1510 NX
is visible (or HX or even MX)

GOODIX
GT9157
1443-B37A
147C1200
E5L 401 xxxx (or E5I)
see http://www.goodix.com/Products/touchscreen-chip-for-mobilephone/hotknot/
This is our touchscreen controller and supports a form of NFC screentouch communication called "HotKnot" (probably only with other GT9157s)

Primary camera, ribbon marking is
JAL-JBL
-A128B
(8604)

Front camera ribbon markings:
JAL-JBL-
A128F(4-8)

On The Flip Side

a radio transceiver
MEDIATEK
MT6169V
1513-AMTH
BTP2NV39

The 2Gb DDR3 ram
SAMSUNG 516
KMR820001M-B609
Some probably unique number.


Other phones with the MT6169V
Pioneer K88L
Meizu-MX4
TCL Momoda 4G

After reading some other teardowns I notice that they aren't so easy to find and the MLais is not very anti-tamper for my part. There are some metal screens I didn't try very hard to look behind but much less than on equivalent phones, though the phones listed above do tend to have many more chips than I discovered, they are a bit older, or perhaps I am missing some.

Restore IMEI with IMEI&SN Writer

Restore Lenovo A820's IMEI with IMEI&SN Writer

If you don't understand something or have any doubts don't do it, I take no responsibility for relaying my experience here. This is taken from my much longer post Driver Sanity in Windows, Restoring IMEI to Lenovo A820 with all dead ends and fails removed. I can only support the single method tested herein.

When I get a new MTK phone, the instructions for that don't consider I might already have drivers installed. This can lead to driver conflicts. Another thing you should beware of before asking for help is that you don't have devices flagged in Device Manager. If your Device Manager looks as flat as this:

Then this isn't a problem for you and you can continue to the Out With the Old (Unseen Driver Conflicts) section.

Install Missing Manufacturer / OEM (eg Dell, HP, Acer etc) Drivers

For years I put up with an unidentified, but disabled "Simple PCI communication interface" or "Simple PCI communication controller". Only after struggling to connect my phone on a VCOM/COM port did I decide keeping this motherboard device deactivated might be a bad idea. I dug out my original factory "drivers and apps" disk and put it in the DVD drive. About 3 minutes later it loaded :)

It wasn't necessary to use the manufacturer's installer. I activated the offending hardware from device manager and either uninstalled it first or just showed it to my DVD drive (more on this process in just a moment, it is this process that is the crux of this document). Windows very efficiently installed just the driver and none of the bloat, it was a minor device I might have lived without.

Out With the Old (Unseen Driver Conflicts)

Consider the following where Lenovo Composite ADB Interface is in some way undesirable:

 

 
You may have previous installations cached allowing Windows to automagickly reinstall the device. Every time this happens repeat the above procedure to arrive at a "clean" installation w.r.t. this particular driver.

I stress this is only for third party drivers, things Windows or your OEM may have preinstalled, may be harder to find better/correct drivers for.

When Window's cache of drivers is empty it will either either ask you for one or list it in Device Manager with an exclamation mark nest to it. Job done.

Restoring IMEI

You'll notice in previous screenshots the "Ports (COM & LPT)" entry is displayed in Device Manager. The problem with my VCOM driver was that, initially, it was only fleetingly visible the instant a connection was made with the powered down phone. Device Manager would flicker, display the entry for a second, then flicker again removing all mention of "Ports (COM & LPT)". You have just a second to right click an offending driver. Once right clicked the clock stops and you can carefully click uninstall. Then tab away and check the instructions. If you have to open the "Ports (COM & LPT)" you'll almost certainly miss it and get frustrated fast. If you have something else there, that's one less click you need in that second. That's why my "Ports (COM & LPT)" is visible, a modem or (old) printer can be used for this purpose.

This driver is essential for META mode to connect your phone with the low level MTK tools. The correct driver will maintain an entry in "Ports (COM & LPT)" all the while the phone is connected in META mode. My driver, from previous ROM upgrades and subsequent phone purchases proved incorrect.

To be sure of any driver's provenance you must uninstall all previous drivers as outlined in the Out With the Old (Unseen Driver Conflicts) section above. To know when Windows is ready for the correct driver watch for an exclamation mark on the entry, in the case of this particular device the entry will read, "MT65xx Preloader".

At this point you can install the new driver(s). The file I was given was DriverInstall_v5.14.53_WinXP_Win7.exe,

MD5: aefe6fc53400b8f9a313cbacd4a4f50b,
SHA1: 2f12e07f5785defb81e9f8ab7e501b5d951c8c0f

published my MediaTek. When I go to install it Windows warns that the publisher is unknown. Continue as any other installation. When you are asked (in red!) to install an unsigned driver, go for it, four times! I think this is just MediaTek being cheap not getting MicroSoft to sign and test their drivers. MicroSoft's high false positive rate causes users to blithely dismiss all sorts of security warnings. I don't guarantee these drivers, I use them as do many others.

I'd actually just dismissed exactly four of these warnings installing for my other phone's ROM, with an entirely different installer, a script, so I "knew" what was happening. It would install the unsigned drivers first then install the signed ones over the top. Often signed drivers don't work so I was happy  to try unsigned.

With just these drivers installed they should be sufficient to enter META mode. I'd never before been asked to install four consecutive unsigned drivers in a row, MLais publish a how-to telling me to do this, so now I do.

ADB Drivers

I believe my old VCOM driver was being supplied by the SP_Driver_v1.x pack and causing incompatibility. I can't describe how to install these and ADB drivers here, that is outside the scope of this article. Approved drivers are:

sp_drivers_v1.5_lenovo.zip:

MD5: 2e9d1ca627056703f471f2bbe1b199ea
SHA1: 79bbc822e6af5d394ccabe229a8a2640bf146848

I instead used SP_Drivers_EXE_v1.6 from Pakyto's "RESTAURAR IMEI.zip"

MD5: 0be4b2fb53c18d9bc392e5e4cc6f6972
SHA1: d483be492df8785efe00b4416e5f7ba9229895e8

Software Sources

I didn't ultimately use Pakyto's apdb_modemdb_A820 because the name of his Modem Database included P780 instead of A820.

(from Pakyto)
BPLGUInfoCustomAppSrcP_MT6589_S00_P780_V23

MD5: 0f244cd43a65b9aee65a31b73cbcc00c
SHA1: c6a5a4102c77fbb2493323bc7c9ae9f458a506a7

APDB_MT6589_S01_MAIN2.1_W10.24

MD5: 80a45a9bb5bd5416692901de6974d871
SHA1: 76638fb9cd4234437a5c64f149134b9cb81bcae8

The following are more A820 specific:

(from https://yadi.sk/d/ylJyJbDjZWm7k, from http://www.mcrf.ru/forum/archive/index.php/t-36527.html)
apdb_modemdb_A820.7z

MD5: f770b3e08a5ec076b592493b38591d44
SHA1: 062578a596b90d05b1cf6a2c37bff324740cc3d6

BPLGUInfoCustomAppSrcP_MT6589_S00_A820_V16

MD5: f5a6a5a28ee227533ccb41c35e7155db
SHA1: 8d41e8d604cc9c4a750b7eb9305f641746d2691f

APDB_MT6589_S01_MAIN2.1_W10.24

MD5: 80a45a9bb5bd5416692901de6974d871
SHA1: 76638fb9cd4234437a5c64f149134b9cb81bcae8

 from somewhere I found:

imei&sn writer v1.5.3.rar

MD5: 52f43ae9e73b2279493977ad4f9b68ac
SHA1: f15224419dd9bc440bc006ff53d5efef53fefed5

which contains the 2012 tool IMEI&SN Writer.exe

IMEI&SN Writer

It reported a success when I just flashed the IMEI:

Success, but I was too tired to remember to what extent. In any case it wasn't acceptable so I repeated with all the fields filled in and it fixed it.

For step 3, Select DB, use the files described above in Software Sources, or google "apdb_modemdb_A820" and see my checksums. Or try the following (verified).

IMEI&SN Writer V1.5.3.7z (3.25Mb)
MD5: 955fc522fd47376e6f7e3c6e3b1b9fc0
SHA1: dd6e0c0a80a57502c6d8fe2436dd6fc6a19e8798

apdb_modemdb_A820_20150729.7z (5.34Mb)
MD5: 6e6ee6541b5800e8386da1ba7436a9da
SHA1: e80700159bc31ba2d94cdfbfeb351b023e581e2f