Finally handling BD+ (?)

[oibaf]

Heh evvktvh (http://www.evvk.com/evvktvh.html#english)
:)

Pick a license that you think would be best, and I'll put it on the files I made. I've used New-BSD in the past, but I care not about these things.

While I can't say nothing since I did not write a line of that code, I would suggest GPLv3 or later, since:

it prevents others taking the code and re-releasing it as closed source software (we already have AnyDVD with its secret, closed source implementation);
it also prevents Tivoization (http://en.wikipedia.org/wiki/Tivoization) (permitted by GPLv2).

[loo3aem3ON]

Here is a snapshot package of "Jumper" from a player which uses the current publicly available key set.

Jumper v1.01 (http://uploaded.to/?id=al3531) *new*
Jumper v1.00 (http://uploaded.to/?id=9kqx1z)

The content code does a lot more checking which should help us finding some of the hidden bugs.

Also note that trap#8010 is sending this message to the console:
2008-10-17 02:50:19.82 playback starts

[Disabled]

First I want to give you all a big thumbs up for your work! I'm sorry I just left your project but felt like there were better developers involved now.
I wanted to comment about the licence. I don't think GPLv3 is a suitable licence for this project. I don't think Tivoization will be a problem, because if someone legally sells hardware with this lib he has to comply with the BD licencing authority and I don't think they will allow this lib to be used. And if you use v3, GPLv2 only software won't be able to use this lib. I wouldn't even mind, if someone writes a free but closed source app using this lib (commercial would again be a problem because of the BDLA) so I would choose the "LGPLv2.1 or later" licence, but if you don't want to support closed source software I would use "GLPv2 or later". The "or later" is important that GPLv3 software like dumphd can use it without problems. I tried to search GPLv2 only software but many players (like mplayer) just state its licence as GPL without a version, so it would at least be unclear if it could link to a GPLv3 licenced software.
As far as I can see libaacs is under an evvktvh style licence.
To sum LGPLv2 up as I understand it: You have to release any changes you make to the lib, but your program can have any licence you want.

[loo3aem3ON]

And another bug found. This time in:
UINT32 TRAP_DeviceDiscovery(UINT32 dev, UINT32 qID, UINT8 *buf, UINT32 *len);
The content code tells the player how many bytes of memory are reserved for the answer it expects. This length is stored at <*len>. The player checks if the space is sufficient and after writing the answer it updates the length with the number of bytes it has written. The issue is fixed in revision 138.

Edit: simplified and correct the explanation above. :rolleyes:

[MickJT]

The issue is fixed in revision 138.

Sorry for asking, but of what, and where?

[Accident]

I would have expected that all traps that take a pointer to uint32_t len, expects it modified in return. For example, TRAP_LoadContentCode, if the read is short. Just a guess though. Why make it a pointer if it isn't expecting a return value.

Edit:
Never mind, turns out I already do. I should change trap_DeviceDiscovery to check there is enough room as well though.

[loo3aem3ON]

I would have expected that all traps that take a pointer to uint32_t len, expects it modified in return. For example, TRAP_LoadContentCode, if the read is short. Just a guess though. Why make it a pointer if it isn't expecting a return value.
So far we only used this to return the <number of bytes written> but we never read the length from this address.

I should change trap_DeviceDiscovery to check there is enough room as well though.
That's exactly what the debugger was missing too. :)

Next problem:
UINT32 TRAP_MediaSHAFileHash(UINT8 *FileName, UINT32 FileNameLen, UINT32 FileOffsetHigh, UINT32 FileOffsetLow, UINT32 *len, UINT8 *dst);
*edit* This system call has to check how many chunks it can read from that file position and update the length at <*len> accordingly before returning. */edit*

Edit: corrected description of problems with TRAP_MediaSHAFileHash above. It was originally stated that this system call would only produce one hash (0x14 bytes) and hashing only the first chunk (0x200 bytes). This wrong statement was due to insufficient testing and the lack of any description about this trap.

[Accident]

So TRAP_MediaSHAFileHash only ever does _one_ hash, or, always return the hash-block size 0x200, but produce all digests requested?

Edit:

Never mind the date thing. "2008" is not two bytes with "20" and "08". Sigh


Also, it is entirely possible the only does ONE hash is because of:

[trap] reading 'BDSVM/00002.svm' at pos 00000000013ffe00
trap: read bytes and SHA_BLOCK
[trap] shaMediaFile warning short read


It was only able to read ONE block 0x200 after all, then it is at EOF.


Edit2:

After those little fixes, Jumper gets further but I do not think I can make it complete, without at least two shablocks of the main file:


[trap] reading 'BDMV/STREAM/00005.m2ts' at pos 00000000ae8d5200
[trap] reading 'BDMV/STREAM/00005.m2ts' at pos 00000002a84dce00

dd if=00005.m2ts of=shablock1.bin bs=512 skip=5719721 count=1
dd if=00005.m2ts of=shablock2.bin bs=512 skip=22292199 count=1

It dies soon after. But I take this as good news.

[loo3aem3ON]

Also, it is entirely possible the only does ONE hash is because of:

[trap] reading 'BDSVM/00002.svm' at pos 00000000013ffe00
trap: read bytes and SHA_BLOCK
[trap] shaMediaFile warning short read


It was only able to read ONE block 0x200 after all, then it is at EOF.
All the time i thought it was hashing 00002.m2ts which is of course much bigger. Now that was stupid. The debugger also never checks how many bytes it was able to read from that position. :rolleyes:

After those little fixes, Jumper gets further but I do not think I can make it complete, without at least two shablocks of the main file:
Here (http://uploaded.to/?id=i4vb1p) they are. Also if you prefer the original full snapshots you can still extract them from the diffarchives using the diffarchive tool from the repository. You can select this from the menu once you start the tool. :)

[Accident]

Thanks for the blocks, libbluray-0.0.5.tar.gz (http://uploaded.to/?id=a6nfwc) can handle Jumper as well.


[segment] Starting decode of conv_tab.bin: 0x4dfafc (1035732)
[segment] num tables 31
[segment] Table 0 ID 00000000, 1 segments.
[segment] Table done. Setting ptr to 00000010
[segment] Table 1 ID 00000001, 1 segments.
[segment] Table done. Setting ptr to 0000001E
[segment] Table 2 ID 00000002, 5 segments.
[segment] Table done. Setting ptr to 0000004C
[segment] Table 3 ID 00000003, 8 segments.
[segment] Table done. Setting ptr to 00000092
[segment] Table 4 ID 00000004, 11 segments.
[segment] Table done. Setting ptr to 000000F0
[segment] Table 5 ID 00000005, 446 segments.
Segment 0 offset 000007EE -> 3 entries
Segment 1 offset 0000082E -> 58 entries
Segment 2 offset 00000CBA -> 67 entries

-rw-r--r-- 1 owner group 1035732 Nov 18 21:52 jumper_conv_tab.bin

real 0m1.535s


Edit;

Uploaded

[loo3aem3ON]

Thanks for the blocks, libbluray-0.0.5.tar.gz (http://uploaded.to/?id=a6nfwc) can handle Jumper as well.
The debugger can't handle "Jumper" currently. The segment keys are wrong but this doesn't mean yours have to be wrong too. Actually the main reason i bought this movie for was to find bugs and not to add quick support for it. You should also work with the snapshots to test your implementation. For example TRAP_Sha is still wrong and TRAP_DiscoveryRAM is giving wrong results too.

[Accident]

Ah I suppose there is no way to know if the segment keys are wrong without snapshot use? Hmm I guess getting offsets that aren't strictly increasing in order would imply the values are incorrectly descrambled.

[KenD00]

Q:
Ah I suppose there is no way to know if the segment keys are wrong without snapshot use?


A:

Hmm I guess getting offsets that aren't strictly increasing in order would imply the values are incorrectly descrambled.


And in the way how the patch offsets are calculated i assume that the patches shouldn't exceed TS packet boundaries too. A quick check with ConvTableView tells me that my Jumper conv_tab.bin is indeed not correctly decrypted :(.

:rolleyes:

[IceM]

Nice project and nice progress! Im a developer myself and since im lazy I was wondering what hardware was needed to contribute to this project? (e.g. hardware needed for testing). Any special drives that require firmware patching or does any bd drive do?
About the licensing, please read the TOS of assembla, if I remember correctly they had a few things in there that stated that they get rights on your code once you commit it to the svn.

[loo3aem3ON]

Ah I suppose there is no way to know if the segment keys are wrong without snapshot use? Hmm I guess getting offsets that aren't strictly increasing in order would imply the values are incorrectly descrambled.
There are some checks done (e.g. if the first two bits of the flags byte are either '01' or '10') but i haven't studied this yet. I suggest to make a list of problem i should look into (with priorities) and put it into the repository where it gets updated.

Im a developer myself and since im lazy I was wondering what hardware was needed to contribute to this project? (e.g. hardware needed for testing). Any special drives that require firmware patching or does any bd drive do?
We obtain snapshots and traces of the vm state from licensed players which we use for automatic testing and to force our emulators to "stay on track". If an emulator enters a different state than the licensed player we evaluate the differences (console debug output) and "correct" the state before resuming execution.
So with these snapshots/traces you can write your own emulator without any blue ray drive or disc. Later you probably want to test your implementation with content code from a disc we have no snapshot/trace packages for. Then you would need a blue ray drive for which volume id firmware patches are available (see this (https://forum.doom9.org/showthread.php?t=139522) thread),

A sample snapshot/trace package can be found in posting #402 (https://forum.doom9.org/showpost.php?p=1213980&postcount=402).

About the licensing, please read the TOS of assembla, if I remember correctly they had a few things in there that stated that they get rights on your code once you commit it to the svn.
We should put the code under GPL and hope nobody complains. I don't think the license makes a big difference though.

[IceM]

And with licensed players you mean software players like windvd/powerdvd?

[Accident]

I don't suppose we could get the first (say, 5?) correct segment keys posted for Jumper? I have been looking at what it does with each Segment key request, and I am quite surprised that each one is quite different. 5/0 Calls lots of Aes(). 5/1 AddWithCarry+Memmove, 5/2 MemSearch, 5/3 SHA, and so on. How tedious for them.

Anyway, during the testing of Aes, there is a whole bunch of tests that should fail, but one succeeds that I suspect should not:


[dlx] Aes(003DEA6C, 003DEA4C, 00000002, 003DEA54, FFF10000


*dst and *key overlap (and even *src, but perhaps that is valid). I have added an additional check with "dst+len vs key" so mine fails.

My segment keys are currently:

27 AF 07 95 76 A7 B6 55 88 16 46 0C 37 85 06 3B
9C 33 19 F9 E9 E5 01 51 5F F1 9F 4C CB 34 19 A4
CE 5D 01 4C 82 D2 2A 45 90 A1 B6 D0 F2 F1 4A 2C
10 DC 7C 22 31 05 8C 63 12 57 28 8B 3B 96 C1 CF
A3 BF 52 C8 7D F3 88 D6 2B 10 7C 19 FD 37 C1 BF


5/0 Segment _could_ be valid, but 5/1 definitely seems wrong (its offset is before 5/0)

[js06078]

Accident: See posting #213 (http://forum.doom9.org/showthread.php?p=1193182#post1193182) for the behaviour of the segment-key-computing events. Basicly, every event 0x220 is repeating different parts of the previously (i.e. during VM-initialization or after event 0x110(1) was invoked) executed trap-checking before it reads from slot 0 and then computes the segment key (of course only if the trap-testing was 'succesful', i.e. the player behaved like a licensed player).
However, notice that the BD+ developers may change the content code so that these events could be treated completely different in future BD+ versions. But until now, each invocation of event 0x220(<m>,<n>) is testing different traps for increasing values of <n> (and/or <m>, actually).

Another information that I didn't see in this thread yet: Section 1 of the file 00002.svm holds the encrypted conversion table for all the movies that have been looked at in this thread.

Also, here is an analysis of the snapshots for "Jumper" (Debugger Revision #143 was used to create the analysis):

- Trap_DiscoveryRAM is still giving quite a few errors. The first call with errors is probably due to an updated player-firmware on the snapshot-creator's system. Here is one of the other problematic calls:
#004114 TRAP_DiscoveryRAM (00254E23, 003DFCA0, 00000080);
[!] memory difference after trap call: 3DFCA0: 6A (vm) != 5C (snapshot)
[!] memory difference after trap call: 3DFCA1: C7 (vm) != 31 (snapshot)
[!] memory difference after trap call: 3DFCA2: 9E (vm) != 0C (snapshot)
[!] memory difference after trap call: 3DFCA3: EF (vm) != ED (snapshot)
...
[!] memory difference after trap call: 3DFD1C: DE (vm) != 44 (snapshot)
[!] memory difference after trap call: 3DFD1D: CC (vm) != 01 (snapshot)
[!] memory difference after trap call: 3DFD1E: 9B (vm) != C4 (snapshot)
[!] memory difference after trap call: 3DFD1F: 36 (vm) != 8D (snapshot)


- Trap_SHA has a bug (which got even worse with revision #143). This bug seems to appear, when more than 512 bytes are being added to the SHA-context, such as here:
#000502 TRAP_Sha (003DFD8C, 00001180, 00001000, 00000001);
[!] memory difference after trap call: 3DFD8C: 01 (vm) != E1 (snapshot)
[!] memory difference after trap call: 3DFD8D: 23 (vm) != D0 (snapshot)
[!] memory difference after trap call: 3DFD8E: 45 (vm) != 1A (snapshot)
[!] memory difference after trap call: 3DFD8F: 67 (vm) != 82 (snapshot)
...
[!] memory difference after trap call: 3DFD9D: E1 (vm) != 92 (snapshot)
[!] memory difference after trap call: 3DFD9E: D2 (vm) != FC (snapshot)
[!] memory difference after trap call: 3DFD9F: C3 (vm) != 5B (snapshot)
[!] memory difference after trap call: 3DFEE9: 00 (vm) != 80 (snapshot)


- Trap_DeviceDiscovery is (on ~4 occasions) still being executed even though it shouldn't be executed according to snapshots (probably due to bad length-value at <pLen>):
#005735 TRAP_DeviceDiscovery (00000001, 00000001, 003FFD48, 003DF814);
[!] register difference after trap call: r01: 00000000 (vm) != 80000001 (snapshot)
[!] memory difference after trap call: 3DF816: 01 (vm) != 02 (snapshot)
[!] memory difference after trap call: 3DF817: 1C (vm) != BC (snapshot)
[!] memory difference after trap call: 3FFD49: 00 (vm) != 01 (snapshot)
...
[!] memory difference after trap call: 3FFE60: FA (vm) != 00 (snapshot)
[!] memory difference after trap call: 3FFE61: F3 (vm) != 00 (snapshot)
[!] memory difference after trap call: 3FFE62: 72 (vm) != 00 (snapshot)
[!] memory difference after trap call: 3FFE63: 6F (vm) != 00 (snapshot)


- Trap_DeviceAccess is not implemented, but one call of this trap (with 'new parameters') actually writes a result to VM memory now:

#004650 TRAP_DeviceAccess (00000001, 00000000, 003DFB70);
[W] TRAP_DeviceAccess not implemented!
[!] memory difference after trap call: 3DFB70: 00 (vm) != 0F (snapshot)
[!] memory difference after trap call: 3DFB72: 01 (vm) != FF (snapshot)
[!] memory difference after trap call: 3DFB73: 00 (vm) != FF (snapshot)


The same events as before are called for Jumper, with one exception:
- event 0x110(0,0x13)

is used for decryption of the conversion table (?) instead of
- event 0x110(0,1)

This could mean, that the sub-table with id=0x13 needs to be decrypted instead of the one with id=1. This would be reasonable if the sub-table with id=0x13 holds the repair-descriptors for the protected parts of the disc. :confused:

Also notice, that Trap_0x20 (usually signalling the adress and length of the decrypted conversion table to the player) is never being called with other parameters than (0,0x1000) in the snapshot-package for "Jumper" :confused:

[loo3aem3ON]

I don't suppose we could get the first (say, 5?) correct segment keys posted for Jumper?
Why not? Everything is recorded in the snapshot/trace packages. See posting #402 (https://forum.doom9.org/showpost.php?p=1213980&postcount=402) and download the new Jumper snapshot package v1.01.

The first 5 segment keys are:
62 9E 6A 71 B7 75 62 00 98 9C 7D E6 6A 35 2D 5D ( subtable 5, segment 00)
90 85 E7 C4 92 05 A8 EF 6A AB D3 0C 6A 86 09 29 ( subtable 5, segment 01)
E5 E8 5D 4F FE AC 6B 39 2B 04 04 44 D8 A4 A0 51 ( subtable 5, segment 02)
6D C7 8E 75 6F 32 46 01 5E A6 B4 B7 81 82 12 55 ( subtable 5, segment 03)
E0 D5 F7 C5 6C 62 E8 D6 C4 0E DA 87 4B AF 8A 29 ( subtable 5, segment 04)

Anyway, during the testing of Aes, there is a whole bunch of tests that should fail, but one succeeds that I suspect should not:
Like i said please make a list of things you want me to check. Apart from that please use the snapshots because they are correct.

Also notice, that Trap_0x20 (usually signalling the adress and length of the decrypted conversion table to the player) is never being called with other parameters than (0,0x1000) in the snapshot-package for "Jumper" :confused:
That's because the snapshot/trace package was too short. A more extensive version is avaliable in posting #402 (https://forum.doom9.org/showpost.php?p=1213980&postcount=402).

[loo3aem3ON]

I've fixed a bug in the parameter checking of TRAP_DeviceDiscovery (thanks js06078) and another bug in TRAP_Sha (thanks [anonymous]). It seems the segment keys for jumper are correct now so i will make this a new release:

Download: BDVM Debugger v0.1.2 (http://uploaded.to/?id=40hx0q)

Please report back and tell us if you experience any problems.

[loo3aem3ON]

There might be an issue when repairing a movie with the correct conversion table. I've compared the results and some repair descriptors are ignored by AnyDVD-HD. Either these descriptors insert invisible watermarks for the industry to trace any illegal copies back to a player or these descriptors are invalid (maybe a parity bit in the 'flag' byte?) and would only corrupt the movie even more.

This (http://uploaded.to/?id=61qui7) archive contains the conversion table i get for "Jumper" as well as a list of the first few descriptors which were not applied by AnyDVD-HD.

Edit: fixed link

[js06078]

While taking a look at "Jumper v1.1" snapshots, i noticed, that there are some additional invocations of event 0x110 with different parameters (0x13,2,0x14,3). They all do similar trap-testing but do not create a conversion table. This seems to be obfuscation tactics but I guess it can be easily skipped (by completely ommiting invocation of these events). However, the last event before the playback of the movie starts is event 0x110(1) and it loads the conversion table (Length: 0x000FCDD4, Offset: 0x002DFAFC).

Here are some more bugs that I noticed:

#018343 TRAP_Aes (003DE214, 003DE224, 00000000, 003DE1C4, FFF10000);
[!] register difference after trap call: r01: 00000000 (vm) != 80FFFFFF (snapshot)


This happens once per each call of event 0x220(5,n):
#018346 TRAP-SlotRead (003DF968, 00000000);
[!] memory difference after trap call: 3DF9B2: 01 (vm) != 00 (snapshot)
[!] memory difference after trap call: 3DF9B3: 13 (vm) != 2E (snapshot)

I guess it happens since the slot-treatment still uses data from an older player-version.

One more small bug:
#018619 TRAP_MemSearch (003BFA5C, 00000014, 003BFA6E, 00000002, 003BF99C);
[!] memory difference after trap call: 3BF99D: 00 (vm) != 3B (snapshot)
[!] memory difference after trap call: 3BF99E: 00 (vm) != FA (snapshot)
[!] memory difference after trap call: 3BF99F: 00 (vm) != 6E (snapshot)


None of these bugs seems to be crucial for correct conversion table creation and decryption, but I think it would be best to make the debugger behave as identical to the player as possible.

[loo3aem3ON]

While taking a look at "Jumper v1.1" snapshots, i noticed, that there are some additional invocations of event 0x110 with different parameters (0x13,2,0x14,3). They all do similar trap-testing but do not create a conversion table. This seems to be obfuscation tactics but I guess it can be easily skipped (by completely ommiting invocation of these events).
Event 0x0110 is issued when the playback of a new file starts.
0x13 = 00019.m2ts = Still frame "Mismatch between disc and player region codes. See disc packaging for details."
0x02 = 00002.m2ts = ? (mplayer crashes)
0x14 = 00020.m2ts = Still frame "Thank you for buying ... "
0x03 = 00003.m2ts = a movie trailer
...

Thank you for reporting more bugs.

[js06078]

About the redundant / ignored repair descriptors:

I noticed that whenever a descriptor is ignored by AnyDVDHD, there would have to be two blocks of 15 consequent bytes replaced (according to the conversion table). Since one descriptor is ignored by AnyDVDHD, one or sometimes both of these blocks get 'destroyed' by the ignoring.

The first five bytes of both 15-byte-blocks are always identical.

Also, the redundant descriptors only appear at the very end of segments.

The first four bits of the flag-byte of an ignored discriptor are always equal to 8 or 9.

Here's a list of the replacements which are listed in the conversion table. Red bytes are being ignored by AnyDVDHD:

Segment 6, Repair descriptor 121:

0x0FD32E5A 1E8A98D1B1 9E6E15DFF1 0FBBC6301
0x0FD48D5A 1E8A98D1B1 9B5B5C1848 0D2FF1F71
0x0FD55B0A 3D5A9618E8
0x0FD64F5E 324617AFFD


Segment 8, Repair descriptor 121:

0x14EFFF9A B47812BEE4 D1A21040BA 651E2AB21
0x14F055DA B47812BEE4 BD45D8F6C5 FAFA45E0B


Segment 18, Repair descriptor 96:

0x2F50675A D873292C18 6A30131FEA 66E24B4B3
0x2F50BB5A D873292C18 89422BF869 875A2840F


Segment 19, Repair descriptor 129:

0x322C71DA A87F313984 4865272D91 74635ECD9
0x322CF39A A87F313984 29A4811976 7DDB59396


Segment 25, Repair descriptor 111:

0x4186B0DA DC741B3DBC D91F56B81D 98B4830A0
0x4187005A DC741B3DBC 75FC8AE136 CA346216C


Segment 33, Repair descriptor 116:

0x54CF45DA E708FA730C 312E60B2E3 B91D2EF2D
0x54CF949A E708FA730C B17E1AF0C8 0F8710CCF


Segment 34, Repair descriptor 91:

0x5706D5DA 02254DAA8F D4341B50C5 08C36DB56
0x57079E1A 02254DAA8F 52B4CFF223 CB6F7B9CC


Segment 41, Repair descriptor 119:

0x68B5871A 158D698E14 1E9D52D154 8E8332D81
0x68B5FB5A 158D698E14 D117525EC1 6F716690A


Segment 44, Repair descriptor 113:

0x70737E5A 65BA46F8C4 3C496C5F9D BF6BE4233
0x7075231A 65BA46F8C4 F2B4A9DA70 CC04B24AC
0x70767B16 2D9BC7F50A
0x70768DB2 0AEA4EB805


Segment 47, Repair descriptor 121:

0x798EB39A 5DCCE19B5E 1E1A5E13A1 A4EACCFE3
0x798F6A9A 5DCCE19B5E 0701561564 11124E630

[loo3aem3ON]

The first four bits of the flag-byte of an ignored discriptor are always equal to 8 or 9.
It's more difficult than i previously thought. The first byte of the repair descriptor header (currently called "flag byte") consists of two parts. The most significant two bits seem to define the type of the descriptor. They can either be '01' or '10' (meaning type 1 or 2). The remaining bits are a bit address inside a 64-bit array which acts as a mask for the descriptors of type 2:
FB BD FD FF 7F EC DB FF
Now given a repair descriptor it is checked if it is of type 1 or 2. In case of type 2 it is checked if the bit at the given address (specified by the six least significant bits of the flags byte as explained above) is set. If it is set the descriptor is applied otherwise it is ignored.

Example:
The first descriptor that is not applied is:0x00002B1A: Segment 6:
121 0x00151A2D 0x8E 0x13A 0x000 0x1F 0x24 0x0FD48D5F 0x0FD48D64 0x9B5B5C1848 0xB0D2FF1F71
The first byte of the header is 0x8E which means type 2 and bit address 0x0E. So we have to look at bit (0x0E & 0x07) = 0x06 of byte (0x0E >> 3)=0x01. Byte number 1 is 0xBD and the bit 6 is not set (0xBD & 0x40 = 0) so this descriptor is ignored.

I don't know where the array comes from. Most likely from the content code so it should appear at some time in our memory.

[Accident]

Just reporting in. The bug fixes in Debugger I had already counted for in libbluray, but I had other bugs. One in DiscoveryRAM (Name repeating, memory over-step), Missed (dst < src) test in PrivateKey (?) and DiscoveryRAM len test of 0x100000.

It is still not quite right, but I am slowly getting there. Also, diffarchive support has been added.

Edit:
Bugger, I could not get the Jumper snapshot do to anything right for the longest time, and it only just occurred to me that I downloaded the new Jumper snapshots, but never extracted. Sigh.

One worry at the moment is this call:

[dlx] PrivateKey(00000000, *00005E58, *0000232C, 00000010, 00000000)
[dlx] TRAP return: R1 = 00000000
[bdtest] comparing with 'post_trap_snapshots/post_trap_reg_000720.bin'
[bdtest] comparing with 'post_trap_snapshots/post_trap_mem_000720.bin'
+00005E50 00 00 00 00 00 00 00 00 20 17 4D E3 86 06 D1 78 |..........M....x|
-00005E50 00 00 00 00 00 00 00 00 39 9A 25 75 15 78 26 7A |........9..u.x.z|
+00005E60 CF AE 0C 0C 4D 8A F8 08 1E F2 F6 9B 4E 1F 42 2A |....M.......N.B.|
-00005E60 AF B6 6B 12 29 90 8F 80 82 E1 A3 79 94 49 18 C7 |..k........y.I..|
+00005E70 B4 A0 EB 40 31 22 D2 D8 83 C9 E6 2E A2 39 0E 37 |....1........9.7|
-00005E70 A3 E9 59 FC 26 F1 9A 5C 17 3A 53 A2 BF D9 A1 1F |..Y.......S.....|
[dlx] compare complete. At least 3 differences.


Is PrivateKey allowed to differ, or generally should it not?

Edit:

Thanks loo3aem3ON. I shall not worry about it. The snapshots get me the correct Segment keys finally, I just need to get it to produce it unguided.

[loo3aem3ON]

Also, diffarchive support has been added.
Now that's some good news! :)

Happy debugging and please make sure you don't implement anything undocumented just to make it work for this snapshot package (like Schluppo did it sometimes). If you have any questions make a list and send it to me. ;)

In the meantime i've studied some attacks on the RSA scheme with small exponents. Because of the content code running on a virtual machine and therefor being very slow the license administration has chosen a very small public key exponent e = 3 in order to improve the speed. It is well know that this leaks half of the most significant bits of the private key d.

The result is:
d'=
5CB9BF8C681B23E2E923E0EAFD02129E20D0137B1F4E411829A2D76F3E004EE9
EFC2FF78D3870835A4E1CB06EEF61911CA0D5F049F2135937834A5566E7520E0
2701D405BE8A18EBB036BBBE19DDA674662EF16CBBBBC72F2C49A93C4417586F
A1E1220331335DA182CDE42B41BD443527EBEFBB7C206268F526191EB2CE05B9
63506A7C9BD0CBFD568DE0AF77479731B050965B87E574CAAFAAF3A3DEBA1CE5
where d' is the approximation of d satisfying:
| d' - d | <= 2 * square_root( N )
Where N is the public key modulus of the BD+ license administration. Finding the private key of the license administration would be a major step towards a break of BD+.

[tteich]

Now that's some good news! :)

Happy debugging and please make sure you don't implement anything undocumented just to make it work for this snapshot package (like Schluppo did it sometimes). If you have any questions make a list and send it to me. ;)

In the meantime i've studied some attacks on the RSA scheme with small exponents. Because of the content code running on a virtual machine and therefor being very slow the license administration has chosen a very small public key exponent e = 3 in order to improve the speed. It is well know that this leaks half of the most significant bits of the private key d.

The result is:
d'=
5CB9BF8C681B23E2E923E0EAFD02129E20D0137B1F4E411829A2D76F3E004EE9
EFC2FF78D3870835A4E1CB06EEF61911CA0D5F049F2135937834A5566E7520E0
2701D405BE8A18EBB036BBBE19DDA674662EF16CBBBBC72F2C49A93C4417586F
A1E1220331335DA182CDE42B41BD443527EBEFBB7C206268F526191EB2CE05B9
63506A7C9BD0CBFD568DE0AF77479731B050965B87E574CAAFAAF3A3DEBA1CE5
where d' is the approximation of d satisfying:
| d' - d | <= 2 * square_root( N )
Where N is the public key modulus of the BD+ license administration. Finding the private key of the license administration would be a major step towards a break of BD+.
I'd guess you're aware of these papers:
www.cs.umd.edu/Honors/reports/Everstine/390ResearchPaper.pdf
and
theory.stanford.edu/~dabo/papers/RSA-survey.pdf

[loo3aem3ON]

I'd guess you're aware of these papers:
www.cs.umd.edu/Honors/reports/Everstine/390ResearchPaper.pdf
and
theory.stanford.edu/~dabo/papers/RSA-survey.pdf
I knew the first one. The second one looks promising too.

About the mask: You can find it at address 0x00000020 after event 0x0220. This is directly behind the section key. Every section has it's own mask like it also has it's own section key. The mask for the first section is "0E 95 0C 80 8F A5 F6 A2". Start counting the bits from the right hand side so "A2" contains bits 0-7 and the last byte "0E" contains the bits "56-63". The section masks for first sections are:
0E 95 0C 80 8F A5 F6 A2
77 7F 79 FC 27 DF 86 FB
9F F7 8A FF 3B EF 73 9B
B3 7F BF D7 CF BF DF E7
D4 EB AE 58 FD DD F2 B5
F9 B1 EF 79 5F D6 F7 CF
FF DB EC 7F FF FD BD FB
...
In my previous example the section mask for section 6 was given in reversed byte order so don't be confused.

[tteich]

I knew the first one. The second one looks promising too.

...
Out of curiosity: is the same key that is used for decryption of the content (AACS title key) also used for the signature verification in BD+? If yes, this would violate the good practices of cryptography (don't use the same key-pair for 2 different things). If not: does BD+ comprise some sort of key revocation and renewal scheme?

[js06078]

Suggestion about the redundant descriptors:

When each repair-descriptor is XORed with the current segment key (after each event 0x220 in the debugger), one might also check, whether the current descriptor is redundant (just store the current mask similar to the current segment key and then use the current flag together with the mask to decide, whether the descriptor is redundant). If it is indeed redundant, then
a) replace it with the previous repair descriptor, creating two consequent identical repair descriptors and overwriting the bad one
or
b) replace it with the 'empty repair descriptor' which is supposed to be ignored by all repair-tools which might use conv_tab.bin ('empty descriptor' could be all 0x00 or similar).

This would integrate the treatment of redundant descriptors in the tool which creates the conv_tab (debugger) and would allow to keep the repair-tools as simple as possible.

[loo3aem3ON]

Out of curiosity: is the same key that is used for decryption of the content (AACS title key) also used for the signature verification in BD+? If yes, this would violate the good practices of cryptography (don't use the same key-pair for 2 different things). If not: does BD+ comprise some sort of key revocation and renewal scheme?
The virtual machine and it's interface with the player is defined by the BD+ specification. The conversion table is probably covered too. All the keys we currently have can theoretically be revoked but this could cause backward compatibility problems. What i know for sure is that the new firmware of my player contains a new version key (aes key 6) and a new secondary certificate (with a new ECDSA public key).
If we find a way to forge the signature for the certificates then this would have a significant impact on the security of BD+. We would be able to generate our own ECDSA public/private keys and even change the identity of the player we emulate at will. We already have half of the bits of the private key used to sign the certificates but i'm not sure if this is helping us in any way.

Finally one shouldn't speak of "security" as BD+ is not designed to prevent any attacks. Instead it is supposed to slow an attack down to ensure at least 2 weeks pass before the first pirated copies are sold on the streets. This is the time where most of the money is made by selling authentic copies. At least that's what i've read. :rolleyes:

Suggestion about the redundant descriptors:
Thanks but i've already rewritten some code so the conversion table is now rebuilt after decryption without the redundant repair descriptors.

Download: BDVM Debugger v0.1.3 (http://uploaded.to/?id=j4gz5m)

The movie "Jumper" is now correctly handled

Is PrivateKey allowed to differ, or generally should it not?
ECDSA is using a random parameter 'k' so it naturally creates different (r,s) pairs all the time. So yes TRAP_PrivateKey may differ just like TRAP_Random.

[loo3aem3ON]

If not: does BD+ comprise some sort of key revocation and renewal scheme?
A simple revocation scheme could be:
1. call TRAP_DeviceDiscovery to get the player certificates
2. verify the certificates using the LA public key stored in the content code
3. read the player id and version number from the certificates
4. check if the version number is above a certain value. If it is continue decrypting content code specific to this player otherwise halt (call TRAP_Finished and refuse to generate conversion table).

According to the documentation BD+ can employ watermarking techniques so the content code would create a slightly different conversion table for every player. Now it doesn't take much to add up why SlySoft suddenly needs 1-2 months to support new movies. To provide evidence and reveal the marking scheme we need somebody with a different player to present his conversion table. Or i would have to compromise another player.

I see no reason to believe that AACS and BD+ share keys.

[loo3aem3ON]

I thought about the attack on the LA RSA private key. So far i haven't found any proof about the security of RSA schemes with low public exponents but there don't exist any publicly known attacks which make use of a low public exponent. If there exists an efficient algorithm which can find the remaining bits of the private exponent (d) then one could efficiently factor N = p * q which is believed to be hard in general. The only additional information we have compared to the more general problem of prime factorization is that the public exponent e (which an attacker knows) and the product phi(N) = (p-1)(q-1) are coprime (RSA requirement).

Currently 1024-bit numbers (products of two about equal sized primes) can be factored in reasonable time using expensive hardware. A 1280-bit modulus (like ours) is out of reach.

[haggi]

What about http://boinc.berkeley.edu/? Couldn't we just create a software like that to break that key?

Just getting started with crypto stuff, are there some more documents you can recommend? I would really like to try to help you with this!

Some questions on the key(s) used: how many bits does 'd' have and how many are known by the low exponent attack?

Edit: Maybe we should try debian weak keys first. You never know ...

[loo3aem3ON]

What about http://boinc.berkeley.edu/? Couldn't we just create a software like that to break that key?
No way without specialized hardware (asics).

Just getting started with crypto stuff, are there some more documents you can recommend? I would really like to try to help you with this!
That's a good one: link (http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=A33BA4C70978CA934D5726DD122B5CE1?doi=10.1.1.30.8488&rep=rep1&type=pdf). Have a look at fact 3.2 in particular. Btw the introduction in "390ResearchPaper.pdf" (refered to by tteich) is wrong. One n/4 of the least significant bits of d are necessary (not of N).

Some questions on the key(s) used: how many bits does 'd' have and how many are known by the low exponent attack?
About 1280 bits and half of them (the most significant ones) are known.

Edit: Maybe we should try debian weak keys first. You never know ...
I believe it's hopeless and i've tried to explain why in my previous posting. The problem is still hard even if the attacker knows half of the most significant key bits. Remarkably knowing only one quarter of the least significant bits would be sufficient to efficiently compute d and thus factor N. An attacker could obtain these bits from timing or power analysis of the device which creates the signatures.

[haggi]

I believe it's hopeless and i've tried to explain why in my previous posting. The problem is still hard even if the attacker knows half of the most significant key bits. Remarkably knowing only one quarter of the least significant bits would be sufficient to efficiently compute d and thus factor N. An attacker could obtain these bits from timing or power analysis of the device which creates the signatures.

I don't think it's entirely impossible. There should be some way to use the most significant 640 bits of the key to efficiently factorize n ... I'm working on something, but i need to talk to a pal - who studied math in university - to verify my equations. They seem to be a bit too simple to be true.

[qubic]

No way without specialized hardware (asics).




What about Boinc on GPUs? Isn't that possible?

[Accident]

Aahhhh 4 days debugging and it came down to:


result =
trap_Sha(
&vm->addr[ dst & ADDR_MASK4 ], // dst
&vm->addr[ src & ADDR_MASK4 ], // src


Edit:

Still giving wrong results, but I put in a hack to only copy over the bytes (from snapshots) after trap_DiscoveryRAM() and it works, so I just need to fix those memory areas and it is done.

Edit 2:
Current version checked in now produces the correct segment_keys (first 5 at least) but I have not yet dealt with skipping the dummy entries. There are situations that I find strange still, but appears not to matter. There are multiple calls to DiscoveryRAM with src address of 0x0000000. This (should) return the PlayerName. Snapshots confirm this for the first call, but then for following calls, completely different bytes. This is most curious. My code always return the PlayerName.

[haggi]

What about Boinc on GPUs? Isn't that possible?

If we don't find some very optimized attack on the remaining key bits, even gpu power won't help much...

[loo3aem3ON]

I've restructured our documentation (http://uploaded.to/?id=5442g1) so please have a look at the table of contents. We need more people working on this if possible. Fixing grammar/bad English expressions and typos will help too. Has anyone written a description of the conversion table yet? Would you suggest to move the detailed trap descriptions to the appendix?

[loo3aem3ON]

I saw you committed a few updates including a patch to add diffarchive support. I would like to comment on this.
// Locate the correct diff. This is tedious. Why couldn't they have
// made the diffarchive with a index-list of offsets.
A diffarchive snapshot is a stream of patches in which you are not supposed to seek. The diffarchive file is opened only once during your program initialization (startup). Then you are supposed to allocate another 4MB of memory and fill it with zeros. Now you have two 4MB memories. One is updated by the virtual machine and the other (lets call it reference memory) is updated by the patches from the diffarchive stream.
Once this is done you can start the virtual machine and let it run until the first trap. In the meantime (different thread maybe?) you can apply the first chunk of patches to the (zeroed) 4MB reference memory which gives you the memory state after the first trap execution.
Now when the first trap has been executed you compare both 4MB memories and if they should differ you overwrite the virtual machine memory with the reference memory.
After this is done you apply the second chunk of patches to update the reference memory to the state after the second trap execution... and so on.

I believe you made it far to complicated. Have a look at the snapshots.java file and see how simple this actually is if you can afford the extra 4MB of memory. ;)

(the register snapshots are threated the same way)

// Seriosuly who writes files in LE, you can't use any of ntohs() etc calls
If you would like to have big endian/little endian swapped in future diffarchive snapshot packages you can try to convince me to change it. :)

[Accident]

A diffarchive snapshot is a stream of patches in which you are not supposed to seek. The diffarchive file is opened only once during your program initialization (startup). Then you are supposed to allocate


I meant to delete this rant, I wasn't thinking clearly or drunk, one of those two. Of course the differences has to play from the start to get a specific snapshot.




If you would like to have big endian/little endian swapped in future diffarchive snapshot packages you can try to convince me to change it. :)

This one I feel I have some legs to stand on. Since both the OS (since all network is BE), and BD+ itself is BE, we already have functions and support to handle it. But since normal use will not use snapshots, it doesn't matter too much if you can't use them on BE architectures.

But either way, disregard my rantings, they weren't supposed to be checked in, I did so a little bit quickly to have it committed before the end of the weekend. :)


Also, I read your documentation, nicely done.

Edit:

I re-did the cleaning of fake repair descriptors to be done at segment-decrypt time, so they are not in the way for all the functions using conv_tab. I will work on Win32 build today, and all issues that brings. Otherwise, libbluray-0.0.6 should be working with the known titles.

libbluray-0.0.6.tar.gz (http://uploaded.to/?id=3rst84)
If you intend to try it against Jumper, don't forget you need the two shablocks, or the original encrypted 00005.m2ts file.

[haggi]

My math guy doesn't reply ... So I'll post it here. Prove me wrong if you like :devil:

The signature for some data is calculated as follows:
m = c^d mod n
which is the same as
m = c^d - k*n
with k big enough to satisfy m < n where k is some big int

we know m (the signature), n = p*q (where p and q are the primes we want to get in the end) and c (which is obviously needed the check a signature)

but we want to know d
m + k*n = c^d
d = log_c (m + k*n)
the most efficiently calculated log is the log_2 (the int part is the index of the most significant non-zero bit, counting from the LSB side)
d = (log_2 (m + k*n))/(log_2(c))
where log_2(c) has to be calculated only once

some k has to be found to satisfy
| d' - ((log_2 (m + k*n))/(log_2(c))) | <= 2 * square_root( N )

The last operation (the division by log_2(c)) is to be aborted if the some byte returned is different from the known byte in d'. Which is efficiently possible because a division is calculated from the MSB to the LSB and we know the 640(?) most significant bits. For most k it should be sufficient to only use the int part of both the log_2.

I'm looking into some math libs to see if we could make the whole calculation streamable to save even more computation time if k is wrong, which it will be most of the time :rolleyes:

I will add some pseudo code in the evening... Got to go to work now.

[loo3aem3ON]

This one I feel I have some legs to stand on. Since both the OS (since all network is BE), and BD+ itself is BE, we already have functions and support to handle it. But since normal use will not use snapshots, it doesn't matter too much if you can't use them on BE architectures.
I'm thinking about it.

But either way, disregard my rantings, they weren't supposed to be checked in, I did so a little bit quickly to have it committed before the end of the weekend. :)
I sensed frustration so i tried to help. Someone should write a proper documentation about how to use the diffarchive files.

Also, I read your documentation, nicely done.
It's far from finished. I'm trying to attract some volunteers to help me.

Otherwise, libbluray-0.0.6 should be working with the known titles.
Did you fix TRAP_Sha to match the snapshots (for all operations)? If yes, i would like to copy your implementation because the intermediates are still wrong here (debugger). :rolleyes:

@all: Please run some tests with the movies you have and report back with the titles of those Movies which don't work. Thank you.


m = c^d - k*n
with k big enough to satisfy m < n where k is some big int
Let m=2 and c=8. Now try to estimate the number of bits 'k' has if you choose the given public modulus N for 'n' and the approximation d' of the private exponent for 'd'.

My math guy doesn't reply ...
He probably crashed due to a memory overflow. :devil:

For most k it should be sufficient to only use the int part of both the log_2.
It's a calculation over a finite field and i don't think you can just use the floor of the logarithm result. Anyway I didn't think about it in detail because k is too large to store anyway.

My suggestion for you is to experiment on a mini rsa example with small numbers and a public exponent of e = 3. Use maple/mathematica/matlab or whatever you have access to.

[ala42]

[CODE]m + k*n = c^d

First you should estimate the number of digits of c^d and then buy memory, much memory :)

[Accident]

Did you fix TRAP_Sha to match the snapshots (for all operations)? If yes, i would like to copy your implementation because the intermediates are still wrong here (debugger). :rolleyes:


It is not perfect, but it is better than it was before. I don't know how it compares to Debugger though. Generally byte 349 still differs.
(+addr is libbluray, -addr is snapshots)


[dlx] Sha(003DFD8C, 00002E58, 00002000, 00000002 SHA_FINAL
'post_trap_snapshots/post_trap_mem_000973.bin'
+003DFEE0 00 00 00 00 00 00 00 00 00 00 00 00 15 0D EC C7 |................|
-003DFEE0 00 00 00 00 00 00 00 00 00 80 00 00 15 0D EC C7 |................|

[dlx] Sha(003DEB1C, 003DED1C, 00000001, 00000001 SHA_INIT
'post_trap_snapshots/post_trap_mem_003145.bin'
+003DEB30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
-003DEB30 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |a...............|

[dlx] Sha(003DEB1C, 003DED1D, 00000002, 00000002 SHA_FINAL
[bdtest] comparing with 'post_trap_snapshots/post_trap_mem_003146.bin'
+003DEB30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
-003DEB30 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |a...............|
+003DEC70 00 00 00 00 00 00 00 00 00 00 00 00 E1 E1 E1 E1 |................|
-003DEC70 01 00 00 00 00 00 00 00 08 00 00 00 E1 E1 E1 E1 |................|


If one really wanted to, it could be made perfect.

Edit:

I think I have SHA_UPDATE just fine. But SHA_FINAL is harder. It is like they accidentally run one extra turn after final.


+003DEB30 64 63 62 61 68 67 66 65 6C 6B 6A 69 70 6F 6E 00 |dcbahgfelkjipon.|
-003DEB30 64 63 62 61 68 67 66 65 6C 6B 6A 69 6F 6E 6D 00 |dcbahgfelkjionm.|


Edit 2:

Both SHA_UPDATE and SHA_FINAL will process all of Jumper without mismatch. A couple of things are worth noting;
There is sha_ctxt_len set from last update, and then there is the "len" passed to SHA_FINAL. The logic in SHA_FINAL for the reference player leaves "dst" with length from "sha_ctxt_len" only. So "len" is not added on. The bytes left in "dst" are also in "sha_ctxt_len" (without len) in length.

However, this is only true if that length is 44 bytes or less. If longer, it is cleared.

Secondly, OpenSSL's SHA_CTXT after SHA_FINAL, when sha_ctxt_len + len is (a multiple of) "56", is cleared. Which means I do not clear "dst", but leave it untouched.

This makes for some ugly code, and really it isn't required, but it kept me entertained at work. Completely breaks if you change endian.


uint32_t sha_reference(uint8_t *dst, SHA_CTX *sha, uint32_t len,
uint32_t total_len)
{
uint32_t xlen, i;

memcpy(&dst[ 0 ], &sha->h0, sizeof(sha->h0) );
memcpy(&dst[ 4 ], &sha->h1, sizeof(sha->h1) );
memcpy(&dst[ 8 ], &sha->h2, sizeof(sha->h2) );
memcpy(&dst[ 12 ], &sha->h3, sizeof(sha->h3) );
memcpy(&dst[ 16 ], &sha->h4, sizeof(sha->h4) );

// Move all 4 bytes first:
debugf("reference: copying all even 4s from %u\n", len);
i = 0;
xlen = len;
while(xlen >= 4) {
xlen -= 4;
// Refence is big-endian.
memcpy(&dst[ 20+i ], &sha->data[i/4], sizeof(sha->data[0]));
i += 4;
}

debugf("reference: dealing with half-words: %u\n", len-i);

// Deal with the remainder.
switch(len - i) {
case 0:
break;
case 3:
dst[20 + i ] = (sha->data[i/4] & 0xFF00) >> 8;
dst[20 + i + 1] = (sha->data[i/4] & 0xFF0000) >> 16;
dst[20 + i + 2] = (sha->data[i/4] & 0xFF000000) >> 24;
break;
case 2:
dst[20 + i ] = (sha->data[i/4] & 0xFF0000) >> 16;
dst[20 + i + 1] = (sha->data[i/4] & 0xFF000000) >> 24;
break;
case 1:
dst[20 + i] = (sha->data[i/4] & 0xFF000000) >> 24;
break;
}

// Update len field, if needed
if (total_len) {
debugf("reference: updating total size %u\n", total_len);

dst[340] = (uint8_t) ( total_len & 0xFF );
dst[348] = (uint8_t) (( total_len * 8 ) & 0xFF );
dst[349] = (uint8_t) ((( total_len * 8 ) & 0xFF00 ) >> 8 );
}

return 0;
}


..skip skip...

case SHA_UPDATE:
sha_ctxt_len += len;
SHA1_Update(&osha, src, len);
sha_reference(dst, &osha, osha.num, sha_ctxt_len);
break;

case SHA_FINAL:
trap_Sha(dst, src, len, SHA_UPDATE); // Call above UPDATE to add in "len" bytes.
SHA1_Final(digest, &osha);
i = sha_ctxt_len - len; // Compute size before UPDATE added "len".

if (!(sha_ctxt_len%56)) {
memset(&dst[20+i], 0, 352-20-i); // Clear after "i".
sha_reference(dst, &osha, 0, sha_ctxt_len - len);
} else if (i > 44) {
memset(&dst[0], 0, 352); // Clear all
sha_reference(dst, &osha, 0, sha_ctxt_len - len);
i = 0;
} else {
memset(&dst[0], 0, 352); // Clear all, rebuild all.
sha_reference(dst, &osha, i, sha_ctxt_len - len);
}
// Copy over the digest
memcpy(dst, digest, sizeof(digest));
sha_ctxt_len = 0;
break;




It can most likely be further cleaned up if checked against mod 56.

[loo3aem3ON]

It is not perfect, but it is better than it was before.
Thanks.

Prove me wrong if you like :devil:
We will forgive you if you can't tell us the factorization of N or the private exponent. :)
I've studied a few papers and it is still unknown if factoring is more difficult than the rsa problem. There is some evidence that at least for small public exponents like e=3 it might be easier to solve m^(1/3) mod N than factoring N (or equivalently calculating the private exponent d). But currently nobody knows how to do that without the trapdoor 'd'.

A different approach to forge the certificates returned by TRAP_DeviceDiscovery would be to intervene with the subsequent SHA-1 hash calculation or the encryption of the signature part of the certificate. The interesting data paths (data dependencies) for a given content code program can be found among all automatically recorded data dependencies from the certificate.

[xkodi]

what about this paper:

http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

it describes timing attack on RSA:

Our attack exposes the factorization of the RSA modulus. Let N = pq with q < p. We build approximations to q that get progressively closer as the attack proceeds. We call these approximations guesses. We refine our guess by learning bits of q one at a time, from most significant to least. Thus, our attack can be viewed as a binary search for q. After recovering the half-most significant bits of q, we can use Coppersmith’s algorithm [3] to retrieve the complete factorization.

[loo3aem3ON]

it describes timing attack on RSA:
I don't have access to any device that contains the private exponent. If i had one i wouldn't be sitting here writing postings ;)
Those certificates are probably created on a pc without a network connection to rule out any side channel attacks.