Audible...

[judb]

Okay, I have a question for you folks.

Does anyone on here have a subscription to Audible?

I recall the VW phatbox I bought had a few files on them that were encrypted compressed audio files that would ONLY work on my phatbox as they were signed somehow.  I believe that audible content is downloaded and signed by the PMM but I dont know for sure.

looking at the exec.ini it says

Code Select Expand

auth.loop=/dos/swgrli
auth1.loop=/dos/nmp3
player.pna=/dos/aadec
auth.pna=/dos/nmp3
auth1.pna=/dos/hdparm
auth2.pna=/dos/pkeysa.e

So my questions are at this point around things I am not exactly interested in doing but would be steps toward the end goal of DMS drive swapping..

pkeysa.e looks like it may be the binary to validate the keys once the OS is booted...  and thats how they keep you from playing "protected content".  

Forgive me if this seems obvious as I didn't see it in any of the what we know now threads.  I don't know this for a fact as I dont have an arm emulator or test board to play with but I am pretty sure thats what that file does.


Also, Someone who can do a network packet capture please contact me about some other research I think we need to do to solve these issues.  I don't really want to post about it just yet.


For the RECORD, I dont care about getting around the stupid file locks for playback of protected content, i just want to expand my drive size but I think these two things are going to be locked together.  I hope this doesnt make our activites illegal.

It would be a lot easiear if they just gave us the ability to sign our own drives so if we download content to it its still protected to that specific drive instead of making us have to unravel the whole thing.

[para]

That's it! Our main goal is exactly what you describe. Maybe it should be noted that opening the PB to customizations is a totally different story! At the moment we only care about upgrading the drive in this subsection...

I agree, pkeysa.e is the public key for the signature validation of the files and the DMS. Playlists have a different public key (pkeys2.e).

For ARM emulators you should check out
this thread.

I don't see the connection between audible content and the PB signatures. Can you explain your thoughts in detail? FYI, the listed files are the audioplayers/codecs only AFAIK.

Para

[judb]

Well, the preloaded files on the VW phatbox I got were in the .pna format.  in looking at the exec.ini it seems that there are some functions that it calls for .pna files that involve hdparm which is an arm elf binary and pkeysa.e which instead of being the key might be another executable .. however objdump doesnt recognize it as an elf binary, so I am not sure.

My theory at this point is that the exec.ini is somehow telling the nmp3 decoder to call hdparm and pkeysa.e to decrypt the stream of audio before playback.

Theres some other things that I really dont want to post in here just yet that I have been trying ... can you get the PM feature to work?

[para]

Ok, now I see where you're coming from...
WTF has that public key to do with audible? It should have other purposes (see above) as authorizing audible files! hdparm seems to be used by Phatnoise's modified audible (aac) as it's a common way to identify a certain box by it's drive ID (in this case stored in /tmp/drive.id) - sounds familiar doesn't it...? By the way, what does pna mean? Phatnoise Audible?

Generally it looks like nmp3 is the actual audio player which uses different codecs like aadec if no dedicated player (oggplay, phatwma) is available.

Para

PS: Paul's the only admin around here...

[judb]

Exactly.  So, since I dont have the VW phatbox anymore, just some music kegs.. I dont have those protected pna files to dick with.  I was going to see if audible content got dumped into .pna files.

***IF*** they do, and it uses the NON playlist key that means that the PMM has to have a way to sign those files, and following that logic, would have the key to sign other things too possibly... since I doubt that the send the drive id to audible and then they sign the file before being sent.

I mean look at the itunes bypass that DVD John put out, itunes software watermarks and DRMs the files after its downloaded, so it would be senseable that phatnoise would follow a similar idea.

[para]

Yep, sounds reasonable to me. Especially if you look at aacdec you'll find an "activation file" in /dos/Data/PnaActPack (in your PHTDATA root)! Furthermore there's (cheers Brendan) a function called RSAPrivateDecrypt() which looks as the private key is actually there but encrypted (i.e. /dos/pkeysa.e which would explain the .e) But what is used to en-/decrypt a private key Even more interesting is the directory /pn. That might be the place the decrypted private key is stored during runtime! That takes me back to the serial approach...

On the other hand this is a bit contradictory to the fact that they use a keyserver for their file signing script :-/

Crank it up, Para

[judb]

Anyone know anyone with an IDE logic analyzer?

[sbingner]

On the other hand this is a bit contradictory to the fact that they use a keyserver for their file signing script :-/

Crank it up, Para

Naw, thats the private key... it sounds they're encrypting the public key for some reason.... they HAVE to provide the public key somehow or they couldn't verify the sigs...

[para]

Erm, that's why I'm wondering about my findings (see first paragraph) - they sound strange...
I'm also of the opinion that pkeysa.e is the public key but what's the purpose of that function then?

it sounds they're encrypting the public key for some reason

There's no reason to do that as it doesn't help anyone...