search

espes / Slave-in-the-Magic-Mirror

Open source implementation of AirPlay Mirroring. WIP.
610 stars 122 forks source link

About the test code in drm.py #2

Closed juhovh closed 9 years ago

juhovh commented 9 years ago

Hi,

I've been tinkering with this some time ago, but seems like you've got further. It's a very cool idea to use ARMv7 runtime interpretation to run the DRM challenge-response code. I tested the code with the documented AppleTV2,1 build 9A334v airtunesd, but got the following output. I find it weird that the first response is only 142 bytes long, do you have any idea why it's not 164 bytes as expected on my machine? I know the code is very much WIP, but I'm interested in helping on this if possible.

$ python drm.py [1073741824, 291, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1879048192, 4109694196, 275892] 100000 63295.7077634 200000 66894.9766774 did 281309 instructions we're done! 0

Stage 0

[2, 291, 1073741828, 1073742104, 0, 0, 0, 0, 0, 0, 0, 0, 12879995, 1879048176, 4109694196, 962572] 100000 72964.1113567 200000 72360.8117142 300000 72152.658041 400000 71100.1777037 500000 69304.7489314 600000 69734.3588932 700000 69709.721769 800000 69786.8433923 900000 69934.9988462 1000000 70177.3007911 did 1019849 instructions we're done! 0 args ['0x2', '0x123', '0x40000004', '0x40000118', '0xabc', '0x40000128', '0x4000012c', '0x40000130'] r 0x0 out_data 0x40000134 out_length 0x8e out_stage 1 46504c59020102000000008202012e3e9bd77e1ce3b7dad273e8a6f8492e17839b7d0eed2054d83a557a588e4fa3312422ada4ea27722bfb2d1701e5a5da52fc4b227256cfd59cfa75df7644a6d8eab9714fb93bb7432a6e9a7be4e4ac5be4d18c4e06b052f27ca4d2bbfa869c23eea913d13a9f5a2cc77aa5ccf0819e761c9ba6de49755d380ba11964d318a578 Traceback (most recent call last): File "drm.py", line 128, in assert r0 == "46504c59020102000000008202012157a656cf4046c01a75aad3fce23a29caf39d1a4f9b3c2db38519b0e9486e3da39f956d57db3eadc5f87c33f31ae1b5e28d23c45ac26dd15d8bdc04808440f4065657b1df9e12895c9b88a7a2b707ef2c23959012d4fcc733a0e8e3cc496e8bdebf2bfff7e9e906748dfe3ebbee8ebe798365ac0b4f9e40e034df3c7781849c".decode("hex") AssertionError

juhovh commented 9 years ago

Actually ignore the length, there's the check of first stage response length being 0x8e, so I guess my memory servers me wrong and the first response is supposed to be 142 bytes. However, the value doesn't seem to match except for the beginning (which is always taken from challenge). And if I try to get a stage 1 response with the input in drm.py file the result is still wrong, 982 instructions is very little and out_stage 255 is obviously wrong. What makes this weird is that my airtunesd SHA-1 hash matches, so I don't understand how it is possible to get different results on this.

[2, 291, 1073741828, 1073742104, 0, 0, 0, 0, 0, 0, 0, 0, 12879995, 1879048176, 4109694196, 962572] did 982 instructions we're done! 4294925211 args ['0x2', '0x123', '0x40000004', '0x40000118', '0xabc', '0x400001bc', '0x400001c0', '0x400001c4'] r 0xffff5b9b out_data 0x400001c8 out_length 0xc out_stage 255

espes commented 9 years ago

That test code is wrong since I changed the implementation of arc4random (from 'return 1337' to 'return 4' :P)

juhovh commented 9 years ago

Thank you, this fixes it. :)

I guess it is necessary that the random stream is the same for both stage 0 and stage 1, because with a different arc4random stream that otherwise valid stage 1 challenge broke.