“It’s a map app… why did my travel route leak?”
Theft of Location and Account Information through App Tampering (Attacks via Repackaging, Fake Maps, and Mobility Apps)
One day, a user had a strange experience. They had simply checked their commute route using a navigation app and hailed a taxi using a mobility app… but from then on,
• They received messages suggesting their travel route had been exposed
• Unused payment transactions occurred
• Notifications to change their account password arrived one after another.
On the surface, the screen was completely identical to famous map apps, taxi hailing apps, and navigation apps.
The icons, the UI, and the user flow were all the same.
The problem was that the app itself—not the server or the user—was fake.
Problems encountered in actual cases
“The attacker deceived the screen, and the user did not suspect anything”
This attack is a typical repackaging-based attack.
The attacker downloads a legitimate map or mobility app and performs the following actions:
1. Insertion of malicious code into the app
2. Addition of information theft logic when logging in, making payments, or entering transaction history
3. Maintaining the same UI as the legitimate app
4. Distribution of the fake app via external channels
Users could not distinguish it from the official app and naturally entered their login information and transaction history.
At that moment,
• Account ID and password
• Location information and movement paths
• Payment method information
All were transmitted to the attacker in real time.
Where exactly did the security issue lie?
The core security issue in this case is clear.
It is that the "modified app ran like a legitimate app."
• Executable despite the app signature being changed
• Undetected despite code modification
• Operated without warning to the user
In other words, the entire security incident began without verifying whether the app was "real or fake."
This type of attack cannot be prevented by server security or network encryption alone.
How did LIAPP defend against this problem?
LIAPP verifies the integrity of the app itself at the time of execution.
1) App Integrity Verification
Verifies that the app code, signature, and package structure remain identical to their state at the time of distribution.
If even the slightest tampering is detected, it is immediately classified as a dangerous app.
2) Repackaging Detection
Accurately distinguishes fake, cloned, or modified apps based on legitimate apps.
Even if an attacker maintains the UI exactly as it is, changes to the internal structure cannot be hidden.
3) Blocking Modified App Execution
If tampering is confirmed, the app execution itself is blocked at the stage prior to the login screen.
Consequently, fake map and mobility apps cannot even be used.
How were the issues resolved after implementation?
The changes following the implementation of LIAPP were clear.
1. Immediate blocking of repackaged app execution
2. Complete blocking of login and payment attempts via fake apps
3. Cessation of movement history and location data leakage incidents
4. Restoration of user trust
Attackers are no longer able to utilize "fake apps that look like legitimate apps."
Lessons from This Case
The starting point for map and mobility app security is not ‘server protection,’ but ‘verifying whether the app is genuine.’
• Just because the screen looks the same does not mean it is safe.
• You cannot trust that the functionality is normal.
• You must first verify if the app has been tampered with.
LIAPP does not analyze attacks retrospectively. It does not allow the moment a fake app is executed.
The first step in mobility security is not protecting functionality, but verifying integrity.
#LIAPP #LISS #LIKEY #AppTampering #RepackagingAttack #FakeApp #MapAppSecurity #MobilitySecurity #LocationDataLeak #MovementHistorySecurity #AccountHijacking #PaymentInformationSecurity #MobileSecurity #AppIntegrity #SecurityCase #AppSecurity
