As you all know, Google has introduced developer verification as a way to prevent users from installing “unregistered” APKs. This measure was taken as a security feature to link every APK in existence to its developer, as in Play Store.

Link to the Android documentation, link to FAQ

Why this is bad

This has already been discussed by ArsTechnica and on some threads (some cherry-picked ones): reddit, ycombinator, hackaday.

A quick recap of the main points (as of 30 Oct 2025):

• The base tier costs $25, as in Play Market. Requires an ID
• There will be a limited “hobbyist” unpaid license. Google claims that they won’t require an ID
• Legal info is told to be private, unlike with Play Market
• The verification code is supposed to be located in Play Services, but Google hasn’t published the source code yet
• Google assures that it would be possible to install applications locally using ADB, but there are no details on this
• Hobbyist license restrictions are unknown

A few months prior Google has decided to make Android development private, which seems to be a preparation for the upcoming changes (another article). Due to this change in AOSP release format, it is no longer possible to track what exactly Google is doing.

My answer to this question is that it would simply prevent small developers from distributing their apps, including myself. If we take the legal route, a hobbyist license is supposed to have some limit on the number of installs by design. If we take, say, 10K installs, this is not enough in my case. Another question is how exactly the process of verification is going to happen, what if Google adopts the same rules as in Play Store? Taking my fork of the old VN engine port, this apk would not pass security checks, as the old codebase relies on legacy external storage permissions, which are banned in Play Store. If we take the adb route, there are no guarantees that this method is going to work in the future in the form you expect. For instance, Google mentions that this method is meant for on-device tests during development, and nothing prevents them from reporting the install to their servers and checking if a self-signed apk has been installed on other devices. Another way to put it, this is problematic for an average Android user to perform these steps, and this is going to be the developer’s problem.

The situation links pretty well with Samsung removing bootloader unlocking with the One UI 8 update. Great, duh…

The concept

My vision of the hack is to distribute a verified loader apk, which in turn dynamically loads any apk the user wants. A user obtains the loader apk once and loads apps without installing as much as they want.

The Java virtual machine in Android is the ART/Dalvik runtime (I will refer to it as Dalvik, it seems that Google hates cool names). Did you know that Dalvik natively allows dynamic code execution using PathClassLoader? So an apk may just load some zip/apk/dex code from external storage and execute it in current context. Essentially, this means that we can natively load the apk into memory and execute any code inside of the target apk, and we are not altering the original code signature of the loader.

In order to actually run the apk, the loader needs to properly initialize the main activity (aka the main screen, or the entrypoint) of the target apk. So, the main activity needs to be initialized and somehow placed inside of the Android’s activity cycle with the loader acting as a wrapper. Then, the loader apk should handle other aspects like local files handling and names conflict resolution. This can be achieved by patching the target apk bytecode: .odex/.dex classes may be dynamically decompiled into .smali, analyzed and compiled back into a modified apk. Furthermore, the loader would have to parse AndroidManifest options of the target (main activity location, screen options).

Implementation

Developing such wrapper in a straightforward way has proven to be rather difficult, as Android activity management logic is extremely complicated and differs from version to version. In short, it was problematic to perform the initialization process the right way. Some people suggested to avoid the initialization step completely, and use Unsafe Dalvik api to register the target’s activity as the loader apk activity stub, which is declared in the loader’s manifest without class. I couldn’t find exact methods in the Unsafe documentation, but this actually may be a way to go.

Due to this particular issue I couldn’t bring the proof of concept to a working state in a reasonable time, and because of this I was considering to not publish this article at all. The purpose of this post is not to give a somewhat ready solution, but get some feedback on the concept, as I was not ready to devote lots of time on a potentially broken solution.

The logistics

Information provided in this section is for educational use only, all scenarios discussed below are hypothetical.

In order to install the loader apk on the device, it would require, well, some form of verification. Hobbyist license is the only choice here, as paying $25 for each attempt is not optimal. Since the hobbyist license has a limited number of installs, there should be multiple instances of the apk with separate licences. In this hypothetical scenario there may either be a pool of volunteers who sign the code, or completely random users who are willing to help. In the second case, the loader code would somehow need to be verified or scanned, since such distribution system would be vulnerable to malware.

The final and the most important issue in this process is the verification process itself, as the loader code may (and likely will) be flagged by Google. So, the code would require some form of obfuscation like code flow modification and implementing double functionality (for instance, registering it as a file manager). If Google decides to ban dynamic code loading altogether, the final solution would be to pack the Dalvik runtime into the loader as a native library. This of course would have extremely low performance, but it should be technically possible.

Overall, the hypothetical plan has lots of assumptions, with which I’m not happy with. First of all, it requires lots of manual work by the volunteers or random people, and this work also includes the apk obfuscation, which was not discussed in detail. Then, the verification process itself should be somewhat permissive to allow potentially suspicious apps (I would like to hear how does this happen with current Play Store verification).

Conclusion

The project described in this article by no means is a finished solution, and if you have started to think what else could work, it means that the article has reached its original goal. I believe that we would eventually come up with a proper solution in the future. Thank you for reading!

You may find the source code here. Feel free to create an issue if you wish to discuss

Update 1

Linking the ycombinator thread here.

The most common reaction to this post was “why bother, there exists adb and Shinzuku”.

Why we should bother

We can only hope that Google allows to install distributed APKs over adb in the future, as they explicitly stated that they will allow this for developers to test their own APKs:

As a developer, you are free to install apps without verification with ADB. This is designed to support developers’ need to develop, test apps that are not intended or not yet ready to distribute to the wider consumer population

It is possible for them to do the following:

• Limit the number of installs of an unverified APK, limit it to a single device or go the Apple way (uninstall app after a time limit). This technically won’t prevent developers from testing their apps
• Make it harder to unlock the developer options by requiring some kind of verification that you are a developer. This seems to be less likely, since it’s quite tricky to implement.

There is no reason to dismiss this scenario, as it aligns with Google’s recent actions against power users like making AOSP development private, not publishing Pixel device trees and irrationally trying to ban ad blockers on Youtube (though the last point is partially related to Android through Vanced). If the subset of users who utilize adb is going to be large enough (and it will be), what exactly is stopping them from doing something about it?

Efficiency

Another opinion was that it is “not a good idea to try and find a technical solution to a people/organisation problem”. Furthermore, if such solution is implemented, it is going to require too much effort to maintain, as each upload is going to be almost immediately banned by Google. I absolutely agree with both of these takes, since the apk loader developers are likely going to give up sooner or later.

In this post I’ve made a critical mistake of not putting the emphasis on the removal of bootloader unlock, since in fact it’s indeed awful, as it makes people stuck with Google’s restrictions in the first place. While the first move was done by Samsung, it’s still very alarming as a precedent. Right now the situation with AOSP-based ROMs is not great, as you have to own a specific device like a Pixel or OnePlus model, and Google keeps messing with AOSP. The true hope here are root-based solutions, as they work on stock Android - I hope that they are not going to go anywhere in the future.

(Feel free to skip to the Bill Gates section for the non-technical part)

While I was working on my first preprint mid-May, my Steam Deck suddenly broke. The charging circuit couldn’t negotiate the voltage, something went wrong and the smart battery controller entered in permanent failure mode. We managed to desolder the lithium cells from the battery package PCB and replaced the fuse, but the controller still wouldn’t take charge. While reading the bq40zxy protocol, I’ve discovered that it is possible to disable PERMANENT FAILURE mode by calling a special ManufacturerAccess Smart Battery System (SBS) command, which is done over the SMBus. And so, the adventure began.

How do I talk to the SBS controller?

As SMBus is derived from I2C and these protocols are closely related, the intuition was that I could access SMBus using the i2c-tools driver, which provides this functionality using <i2c/smbus.h>. I wrote a simple SBS utility, tested the devices which exposed the 0xb battery address and got… nothing. The only responding device returned plain zeros. I was trying to find the mistake in my code, cross-checked every line in my code against another SBS driver (ROS node) implementation, but I didn’t find any error. The reason was that in my case the SMBus was simply connected to the embedded controller (EC), not the I2C bus.

Into the EC rabbithole

Embedded Controller (aka EC, SuperIO) is the modern IBM PC equivalent of various I/O logic circuitry which handles legacy stuff (PS/2, floppy, serial and parralel ports) and modern subsystems (ACPI, GPIO, fan, thermals, SMBus, etc). The main way to communicate to the controller is through the kernel using the linux/drivers/acpi/ec.c driver, which effectively writes to the CPU IO pins as described in this article on I/O ports usage. ec_read() and ec_write() commands are great, but I don’t know neither the addressnor the protocol format for telling the EC chip to execute the SMBus transaction. At this point there is almost no documentation on this kind of stuff, so the best bet was to analyze how the kernel operates with the hardware.

Thankfully, the kernel already has the driver for communicating to the SBS over SMBus through EC: linux/drivers/acpi/sbs.c handles the SBS protocol, while linux/drivers/acpi/sbshc.c performs direct calls to the EC and executes SMBus transactions. So I started digging how this driver works and found that it finds ACPI devices with hid equal to ACPI0001 or ACPI0005, calls the ACPI _EC method and calculates the value (val >> 8) & 0xff; as the address to send SMBus packages. Huh.. This is an oddly specific way to simply start talking to the bus. At least the kernel driver handles.. it does not. The driver couldn’t load the device. In order to investigate this, I needed to try calling this method and seeing what it outputs. (As at that time I haven’t lost the hope in finding the solution yet, I’ve tried writing the userspace driver to avoid writing a whole kernel module. Wasted lots of time and ended up writing the sbsctl module. Silly me…)

This started to get weird, since there were no devices with such HIDs. I thought that the device could be under a different hid, but calling the exact same _EC module as in sbshc.c resulted in failure for the most likely candidates. At the same time ec.c successfully found the EC under \_SB_.PCI0.LPC0.EC0_, but this device doesn’t have a _EC method! Like.. What? How do I get the offset then?

This is where the fun begins

Long story short, the OS needs some standardized way to access various devices, since it doesn’t know which devices are present and how to access them. ACPI is the interface between the motherboard (hardware) components and the OS which is designed to do exactly this: act as a robust layer between software and hardware, which minimizes the chance of calling a command at a wrong address and causing hardware damage. Except that it provides all information in a custom domain-specific language called ASL (?) with no guaranteed error-prone way of parsing it (??) other than praying that the iasl (Intel ASL compiler, part of the Linux kernel) correctly parses the tables (???) or simply giving up and using Windows with their Microsoft ASL compiler (?!!)

I get that the environment ACPI needs to operate in is complex, but I just need to simply get an address to send SMBus commands, and ACPI fails at the single task it needs to do??

OK, but what about the official specification? Perhaps there is a bug in the driver, and there is a reasonable explanation to all of this.. ACPI specs describing how to access the SMBus tells us that the SMBus controller built into the EC must be present as a ACPI0001 or ACPI0005 and should indeed have the _EC method, which provides the address offset and the query bit. The Steam Deck indeed has the ITE SuperIO controller with builtin SMBus functionality, but the ACPI device is not present. At the same time, a separate SMBus controller should be loaded under a custom HID with no way of providing essential info, and the specs tells that the OS should somehow handle this:

Regardless of the type of hardware, some OS software element (for example, the SMBus HC driver) must register with OSPM to support all SMBus operation regions defined for the segment. This software allows the generic SMBus interface defined in this section to be used on a specific hardware implementation by translating between the conceptual (for example, SMBus address space) and physical (for example, process of writing/reading registers) models. Because of this linkage, SMBus operation regions must be defined immediately within the scope of the corresponding SMBus device.

What am I reading is the official specification, right? They acknowledge that knowing the address offset is essential, but do not provide any means to get the said address.. What the hell? What this means is that there is no way to get this info unless the OS magically has a driver for talking to the exact controller. Isn’t the only reason why ACPI exists is to prevent such dependence in the first place?

The responsibility for the definition of ACPI namespace objects, required by an SMBus 2.0-compatible host controller driver to enumerate non-bus-enumerable devices, is relegated to the Smart Battery System Implementers Forum.

Yeah, why not

The EC chips

It is worth mentioning that the most popular (takes >90% of the market) EC/SuperIO chip manufacturer ITE doesn’t provide any datasheets or info to like a half of their chips, and it was extremely hard to find any info on how does it operate. I randomly stumbled upon this datasheet for a particular chip on archive.org and System76 EC firmware, which helped a lot. The datasheet is the only source of info on how is the chip supposed to talk to the CPU, and the firmware does the actual work decoding the registers. It seems that ITE is only willing to provide this data to other companies, as some datasheets I was able to find on their website are marked as confidential.

Bill Gates

These issues have already been discussed since the 2000s, and ACPI was described by Linus as a “complete design disaster in every way”. Furthermore, ACPI seems to be deliberately designed to require OS-level drivers for basic functionality and have extremely vague “specifications”. As if a singular company could have exclusive access to the vital information…

And then I accidentally found this article on ACPI debugging, which references the memo written by Bill Gates in 1999:

One thing I find myself wondering about is whether we shouldn’t try and make the “ACPI” extensions somehow Windows-specific. If seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work. … Maybe we couid define the APIs so that they work well with NT and not the others even if they are open. Or maybe we could patent something relaled to this.

What. The. Heck.

This is insane.. Isn’t it like the textbook definition of lobbying? I wasn’t expecting to find a whole conspiracy while trying to fix my Deck, perhaps the memo is a hoax or something, but this all just lines up so naturally. If it really was his plan, then he succeeded.

What do we do now?

Of course I cannot advise anyone to do something crazy like decompiling NT kernel due to the potential lawsuits against the Linux Foundation or someone else. The best course of action would be to patch Linux ACPI drivers to improve the support, especially in cases where the specs do not provide any info. Personally, I will continue analyzing the issue with the SMBus protocol, developing the sbsutil project and hopefully making a patch to the sbshc driver. (Note that the repo is in early WIP, README is out-of-date)

This is not Valve’s mistake for not setting up the SMBus communications, but rather the issue of the ACPI itself. Still, that would be huge kudos for Valve if they patched this (your console is awesome btw)

Updates

Upd 1

Wow, this blew up! Thanks a lot for the nice comments, it was pleasing to see all this feedback

Trivia

• This leaked document is a part of Halloween documents.
• As a result of Iowa anti-monopaly class action lawsuit, MS settled the case for $180M, which is only 0.3% of their revenue in 2007. This lawsuit seems not to be directly linked to the Halloween documents AFAIK.
• In EU, reverse engineering is not illegal if done properly (see clean room approach).

Another engineer has encountered similar ACPI issues in the past, here’s the link to his detailed guide on fixing DSDT tables: antenore blogpost

The user u/BitOBear posted a detailed story of Microsoft inner management practices of that time. Bizarre stuff

Overall, I’m going to report the bug to Valve soon! Stay tuned

WIP!!!

Due to my new research project, I had to upgrade my rig for the first time - it was built back in 2020 and needed some enchancements. Firstly, I’ve replaced a dying SSD, then swapped Ryzen 5 3600 with a beefier Ryzen 7 5700x. The old cooler couldn’t effectively cool down the new CPU in precision boost mode, so I also had to swap out both the cooler and pc case. Finally, I’ve mixed 2 new 16 GB HyperX Fury ram sticks with the old 2x8 HyperX Predator ones. Luckily, the sticks booted up just fine (I even managed to overclock them to 3200 GHz 15-17-17), but there was a weird issue: blue channel on the old sticks was dim. This didn’t only happen in OpenRGB, but also in stock rainbow mode

The problem

Since the sticks show this dimming issue in all modes, that’s the incompatibility issue between old and new HyperX RGB controllers. To understand how this works, we need to understand how does the software communicate to the ram sticks.

Another interesting problem is that ram sticks use optical sensors for syncing the clock between each other, and it seems that the position of these sensors is different on the newer ones. Due to this effect the color cycle effect desyncs after some time

Controlling DRAM RGB

HyperX ram is controlled on address 0x27 using global commands that control all of the rgb sticks. This means that the sticks should have some communication protocol.

Each ram stick has SPD controller, which has 3 additional pins SA0-SA2 in order to determine the slot. Only one common pin (ACT_n, VDDSPD) is directly connected to the bus, so in order to select each particular chip, Device Type Identifier Code prefix should be appended to the i2c command. It means that we can directly access each SPD controller on address range 0x30 - 0x37

Let’s analyze available addresses using i2cdetect <device-number> (you can get device list using i2cdetect -l):

I will probe file /dev/i2c-9.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         08 -- -- -- 0c -- -- -- 
10: -- -- -- -- -- 15 -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- 27 -- -- -- -- -- -- -- -- 
30: 30 31 -- -- 34 35 -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4f 
50: 50 51 52 53 -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- 

As we see, 0x27 address is used for HyperX RGB API, but here we found an another address range 0x30 - 0x31 and 0x34 - 0x35, which theoretically can be used for read operations. Write operations are likely disabled.

Right here we are going to apply color correction to mitigate the dimming effect

I2C Commands

Most of the job has been done by OpenRGB developers: they managed to reverse-engineer HyperX protocol. The list of commands can be found here: OpenRGB Documentation

All messages are sent using the format Packet start -> List of commands -> Packet end -> Apply

Firstly, we need to set the mode (it’s global for all sticks):

i2cset -y $I2C_DEV $ADDR 0xe1 0x01 # Start of message
i2cset -y $I2C_DEV $ADDR 0xe5 0x21 # Mode Control 3, selected mode : Direct
i2cset -y $I2C_DEV $ADDR 0xe1 0x02 # End of message
i2cset -y $I2C_DEV $ADDR 0xe1 0x03 # Apply

We have selected Direct per-led mode, so we can set each led individually. Here comes the hard part: we need to convert each slot and led position to i2c write command with “address”. It’s not a physical i2c address, but rather an internal mapping in HyperX protocol.

get_rgb_index() {
        # Get hex address of each led from zone 0..3, led 0..4 and channel 0..2
        IND="0x$(printf '%X' $((0x11+$1*0x30+$2*3+$3)))"
}

get_bri_index() {
        # Get hex address of brightness for led from zone 0..3 and led 0..4
        IND="0x$(printf '%X' $((0x21+0x30*$1+$2*3)))"
}

Luckily, the formula is pretty simple: if we iterate over 0x11 - 0x1f range, we will get all channels for the first slot in repeating R-G-B R-G-B R-G-B pattern. Brightness is set in the next 5 commands for each led. Beginning of each zone is spaced each 0x30 commands. The protocol supports up to 4 slots

Color correction

We need to apply two color corrections: for the blue channel and for red and green channels separately. We can match the brightness of blue channel between the zones and then correct the brightness of other channels - essentially, we are going to adjust the white balance.

Correction for the blue channel can be done simply by multiplying it by some constant.

R,G channels correction is trickier: we need to map them from 0-0xff to 0-dim_coeff*blue_ratio, where blue_ratio is the inversed brightness of blue channel after correction. Using this formula, we can set all zones to full brightness if blue channel is set to 0 and limit them to the brightness of the blue channel if it’s equal to 0xff.

color_corr() {
        # Color correction for R and G channels, arguments: color, blue_corr
        CORR_INT=$(( ((0x3F - $2 + $COLOR_CORR_MAX) * $1) / 0xFF ))
        # (b_min*(c_max-c)+b_max(c-c_min))/(c_max-c_min)
        if [[ $CORR_INT -lt 0 ]]; then COL="0x00"
        else
                if [[ $CORR_INT -gt 255 ]]; then COL="0xFF"
                else COL=0x"$(printf '%X' $CORR_INT)"
                fi
        fi
}

Theoretically, a simple lerp may not be the best solution for color correction, so this formula may need to be replaced with some smoothing function like a bezier curve.

Running the script

Before running the script, make sure that the i2c-tools package is installed and ee1004 module is unloaded.

Don’t forget to set I2C_DEV to the device address (may be found in OpenRGB device properties and using i2cdetect -l)

Simply clone the repository and run hyperx_ram_rgb.sh script

The first parameter is the hex code of the color (#ffffff), and the second one is the brightness (you may set it to 0xff)

So.. it seems that we have a win! Although we get a significant decrease in brightness on max blue channel, the colors are pretty accurate.. But something is telling me that the bash script is not good enough, we need a better tool…

OpenRGB Plugin

WIP!

Links

HyperX i2c commands (OpenRGB): OpenRGB Documentation

SPD Wikipedia article: https://en.wikipedia.org/wiki/Serial_presence_detect

DDR4 SDRAM Datasheet: https://docs.rs-online.com/6ecf/0900766b81641250.pdf

Kirikiroid2 is an awesome opensource Kirikiri engine emulator for android, but there is a problem: the provided apk on Github is different from the one that could be built from source. While the source code is perfectly fine, the apk contains Android.Waps adware. The problem is that recompiling the source is problematic due to the lack of certain source files and dependency issues. Kirikiroid2Yuri project attempts to solve this issue, but the rebuilt apk is still in beta. The author also published a tweaked version of the original apk, which will also be patched.

You may find APK files at Github

Note: the apk has also been patched to run on Android 14!

Overview

There are 2 available files: original Kirikiroid2_1.3.9.apk and patched Kirikiroid2_yuri_1.3.9.apk. We will be covering only the first one, because the differences are minimal.

In order to decompile the apk, we are using Apktool. This utility unpacks the .apk file and converts the .dex/.odex files into readable smali code. .dex file is the bytecode for the Dalvik/ART virtual machine that is used in Android. Google doesn’t use original Java virtual machine due to cpu and memory limitations on mobile, which is quite reasonable. You can think of .dex code as some kind of assembler that is executed on a interpreter rather than hardware. Reading opcodes is not practical, so why we need to convert them to some human readable format: smali. It’s similar to disassembling binary files into readable assembler.

Note that I’m not an Android/Java developer and have no prior experience in modifying apk files. It’s better to read intro to Smali first, scroll down to find more links on app decompilation.

Tools

• Java Development Kit (JDK)
• Apktool
• Some text editor or IDE (I’m using Intellij IDEA with smali plugin)
• (Optional) Android sdk for apk optimization

Decompilation

Note: replace the apk name with either Kirikiroid2_yuri_1.3.9.apk if needed.

In order to decompile the apk, we need to run apktool:

java -jar apktool_2.9.3.jar d Kirikiroid2_1.3.9.apk -o kiri2_src/

cd kiri2_src

AndroidManifest.xml assets              original            smali
apktool.yml         lib                 res

Now we have the project ready. The project structure consists of manifest file (main apk options), assets and resources (assets, lib, res, original), apktool config (no need to modify) and smali files. Java class hierarchy is preserved, such that class a.b.c is stored in smali/a/b/c.smali.

Project structure

smali
├── a
│   └── un.smali
├── android     # Android comon libraries
│   ├── net
│   └── support
├── b
│   └── a
├── cn
│   └── waps    # Adware that we need to purge
├── com         # Some libraries
│   ├── android
│   ├── enhance
│   └── loopj
└── org         # 3 libraries and kirikiri2 sources
    ├── apache
    ├── cocos2dx
    ├── libsdl
    └── tvp     # Main source code

From here we can see that the main task is to remove all usages of cn.waps.* from org.tvp.* classes and just remove the cn folder altogether. Theoretically, we could take another approach and modify cn.waps functions to the point where it’s harmless, but that would be quite hard.

Let’s take a look at org/tvp/ sources:

smali/org/tvp
├── kirikiri2
│   ├── DummyEdit.smali
│   ├── KR2Activity$1.smali
│   ├── KR2Activity$2.smali
│   ├── KR2Activity$3.smali
│   ├── KR2Activity$4.smali
│   ├── KR2Activity$5.smali
│   ├── KR2Activity$6.smali
│   ├── KR2Activity$7.smali
│   ├── KR2Activity$DialogMessage$1.smali
│   ├── KR2Activity$DialogMessage$2.smali
│   ├── KR2Activity$DialogMessage$3.smali
│   ├── KR2Activity$DialogMessage$4.smali
│   ├── KR2Activity$DialogMessage.smali
│   ├── KR2Activity$KR2GLSurfaceView.smali
│   ├── KR2Activity$ShowTextInputTask.smali
│   ├── KR2Activity.smali    # <-
│   ├── MediaStoreHack.smali
│   ├── MediaStoreUtil.smali
│   └── SDLInputConnection.smali
└── kirikiri2_free_10309
    ├── BuildConfig.smali
    ├── Kirikiroid2.smali    # <-
    ├── R$attr.smali
    ├── R$dimen.smali
    ├── R$drawable.smali
    ├── R$integer.smali
    ├── R$raw.smali
    ├── R$string.smali
    └── R.smali

Here the main source files are Kirikiroid2.smali and KR2Activity.smali. Actually, it would be interesting to analyze other files aswell, but the post would be way too long.

Analyzing Kirikiroid2 source code

By using Find in files -> waps I’ve checked that the adware is only called from Kirikiroid2.smali file.

The first function that uses cn.waps is handleMessage.

.method public handleMessage(Landroid/os/Message;)V
    .locals 6
    .param p1, "msg"    # Landroid/os/Message;

    .prologue
    const/4 v3, 0x1

    .line 91
    iget v4, p1, Landroid/os/Message;->what:I

    const v5, 0x10001

    if-ne v4, v5, :cond_2

    .line 92
    iget v3, p1, Landroid/os/Message;->arg1:I

    if-eqz v3, :cond_1

    .line 93    # <- 93
    invoke-static {p0}, Lcn/waps/AppConnect;->getInstance(Landroid/content/Context;)Lcn/waps/AppConnect;

    move-result-object v3

    # <- next line
    invoke-virtual {v3, p0}, Lcn/waps/AppConnect;->showPopAd(Landroid/content/Context;)V
    
    # ...

    goto :goto_0
.end method

If we check the beginning of the function, we can see that this method takes android/os/Message and returns V - void type. Let’s analyze line 93:

invoke-static {p0} means that we are calling a static method, while passing a register p0.

Lcn/waps/AppConnect; calls the AppConnect class and ->getInstance(Landroid/content/Context;)Lcn/waps/AppConnect mentions the exact method to call. So this line gets the instance of the adware class to work with.

The next line calls a virtual method showPopAd. It seems that this adware has builtin code to display ads, huh..

Since this function is not present in the original source code and is redefined in some other parts of the project, it’s likely that the author made it to be quickly addable and removable. In other words, we can simply remove this function and the app would compile.

Other functions .method public onCreate(Landroid/os/Bundle;)V, .method public onDestroy()V and .method showBannerAd(Z)V act the same and can be safely removed.

onDestroy is likely to be a destructor, we should double check it to avoid memory leaks:

.method public onDestroy()V
    .locals 1  # we use 1 local register

    .prologue  # for debug
    .line 80
    invoke-static {p0}, Lcn/waps/AppConnect;->getInstance(Landroid/content/Context;)Lcn/waps/AppConnect;

    move-result-object v0

    invoke-virtual {v0}, Lcn/waps/AppConnect;->close()V

    .line 81
    return-void
.end method

Here we use 1 local register v0 (the VM needs to know how many of them to reserve)

We pass first argument p0 to getInstance in order to get the current adware instance, then assign the result to v0 register and call close in order to stop the instance.

If we take a look at the published source file, we see that the method may look something like that:

@Override
public void onDestroy()
{
    AppConnect instance = getInstance(this);
    instance.close();
}

We may also remove this function, because no adware instance is being created.

At this point we may delete the cn directory, since there are no other mentions in the project.

Final modifications

I have found another concerning function that I would like to patch: KR2Activity.smali:1206

.method public static getDeviceId()Ljava/lang/String;
    .locals 5

    .prologue
    .line 272
    invoke-static {}, Lorg/tvp/kirikiri2/KR2Activity;->GetInstance()Lorg/tvp/kirikiri2/KR2Activity;

    move-result-object v3

    const-string v4, "phone"

    # ...

    goto :goto_0
.end method

This one obtains the device id, which is usually used for advertising purposes, it makes sense to return zeros. Here the functions returns java/lang/String, so we may just return “0000000000000000”.

We may just append

const-string v0, "0000000000000000"
return-object v0

after .line 272 directive and the function would return early.

Recompilation

Run cd .. to exit the kiri2_src directory and run

java -jar apktool_2.9.3.jar b kiri2_src

to rebuild the project. Next we would need to sign the apk with our own certificate:

Generate the signing key if needed (once):

keytool -genkey -v -keystore <filename>.keystore -keyalg RSA -keysize 2048 -validity 10000 -alias <alias>

Sign the apk:

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore <path-to-key> ./kiri2_src/dist/Kirikiroid2_1.3.9.apk <alias>

We may optionally call zipalign to optimize the apk file:

/path/to/android-sdk/bin/build-tools/*/zipalign -p -f -v 4 kiri2_src/dist/Kirikiroid2_1.3.9.apk kiri2_src/dist/Kirikiroid2_1.3.9_debloated.apk

Results

We have obtained the apk file that runs and is not flagged on virustotal, unlike the original ones. I’ve changed the application name in apktool.yml file in order to avoid the package name conflict. If the original apk crashes, please use yuri version with bugfixes.

APK and project files are available at Github

Unfortunately, analyzing the adware code is beyond the scope of this article, since it’s obfuscated, but I may try doing that later.

Links

Intro to smali: https://payatu.com/blog/an-introduction-to-smali/

Essential info on smali (multiple links in the top answer): Stackoverflow question

Smali cheatsheet, not quite readable: github gist

While playing around with Godot engine and shader programming I’ve developed some interestingly looking comic shader with ink-ish look. On this example I want to show you how to implement simple pop style dotted shaders.

It is recommended to read @dreadlocksdude’s shader tutorial first: VFX shader series, lesson 1

Overall, this is an extremely important guide on understanding shader functions as building blocks. We will be heavily using such techniques in this guide.

The idea

While watching the recent Posy video about dot matrix printing, I’ve decided to implement a shader that contained blending CMYK dots in the screen space, such that the image is perpendicular towards the camera (unlike the textures).

In order to avoid unwanted rippling effects during the movement I’ve decided not to overlap the coloured dots, but split them into zones:

So, we will pick the zones, determine the corresponding color, perform some preprocessing effects and render the dots.

As for the test mesh, I will be using the metaball spider model, as this shader looks best on organic surfaces.

Dots function

In order to create the shader, we need to develop the dots function first that returns the color based on position, zone color, background color and rotation of the field.

Firstly, we need to get the formula for the dot in order to determine if we need to return the background color or the color of the dot. This is a simple formula for the ellipse with the origin at \((x_0, y_0)\)

vec3 dots(vec2 pos, vec3 dotcol, vec3 black, float a)
{
    if (pow(pos.x - dot_size, 2) + pow(pos.y - dot_size, 2) <= dot_size*dot_size)
    {
        return dotcol;
    }
    return black;
}

This gives us the single dot at \((x_0, y_0)\), so we need to repeat the function along x and y axis to obtain the matrix of dots. The simpliest way to achieve this is by taking modulo from \(x\) and \(y\). mod(x, n) returns (0, 1, 2, ..., n-1, 0, 1, 2, ...): if we pass the result of this function in the ellipse formula, we obtain the repetition of this ellipse with spacing n anywhere along the space. In the context of shaders, mod function takes floating point numbers aswell.

vec3 dots(vec2 pos, vec3 dotcol, vec3 black, float a)
{
    if (pow(mod(pos.x, dot_spacing) - dot_size, 2) + pow(mod(pos.y, dot_spacing) - dot_size, 2) <= dot_size*dot_size)
    {
        return dotcol;
    }
    return black;
}

The last point is the rotation of the dots. We want to rotate the whole space over the point \((0, 0)\), so we need to apply the transformation matrix to the position vector \((x, y)^T\). Note that angle \(a\) must be in radians.

So we nonlinearly transform our position by some matrix and obtain new coordinates that we pass to our code as is.

vec3 dots(vec2 pos, vec3 dotcol, vec3 black, float a)
{
    pos = mat2(vec2(cos(a), sin(a)), vec2(-sin(a), cos(a))) * pos;
    
    if (pow(mod(pos.x, dot_spacing) - dot_size, 2) + pow(mod(pos.y, dot_spacing) - dot_size, 2) <= dot_size*dot_size)
    {
        return dotcol;
    }
    return black;
}

Fragment shader

Firstly, we need to define some uniform variables that can be tuned for each model.

shader_type spatial;

render_mode unshaded;

uniform float power = 3;  // thickness of edge

uniform float dot_spacing = 10;
uniform float dot_size = 2;
uniform float angle = 45;
// ...

It is important to define render_mode unshaded in order to override the color by disabling engine lighting and shading.

// ...
void fragment()
{
    // ...
    ALBEDO = col;
}

So, we need to write fragment function that takes various parameters (vertex position, face normal, …) and sets the albedo (color) of the current fragment (sub-pixel).

Writing a simple shader

After some theory we are finally going to write a simple dot shader. Our fragment function needs to find the edges of the model in order to paint the front facing parts of the model black. We may calculate the cosine of the angle between the camera and normal vector. In other words, we need the dot product between these vectors.

float dist = pow(1.0 - dot(NORMAL, VIEW), power);
// ...

We need to subtract the cosine from 1 in order to get the distance to the edge. We don’t care about vector lengths as in dot product formula \(a \cdot b = \text{len } a \text{ len } b \cos{\theta}\), because NORMAL and VIEW vectors are normalized: their length is 1. Power of value sets the thickness of the edge.

Now, we need to get the color of the dots. I’ve decided to use the position of the fragment from camera to split the model into several zones. As a result, we can determine the CMYK color of each zone.

In order to add some variation, we subtract it from the normal. There are better ways to do this, but the current code works fine.

// ...
col = vec3(0.0, 0.0, 0.0);  // set the color to black

if (dist > 0.01)  // check for the edge
{
    col = vec3(0.0, 1.0, 1.0);  // set the color to cyan
    if (NORMAL.x - VIEW.x > 0.0) col = vec3(1.0, 1.0, 0.0);  // yellow
    if (NORMAL.y - VIEW.y < 0.0) col = vec3(1.0, 0.0, 1.0);  // magn
    
    col = dots(SCREEN_UV * VIEWPORT_SIZE, col, vec3(0.0, 0.0, 0.0), 0.0);  // right now we don't set the rotation
}

ALBEDO = col;

SCREEN_UV * VIEWPORT_SIZE returns the position multiplied by the screen size with the respect to the aspect ratio. Perhaps it may be needed to normalize this vector in order to get consistent dot sizes on any screen.

At this step we can see that the model needs some border. We will color it with the corresponding CMYK value. We do it by simply adding another distance check.

// ...
if (dist > 0.01)
{
    col = vec3(0.0, 1.0, 1.0);
    if (NORMAL.x - VIEW.x > 0.0) col = vec3(1.0, 1.0, 0.0);
    if (NORMAL.y - VIEW.y < 0.0) col = vec3(1.0, 0.0, 1.0);
}
if (dist > 0.01 && dist < 0.1)
{
    col = dots(SCREEN_UV * VIEWPORT_SIZE, col, vec3(0.0, 0.0, 0.0), 0.0);
}
// ...

This is much better! Now the model stands out from the rest of the scene. Now we should add the distance check and disable the dots when we are too far away to prevent movement sickness.

// in the uniforms declaration
uniform float dots_hiding_threshold = 0.005;

// ...

void fragment()
{
    vec3 col = vec3(0.0, 0.0, 0.0);
    float dist = pow(1.0 - dot(NORMAL, VIEW), power);
    float cam_dist = pow(length(VERTEX - VIEW), 2) * dots_hiding_threshold;

    if (dist > 0.01)
    {
        col = vec3(0.0, 1.0, 1.0);
        if (NORMAL.x - VIEW.x > 0.0) col = vec3(1.0, 1.0, 0.0);
        if (NORMAL.y - VIEW.y < 0.0) col = vec3(1.0, 0.0, 1.0);
    }
    if (dist > 0.01 && dist < 0.1 - cam_dist)  // we do not draw dots if we are too far away
    {
        col = dots(SCREEN_UV * VIEWPORT_SIZE, col, vec3(0.0, 0.0, 0.0), 0.0);
    }
    ALBEDO = col;
}

We are too far away and cannot see the dots. The last thing that we would need to implement is the rotation and movement of the dots. We would need some kind of hash function to add random movement. Such function is sine/cosine: if we pass TIME variable, we will get wave-like change of the parameter over time. If we sum two of these functions with different parameters, we would get pseudo random oscillation that repeats over some time. Such functions \(a_1 \sin{(t + b_1)} + ... + a_n \sin{(t + b_n)}\) are called wave functions and are actually used in water shaders. Acerola has a nice video on this topic

I didn’t declare these constants to the uniform variables to avoid the cluttering of the settings window. Feel free to play around with those.

// ...
if (dist > 0.01)
{
    col = vec3(0.0, 1.0, 1.0);
    if (NORMAL.x - VIEW.x*cos(TIME+b_1)*a_1+c_1 > 0.0) col = vec3(1.0, 1.0, 0.0);
    if (NORMAL.y - VIEW.y < 0.05 + sin(TIME+b_2)*a_2+cos(TIME+b_3)*a_3) col = vec3(1.0, 0.0, 1.0);
}
if (dist > 0.01 && dist < 0.1 - cam_dist)
{
    col = dots(SCREEN_UV * VIEWPORT_SIZE, col, vec3(0.0, 0.0, 0.0), a_x*col.x*sin(TIME)/a_s + a_y*col.y + a_z*col.z);
}
// ...

In order to get random rotation for each color, we perform some ‘hash’ formula on the color r, g, b values.

Repository

The code and models are available on Github: https://github.com/enaix/godot-cmyk-dot-shader

Final code version

shader_type spatial;

render_mode unshaded;

uniform float power = 3;

uniform float dot_spacing = 10;
uniform float dot_size = 2;
uniform float dots_hiding_threshold = 0.003;

const float a_1 = 2.0;
const float a_2 = 0.1;
const float a_3 = 0.12;

const float b_1 = 0.0;
const float b_2 = 0.0;
const float b_3 = 2.0;

const float c_1 = -0.3;

const float a_x = 14.3;
const float a_y = 13.2;
const float a_z = 43.3;
const float a_s = 10000.0;

vec3 dots(vec2 pos, vec3 dotcol, vec3 black, float a)
{
    pos = mat2(vec2(cos(a), sin(a)), vec2(-sin(a), cos(a))) * pos;
    if (pow(mod(pos.x, dot_spacing) - dot_size, 2) + pow(mod(pos.y, dot_spacing) - dot_size, 2) <= dot_size*dot_size)
    {
        return dotcol;
    }
    return black;
}

void fragment()
{
    vec3 col = vec3(0.0, 0.0, 0.0);
    float dist = pow(1.0 - dot(NORMAL, VIEW), power);
    float cam_dist = pow(length(VERTEX - VIEW), 2)*dots_hiding_threshold;

    if (dist > 0.01)
    {
        col = vec3(0.0, 1.0, 1.0);
        if (NORMAL.x - VIEW.x*cos(TIME+b_1)*a_1+c_1 > 0.0) col = vec3(1.0, 1.0, 0.0);
        if (NORMAL.y - VIEW.y < 0.05 + sin(TIME+b_2)*a_2+cos(TIME+b_3)*a_3) col = vec3(1.0, 0.0, 1.0);
    }
    if (dist > 0.01 && dist < 0.1 - cam_dist)
    {
        col = dots(SCREEN_UV * VIEWPORT_SIZE, col, vec3(0.0, 0.0, 0.0), a_x*col.x*sin(TIME)/a_s + a_y*col.y + a_z*col.z);
    }
    ALBEDO = col;
}

How this works

Network

As you see, the remote client connects to the wireguard server hosted on the Raspberry PI. It is possible to host it on the main rig, but it would be impossible to send the magic packet in case if the rig is turned off.

It is recommended to buy a static IP from the provider for better user experience (and I’m sure that you don’t want to randomly lose access due to the router rebooting and changing dynamic ip address). If it is not an option and your router is accessible from outside (there is no double NAT), you may use a telegram bot or a dynDNS service to get the ip.

If you are under double nat, then there is not much of a choice: forwarding services like Ngrok or localhost.run provide miserable speed. Selfhosted vps with an ssh tunnel may get you somewhere, but it still heavily limits your connection speed. From my experience, paying for a static ip is the best choice.

Streaming

Steam Remote Play is by far the best option in terms of speed and quality. Any remote desktop solutions like VNC or nomachine have different video encoding algorithms and have miserable framerate. If you are using Windows, you may give Moonlight a try. Also, Steam has magnificant input system that supports any input. I was surprised that it even supports Samsung physical keyboards on Android!

Installation

I won’t cover wireguard installation process, since there are dozens of guides online (one two). I also recommend to setup an SSH server and VNC/Nomachine on your home PC to be able to launch Steam if the system reboots. You also need to enable Remote Play in Steam settings and install Steam Link client on your laptop/tablet.

Does it work, right?

Right after buying static ip from my provider and setting up the vpn, I finally see the remote screen and… it crashes after a minute. Furthermore, Steam client on the rig crashes alongside with Steam Link, which is extremely weird. It allows me to play any game, but it always dies after a minute or two.

On the next day I noticed that my home router is inaccessible. The router started to randomly drop the link (requiring a reboot each time), the problem was that it could not handle the load. So yeah, an old router may have problems with a static ip.

As for the Steam client, the root of the problem was in the commit in Xorg that ended up breaking some obscure software including Remote Play. It was considered to be non-critical, so why it took so long for the dev team to revert the commit.

Fast-forward in 2 months: it was either the Xorg team or a recent Remote Play update that fixed the issue!

Test results

720p, reasonable FPS (I get around 40-60 I guess) on 10 mbps home link (gigabit ethernet at home) + 100 mbps local wifi with not-so-bad delay. Not gonna lie, you would have troubles playing competitive shooters, but it is enough to play almost any game you wish.

If you add a non-steam game (for example a Lutris launcher), you can also run pretty much any program you wish.

Overall, I recommend this solution for those who don’t wish to pay for cloud gaming solutions or want to stream games with minimal latency.