We performed a controlled lab test on several messaging apps. Observations are based solely on network traffic; no payload decryption or app reverse engineering was done.

1. DNS behavior

Some apps (e.g., Bale) requested DNS from multiple sources outside the device’s configured servers.

At least three DNS servers were contacted, all located outside the country.

2. Tunnel-flag behavior

When the tunnel flag was toggled on and off (no real network change), some apps behaved unusually.

Eita repeatedly closed otherwise successful server connections when the tunnel was on.

This behavior did not occur when the tunnel was off.

3. DNS resolution inconsistencies

Eita sometimes resolved a domain to an IP (e.g., a.b.c.d) but connected to a different IP (e.g., a.b.c.e), ignoring the resolved IP for extended periods.

4. Reconnection and traffic patterns

Eita repeatedly re-established connections after closing them.

We saw forground netowork activity in app that first thought is for notifications.
We tested with a chat message showed the app did not load the message or notifications.
but meanwhile
Upload traffic volume was much higher than download, which is not typical for getting notification request

5. Comparison with other apps

Rubika: similar to Eita, opening multiple connections to different servers, sending data, and closing connections frequently.

Bale: maintained a single, persistent TCP connection to its server, behaving normally.

These apps exhibit unusual and potentially suspicious network behavior.

Some easy to undrestand info are in the zip below: