WIM for iPhone
A native iPhone client built by reverse engineering a mobile carrier’s app and protocol.
Somos WIM is a mobile carrier whose app handles data balances, packages, and account details. I built a personal iPhone prototype that brings those screens into a native English interface.
I captured the original iPhone app’s traffic through a man-in-the-middle proxy, terminating SSL/TLS to inspect its payloads, and analysed the Android client to understand the matching protocol. The app uses WebAxn: the server sends encrypted screen definitions and actions rather than a conventional account API. I reconstructed that exchange in Swift and translated the supported screens into native views.
Sign-in, usage, package browsing, help, profile, and saved-card reads were checked against the live service. The prototype supports the WebAxn screens observed during that work; it is not a complete implementation of the platform. Registration and recovery remain partial, and purchase completion is unverified.
Highlights
- Android analysis and MITM traffic capture
- WebAxn protocol support built in Swift
- Server-defined screens adapted to native views
- Live usage and package browsing
What I built
Capture and understand the original app
Used Android client analysis and a proxy that terminates SSL/TLS to inspect the app’s network payloads and identify the WebAxn protocol.
Rebuild the protocol in Swift
Decoded WebAxn’s encrypted, compact XML screen format and tracked the changing session state needed to request the next screen.
A useful account home
See live data usage, included services, a searchable package catalogue, help, profile, and masked saved-card details in native iPhone views.
Respond to changing server screens
Navigation follows actions from the current server response. The client validates supported screens and refreshes checkout quotes; completed purchases remain unverified.
The traffic capture was only the beginning
The goal was to bring the carrier’s account information into a native English iPhone interface. The investigation began by putting the original app’s traffic through a temporary man-in-the-middle proxy. The proxy terminated SSL/TLS, the encryption protecting the network connection, to expose requests and responses. Their bodies had another encryption layer. Seeing the network traffic did not yet mean being able to read it.
Examining the Android client's code explained how that encrypted exchange worked. I reconstructed its encrypted message format, checksums, and changing session keys, then used a small test client to test the request sequence. The Swift client uses changing values from the current exchange for each request.
An app whose screens arrive from the server
WIM uses WebAxn, a platform where the server sends screen definitions and actions to a generic mobile engine. The payload describes controls, text, navigation, and form submissions in WBXML, a compact binary form of XML. It is much closer to receiving instructions for an interface than asking a conventional account API for a balance.
That made the screen definitions the main source of evidence. The Android package helped explain how to decode them, but the account-specific choices came from the current responses. Each navigation step also changed the state needed for the next request.
Translate the useful parts into native views
I chose to extract understood account data into native iPhone views rather than rebuild the entire WebAxn widget engine. Home presents usage and included services; Packages groups the available offers; Help browses official support articles; Account presents profile and masked saved-card details. Those core reading paths were exercised against the live service through the native Swift client.
The difficult part is preserving meaning while improving presentation. Checkout review keeps the carrier’s offer wording and validity alongside the current price and payment choices. Navigation uses actions from the latest screen, and the client checks the screen it received before treating its contents as the expected data.
Know where the reconstruction ends
A server-defined interface can change without a new app release. This client therefore supports the screens observed during the investigation, with explicit checks for the definitions it understands. Unknown payment fields or a changed quote stop checkout rather than guessing how to submit it.
The result is a working personal prototype with verified account information. Completing purchases, registration and recovery still needs validation, as does some device-specific session behaviour. The interesting engineering work is the bridge: taking an undocumented, encrypted interface protocol and making its understood parts useful in an ordinary native app.