SS8 Interceptor
Earlier I wrote about the Mobile Secrets java app and how its Secrets were easily revealed via bytecode disassembly. Well I recently got wind of an even bigger java app sexpose, the SS8 Blackberry trojan that the UAE deployed last year and caused a big hoohaa cuz it got sexposed!
I managed to get the java pack only last week so still running thru the code but it old news to others already. The tech websites already talked about it, seems is demo/early version with alot of loophole or features missing. You can read this PDF for a overview.
The key points I extract out for your easy reading! Very interesting and sad… battery drain LOL! I wonder the mobile data bill got can refund anot…
OBSERVATIONS
There are several anomalies in the application that lead to the conclusion that it was either not the version intended for deployment; it was mistakenly rolled out or it was an early release that was being tested.
The reasons for such a conclusion can be argued as:
(1) No capability for intercepting incoming messages.
(2) No possibility of silently updating the application with newer releases.
(3) Lack of comprehensive interception capabilities. Only outgoing email messages.
(4) Several segments of unused source code and references that have been hardcoded into the application. Further observations have been listed below.Disabled Email Control Channel
The email based control channel to send commands to the application is disabled. On further analysis, why it was disabled became clear. When the service-provider sends an email message to activate the application, a copy of this control email would also be delivered to the recipient’s email server. Thus the user would be alerted to possible suspicious activity.Control Channel Messages
Control channel commands are momentarily visible when they are received. Thus a user who happens to be looking at his handheld screen would see a message appear for a fraction of a second and then instantly disappear. This behavior was observed on a BlackBerry handheld but was not apparent on the BlackBerry handheld simulator.Hardcoded References
A standard program that is redistributed will usually have some sort of constants or configuration file. The Interceptor application did contain such a file, however the configuration parameters from the file were not used in the execution of the program. Instead, there were hardcoded references that were used. This is what lead to the conclusion that this version of the application was either a early testing version that was mistakenly deployed or it was a badly modified version of an original file.Battery Drain
The application implements a watcher on all the handheld message folders. This watcher triggers other components whenever a message is received. Despite this, the application polls a function to check if a new message has been received. This constant polling uses processing cycles and thus increases
power consumption. It is very likely that less powerful processors may overheat due to the increased processing activity. This is bad programming practice, especially for handheld devices. It was also the reason users were made suspicious of the program.Heartbeat
Every hour, each handheld will report its status and version information to the central server. This happens regardless of application is installed on the handheld and is named whether the application is intercepting messages or not.Encryption
The Interceptor application makes use of encryption when sending intercepted messages or receiving control commands. It does this by encrypting outgoing messages using AES. The keys are hardcoded into the application. For incoming control commands, the messages are decrypted using the device PIN as the decryption key. The encryption type is still AES.
