Your SlideShare is downloading. ×
Hacking JME platform by example / 0wned by MoMo
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Hacking JME platform by example / 0wned by MoMo


Published on

Presentation held by me on Mobile Monday Tartu event on 07. September 2009. …

Presentation held by me on Mobile Monday Tartu event on 07. September 2009.

Published in: Technology, Business

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Hacking JME platform by example 0wned by MoMo Sven Kirsimäe [email_address]
  • 2. [why hack a phone]
    • “ You can tell what a culture values by what it has in its bags and pockets” John Agar, “Constant Touch: A Global History of the Mobile Phone”
    • billions of mobile phone users
    • sometimes the only way of personal private communication
    • mobile internet communication is rising
    • becoming a tool for payments
    • many old “broken” devices still around
  • 3. [publicly known issues]
    • april, 2004 “Siemens S55 SMS Send Prompt Bypass Weakness”
      • Overlay the prompt with more “user friendly message”
    • 2004, Adam Gowdiak, Poland “Insufficient validation of bytecodes in the bytecode verifier component”
      • confirms on his Nokia 6310i
      • took him 4 months
      • no details revealed
    • 2008, he claims 0wning all Nokia S40 devices
      • able to take full control of the device: phone calls, networking, recording audio and video, accessing address book and file system, etc.
      • 6 months of research
      • no details revealed - 20,000EUR for the full report and source
  • 4. [patching the issues]
    • update the JVM = update the firmware
    • update hundreds of thousands of devices
    • “ Over the wire firmware update” come again?
    • renewing mobile hardware is more feasible for a general case
      • every year or two
      • is the new phone patched?
  • 5. [MIDlet JVM security constraints]
    • low-level VM security
      • rejecting ill-formed or maliciously-encoded application
      • two-phase verification: off- & on-device class file verification
      • missing custom class loaders
    • application-level security
      • user prompts, application signing
      • access only allowed libraries and system resources
        • file system, printers, infrared devices, native libraries, the network
      • no native functions or direct access to the existing ones
      • no reflection , no finalization
      • no overriding or extending the set of system or manufacturer specific classes found in
        • java.* ; javax.microedition.* ; com.sun.** ;*
  • 6. [hints on breaking JVM constraints]
    • read the source
      • phoneME – reference implementation of the MIDlet JVM + JSRs
      • manufacturer APIs – decompile and read
      • emulators/SDKs provide list of manufacturer classes
    • try to break the specification constraints
      • buffer overflows on internal data structures
      • bytecode manipulations on off-device verified code
      • cheating the on-device verifier
      • typing on behalf of the user
      • hiding the prompts – threading?
      • search for hidden system classes
      • accessing the system classes
      • call the native methods from the application
    • don’t emulate!
    • takes time to have something
    • non of the “heavy breaking” is required for our today’s demo
  • 7. [SMS without permission]
    • some Samsung devices discard the official specification requirements for the security
    • application is able to gain access to the manufacturer specific “protected” classes
    • access enables to change the internal logic of the “protected” classes
    • a vulnerability enables to send SMS from the MIDlet application without the user’s confirmation
    • affects:
      • targeted audience – the SMS-generation
      • premium SMS
      • malicious applications can be envisioned by anyone…
  • 8. [affected devices]
    • ~ 5- 10% ( GetJar/ AdMob, Feb. 2009), ~130 devices (J2ME Polish) , 3rd after Nokia and Sony-Ericsson.
    • Confirmed on Samsungs
      • D500 (Q4, 2004)
      • Z500 (Q1, 2005)
      • D600 (Q1, 2005)
      • E500 (Q2, 2006)
      • E250 (Q4, 2006)
      • D900i (Q1, 2007)
    • Potentially affected: E730, E760, T509, X700, T809, E340, E360, E370, Z140, Z150, Z230, Z300.
    • All devices are: CLDC 1.1, MIDP 2.0 and JSR 120 (Wireless Messaging API).
  • 9. [why i did it]
    • was just reading around the JME implementation source
    • geekiness kicked in
      • 2 weeks of not sleeping
    • no HTTP in the similar way
      • but what about SMS-in?
    • Samsung has been notified in 02.2007
      • brief response acknowledging the issue
      • release of confirmed D900i
  • 10. [are they critical]
    • needs human factor for the malicious program to reach and run on the device
    • fragmentation of the devices = potential flaw cannot reach many devices
    • phones are getting more open (smartphones)
    • rare exploitations can be quite costly for the end-user
    • T he most effective phone hacking can still be
    • “ stealing the phone” ;)