Sponsored Links

Sponsored Links

Page 1 of 4 123 ... LastLast
Results 1 to 10 of 40



  1. #1
    Registered User RexVF5's Avatar
    Join Date
    Dec 2007
    Posts
    185
    Sponsored Links

    Possible attack vector through BD-J

    Sponsored Links
    Through the weekend after long-long Friday night having too much wine a memory came to my mind: "a signed Java applet can gain access to local (i.e. where browser runs) resources like filesystem, sockets, etc..." So maybe if I could point internal PS3 browser to a page containing signed Java applet and it would act as normal browsers, I should be asked to allow it access to local resources and I would be inside! I tested it today and found out it didn't work - simply because the internal browser doesn't support Java applet at all.

    Then a improved version of the original idea came to me. BluRay standard mandates support for BD-J which is a special version of J2ME. For some info on this see [Register or Login to view links] There is this interesting info:
    Security in BDJ is based on the Java platform security model. That is, signed applications in JARS get to do more stuff, such as Read/Write access to local storage, network access, selection of other titles on the BD-ROM disc, and control of other running BD-J applications.
    and also this one:
    Authenticated applications can use a (signed) permission request file to acquire permissions that go beyond the BD-J sandbox. Permissions can be acquired for:

    * Reading and writing to local and system storage
    * Using the network connection (to connect to defined servers)
    * Access of the file system on the BD-ROM disc
    * Title selection of other titles on the BD-ROM disc
    * Control of other running BD-J applications
    It also notes that
    * BD-J will include support for storage. Two flavors of storage are included mandatory System Storage and optional Local Storage. All storage is accessed using methods from the Java IO package. The path for local storage is as specified by [GEM].

    * System storage is storage that will be present in all BD-J players. The required minimum size of this system storage will permit storage of application data like settings, high-scores etc. It will not be big enough to store downloaded AV material. For this purpose, optional local storage is available. Typically system storage will be implemented using Flash memory and the optional local storage will be implemented on a HDD.
    which would mean it cannot access whole disk. However having access to at least part of it would be interesting as well. You could compare what you have written with encrypted part and maybe this would help breaking in. Or maybe there would be some bug in the implementation which would allow access to other parts of the filesystem (in unencrypted way) as well.

    I am skilled with Java and it would be no problem to test this for me. Unfortunately I lack the required equipment - BluRay writer. Is there anybody skilled enough in Java and having BluRay writer and media to spare for this?

  2. #2
    Registered User parkerparker's Avatar
    Join Date
    Feb 2008
    Posts
    70
    Sponsored Links
    Sponsored Links
    great idea, still trying to save for bluray writer!!

    sounds promising, maybe one of the devs have an idea about this?!?! but anyway great thinking...

  3. #3
    Banned User CoreTX's Avatar
    Join Date
    Jan 2008
    Posts
    20
    Sponsored Links
    Sponsored Links
    How are you planning to break out of the JVM sandbox ?

    And if you have success, then how are you going to write anywhere else, but in the 1gb reserved for this stuff ? Don't you think the hypervisor will dissalow (over)writing to anything other then the reserved space ?

    Interesting theorie though ! Drop me a mail if you need help

  4. #4
    Registered User RexVF5's Avatar
    Join Date
    Dec 2007
    Posts
    185
    Quote Originally Posted by CoreTX View Post
    How are you planning to break out of the JVM sandbox ?
    No need to - BD-J requires that you have access to storage through java.io.* That means you have a tool to write known data to PS3 disk/files. Also

    Quote Originally Posted by CoreTX View Post
    And if you have success, then how are you going to write anywhere else, but in the 1gb reserved for this stuff ?
    No need to write anywhere else - the mere fact you can write files to filesystem is pretty good for analyzing changes on the disk and starting figuring out how it is encrypted (I guess per-sector or per-cluster - not per-file). Also how do you know it's 1GB only? There should be 2 parts of the storage according to specs where the so called "local" storage should be able to hold downloaded AV content, etc. So it should be pretty large in fact which leads me to assumption it is part of the filesystem. Maybe there is a hole in there - not enough checks to disallow access to other parts of filesystem...

    Quote Originally Posted by CoreTX View Post
    Don't you think the hypervisor will dissalow (over)writing to anything other then the reserved space ?
    Unless you have tried you cannot be sure there are hypervisor checks at all (not probable but what if) or that they have no flaw.

    Quote Originally Posted by CoreTX View Post
    Interesting theorie though ! Drop me a mail if you need help
    Well I am perfectly able to put the Java code together myself. What I lack is BluRay writer that would allow me test my theory and see what is accessible to BD-J code. Do you have a writer and preferably BD-RE medium so that we can experiment? If so, let's do some tests...

    Quote Originally Posted by CoreTX View Post
    How are you planning to break out of the JVM sandbox ?
    To explain more: JVM sandbox (usually when using applets) restricts access to local resources. However under some circumstances (signed applets) it is possible (and perfectly OK - it is desired function) to escape the sandbox. In case of applets the user using the browser just has to allow this. In BD-J the situation is similar. The BD-J code can under some circumstances gain access not only to "system" storage (meant for application data like settings, high-scores etc.) but also to "local" storage (meant for downloadable high-res media) but also to sockets. So you can set up bi-directional communication between BD-J code running inside JVM (running inside PS3) and something outside (you application). So it should be possible to for example create file-manager-like application, where one part would be running as BD-J code and through TCP sockets providing access to underlying storages and the other part would be somewhere on your computer.

    Before attempting that we need to research what is accessible from BD-J. I mean what part of filesystem, what system properties, is it possible to run code (through System.execute())? For this a smaller application is enough that would show all these information on screen - that can be achieved through Havi UI classes.

    Here's my thoughts about possibility to cryptographically attack (or attempt to) the encryption of the filesystem (using BD-J).

    My assumptions are:
    • You can access part of the real filesystem through BD-J. By real I mean that the accessible part is not inside another file (that's what I would call virtual filesystem) but instead creates files on PS3's native filesystem.
    • Filesystem encryption is sector (or cluster) based. In reality the smallest amount of data that can be written to HDD is one sector (usually 512bytes). To make it possible to store large files and decrease the size of "index" table (table that stores the information about free/used sectors) filesystem drivers sometimes work with multiplications of sectors called clusters (i.e. one cluster equals 2 or 4 or 8 sectors). So even if you create file of 1 byte size it will occupy size of 1 cluster. In such case the the implementation (imagine FAT/ETX3/NTFS/... driver) of the filesystem calculates where the data will be stored (cluster allocation), updates the internal filesystem structures (creation of the file itself pointing to allocated clusters) and writes the data to the disk. All these operations end up being individual sectors written to the disk. My assumption is that encryption/decryption comes as the last step (last layer before physical disk access) before disk write/read. So the layers are like this:


      <Applications>
      |
      V
      <PS3 OS>
      <Filesystem driver>
      <Disk driver>
      <Sector Encryption>
      |
      V
      <HDD>


    So here's a scenario on how to try to attack the filesystem:

    1. Create a BD-J code that will create a file of small size (512 bytes to fit into one sector) in local/system storage. Fill it with zeros.
    2. Do a snapshot of the HDD (i.e. MD5 sum of each sector)
    3. Fill the existing file with binary ones (0xFF).
    4. Do a snaphot of the HDD. Compare the differences. Store changed sectors somewhere.
    5. Fill the existing file with some other pattern (i.e. 0xAA)
    6. Do a snaphot of the HDD. Compare the differences. Store changed sectors somewhere.
    7. Repeat the steps 5. and 6. few times with different patterns. The idea here is to find the sector that physically stores the data. As you're overwriting existing file the allocation on the disk should not be changing - it should still be the same sector on the disk that you should be able to find after few iterations.


    So after few such iterations you should be having pairs of encrypted/decrypted data and can start some crypto-analysis
    Last edited by RexVF5; 05-21-2008 at 06:42 AM Reason: Automerged Doublepost

  5. #5
    Banned User CoreTX's Avatar
    Join Date
    Jan 2008
    Posts
    20
    When do we start testing ?

  6. #6
    Registered User RexVF5's Avatar
    Join Date
    Dec 2007
    Posts
    185
    Quote Originally Posted by CoreTX View Post
    When do we start testing ?
    I am reading some additional info on BD-J, MHP, OCAM, etc. - i.e. standards that govern these (only MHP has 1376 pages). I also have started to put together tools required for generating BD-J code, signing it to make it authorized, etc.

    If you have BR writer with RE media (I expect few errors from the start so better to have one rewritable media) I can send you disk image once it's ready. I will start with simple example dumping some interesting system properties, trying to create file. Later (if everything works as expected) I can add some more things (like socket handling).

    From what I have read so far it seems that correct implementation should not be able to allow JVM go outside defined directory and its subdirectories on the filesystem. But yes, it should be on the filesystem and also it is possible to find the absolute path for that directory - i.e. system property is required to be setup and point to something like /BD-J/applications/ where each application stores its data.

  7. #7
    Registered User mrbeans's Avatar
    Join Date
    Feb 2007
    Posts
    22
    How does JNI fit into the BD-J specification? Can the classpath be specified for the BD-J program?
    Can a BD-J disc actually be signed for retail players (ie PS3) without shelling out massive amounts of money for the correct keys? Or, do you already have them

  8. #8
    Registered User RexVF5's Avatar
    Join Date
    Dec 2007
    Posts
    185
    Quote Originally Posted by mrbeans View Post
    How does JNI fit into the BD-J specification? Can the classpath be specified for the BD-J program?
    Can a BD-J disc actually be signed for retail players (ie PS3) without shelling out massive amounts of money for the correct keys? Or, do you already have them
    Let me answer one by one:
    • JNI There is no provision against it (AFAIK) however:
      1. usually you need to have the binary code in special directory (somewhere in the runtime installation)
      2. or you need to provide a switch for runtime where to look for the code - which you cannot in this situation as the player (PS3) starts the runtime and you have no way to influence that somehow (and it wouldn't be portable - PS3 runtime can have different switches than somewhere else)
      3. it would be non-portable between platforms (i.e. what works on PS3 wouldn't work on other BD player)
    • specifying classpath Where would you like it to point it to? I mean the platform classes are on the classpath already and what comprises your application is on BD-J and gets to classpath by default (i.e. your .jar file(s))
    • signing the application and the keys I believe you do not need any special keys. Who would generate them? I mean anyone can produce BR disk with BD-J code on it and there is no central authority that signs that BD-J code. It just needs to be signed and the end-user decides to allow or not to allow running the code based on the signature itself (i.e. whether he trusts the issuer). It's the same as with signed Java applets - it can be signed by purely untrusted signature (no need for it to be issued by VeriSign or such) and user just needs to approve it.[br]This is just totally different kind of signing than PS3 binaries.
    • Me having the keys No I do not have the keys to sign PS3 native binaries. Signing BD-J code - I'll just create a signature myself.


    Is everything clear?

    CoreTX,

    about the testing: we will use sources from here as the start: [Register or Login to view links] So you can grab the samples from there, build the BR image and test it on PS3.
    Last edited by RexVF5; 05-22-2008 at 08:21 AM Reason: Automerged Doublepost

  9. #9
    Registered User parkerparker's Avatar
    Join Date
    Feb 2008
    Posts
    70
    rexvf5 please keep us updated! looking forward to the news.

    i've been doing some reading... and it seems like a educated attempt!

  10. #10
    Registered User mrbeans's Avatar
    Join Date
    Feb 2007
    Posts
    22
    If JNIs are supported this is simple access to executing homebrew. It is fairly common to provide multiple JNIs for the different platforms, and quite frankly I only care about the PS3 in this case

    JNIs will likely be easier to get running with access to the classpath.

    I was (apparently wrongly) under the impression that BD-Js had some signing authority in the same fashion that the blu-ray movies themselves have been signed (to prevent copying, but in the case of BD-J for authenticity.) If this isn't the case, then it seems like things should be really easy via this path.

    If I have some time I may try to give one of those samples a try.

 

Sponsored Links
Page 1 of 4 123 ... LastLast
Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News