LimHD:DVDCSS - Revision history

Lundman at 02:00, 25 September 2007

2007-09-25T02:00:06Z

← Older revision		Revision as of 02:00, 25 September 2007
Line 191:		Line 191:
	err = RUACreateInstance(&pRUA, play_opt->chip_num);		err = RUACreateInstance(&pRUA, play_opt->chip_num);
	err = DCCOpen(pRUA, &pDCC);		err = DCCOpen(pRUA, &pDCC);
	err = DCCInitMicroCodeEx(pDCC, DCCInitMode_InitDisplay); /*~~DCCInitMode_L~~		err = DCCInitMicroCodeEx(pDCC, DCCInitMode_InitDisplay); /DCCInitMode_LeaveDisplay/
	~~eaveDisplay~~*/

	// open & connect Demux and DemuxProgramId.		// open & connect Demux and DemuxProgramId.

Lundman at 01:57, 25 September 2007

2007-09-25T01:57:36Z

← Older revision		Revision as of 01:57, 25 September 2007
Line 175:		Line 175:

	Should we fiddle with the moduleIndex though? Using '''1''' crashes less than using '''0'''.		Should we fiddle with the moduleIndex though? Using '''1''' crashes less than using '''0'''.

			Nearly all examples using module '''DemuxTask''' uses it like this:

			RMuint32 demux_task = EMHWLIB_MODULE(DemuxTask, EMHWLIB_MODULE_INDEX(demux));

			EMHWLIB_MODULE_INDEX(RMuint32 ModuleID) { return (ModuleID >> 8) & 0xff; }


			Which it seems to get from:

			Tasks[i].Spi = FALSE;
			Tasks[i].SourceType = SourceType_dvd;
			Tasks[i].Id = i;
			Tasks[i].dcc_info = &dcc_info;
			err = RUACreateInstance(&pRUA, play_opt->chip_num);
			err = DCCOpen(pRUA, &pDCC);
			err = DCCInitMicroCodeEx(pDCC, DCCInitMode_InitDisplay); /*DCCInitMode_L
			eaveDisplay*/

			// open & connect Demux and DemuxProgramId.
			demux_profile.BitstreamFIFOSize = Tasks[i].Spi ? 0:DEMUX_FIFO_SIZE;
			demux_profile.XferFIFOCount = Tasks[i].Spi ? 0:DEMUX_XFER_FIFO_COUNT;
			demux_profile.DemuxID = Tasks[i].Id;
			demux_profile.DemuxProgram0 = i;
			demux_profile.DemuxProgram1 = 0xff;


			err = DCCOpenDemuxSource(pDCC, &demux_profile, &pDemuxSource);
			dcc_info.pDemuxSource = pDemuxSource;

			err = DCCGetDemuxSourceInfo(pDemuxSource, &(dcc_info.demux), &(dcc_info.demuxProgram0), &(dcc_info.demuxProgram1));


			This I do not know about. So clearly there should be a specific value to be used. I'm hoping it is hard-coded/stable enough that I can use a static between firmwares, but it is also possible it is assigned dynamically it order of codecs loaded, or similar.

Lundman at 01:40, 25 September 2007

2007-09-25T01:40:42Z

← Older revision		Revision as of 01:40, 25 September 2007
Line 170:		Line 170:
	If I just call '''get_CSSchlgkey1''' it just hangs. But perhaps I should call '''set_CSSkey1''' first.		If I just call '''get_CSSchlgkey1''' it just hangs. But perhaps I should call '''set_CSSkey1''' first.

	'''set_CSSkey1''' is at: '''0x1822''' or 6178. It is in '''EMhwlibSetDemuxTaskProperty''' this time. This is at index 485 in EMhwlibVtable.		'''set_CSSkey1''' is at: '''0x1822''' or 6178. It is in '''EMhwlibSetDemuxTaskProperty''' this time. This is at index 485 in EMhwlibVtable. However, '''EMhwlibSetDemuxTaskProperty''' loads the address of '''EMhwLibVtable + 4''', which would call Set method instead of Get, with the same moduleId of '''44'''.

			The '''ioctl''' call is different. Set is '''1''', Get is '''2'''.

			Should we fiddle with the moduleIndex though? Using '''1''' crashes less than using '''0'''.

Lundman at 01:17, 25 September 2007

2007-09-25T01:17:15Z

← Older revision		Revision as of 01:17, 25 September 2007
Line 168:		Line 168:
	Which makes me think that '''44''' is a better bet. Now it also uses bits 8-16 for index, and 24-16 as moduleTarget. No idea what they are. Many of the samples use '''0''' for index.		Which makes me think that '''44''' is a better bet. Now it also uses bits 8-16 for index, and 24-16 as moduleTarget. No idea what they are. Many of the samples use '''0''' for index.

	If I just call '''get_CSSchlgkey1''' ~~I get all zeros back~~. But perhaps I should call '''set_CSSkey1''' first.		If I just call '''get_CSSchlgkey1''' it just hangs. But perhaps I should call '''set_CSSkey1''' first.

			'''set_CSSkey1''' is at: '''0x1822''' or 6178. It is in '''EMhwlibSetDemuxTaskProperty''' this time. This is at index 485 in EMhwlibVtable.

Lundman at 01:09, 25 September 2007

2007-09-25T01:09:57Z

@@ Line 108: / Line 108: @@
 '''. Although, that could be wrong?
-  .text:0002A014                 LDR     R3, =0x177B
+  loc_15144
- .text:0002A018                 CMP     R12, R3
+      LDR     R3, =0x1821
-  .text:0002A01C                 BEQ     loc_2A12C
+      CMP     R12, R3
-  .text:0002A020                 ADD     R3, R3, #0x6C
+      BEQ     loc_15314     ; getCSSchglkey1
-  .text:0002A024                 CMP     R12, R3
+      BHI     loc_15164     ; test for 0x1824
-  .text:0002A028                 BEQ     loc_2A08C      ; getCSSchglkey1
-  .text:00001778 dword_1778      DCD 0xE1A00005          ; DATA XREF: EMhwlibGetDispHardwareCursorProperty:off_98AC�o
+So, propId is '''0x1812''' or 6177.
-  .text:00001770  02 21 A0 E1 7C 20 82 E2  '''05 00 A0 E1''' 04 11 81 E0  �!áß| éG�.áß��üa

Lundman at 00:20, 25 September 2007

2007-09-25T00:20:17Z

← Older revision		Revision as of 00:20, 25 September 2007
Line 104:		Line 104:

	Ok, what it comes down to is me authenticating the drive, which lets me play the files. They are not unscrambled so that is why they appear blocky. My loading of CSStitlekey is failing, 99% sure it is due to me not knowing what '''moduleId''' to use.		Ok, what it comes down to is me authenticating the drive, which lets me play the files. They are not unscrambled so that is why they appear blocky. My loading of CSStitlekey is failing, 99% sure it is due to me not knowing what '''moduleId''' to use.

			Looking at the assembler inside of '''em8xxx.o''' it seems clear that '''get_CSSchlgkey1''' call is propId of '''
			6177'''. Although, that could be wrong?

			.text:0002A014 LDR R3, =0x177B
			.text:0002A018 CMP R12, R3
			.text:0002A01C BEQ loc_2A12C
			.text:0002A020 ADD R3, R3, #0x6C
			.text:0002A024 CMP R12, R3
			.text:0002A028 BEQ loc_2A08C ; getCSSchglkey1
			.text:00001778 dword_1778 DCD 0xE1A00005 ; DATA XREF: EMhwlibGetDispHardwareCursorProperty:off_98AC�o
			.text:00001770 02 21 A0 E1 7C 20 82 E2 '''05 00 A0 E1''' 04 11 81 E0 �!áß\| éG�.áß��üa

Lundman at 01:38, 21 September 2007

2007-09-21T01:38:22Z

← Older revision		Revision as of 01:38, 21 September 2007
Line 101:		Line 101:

	But ultimately, if a title changes key in the middle, we have no way to succeed.		But ultimately, if a title changes key in the middle, we have no way to succeed.


			Ok, what it comes down to is me authenticating the drive, which lets me play the files. They are not unscrambled so that is why they appear blocky. My loading of CSStitlekey is failing, 99% sure it is due to me not knowing what '''moduleId''' to use.

Lundman at 23:59, 19 September 2007

2007-09-19T23:59:45Z

← Older revision		Revision as of 23:59, 19 September 2007
Line 95:		Line 95:

	Minor success. Using moduleId of '''9''' make it do "something". It loads both disckey and titlekey without crashing. Then when I try to play that vts_02_1.vob file it actually starts to play. First frame is perfect. However, play is very jerky (stop/start) and have a lot of macroblocks / corruption. I am used to the video being all "green" when it's encrypted so I am not sure what to think.		Minor success. Using moduleId of '''9''' make it do "something". It loads both disckey and titlekey without crashing. Then when I try to play that vts_02_1.vob file it actually starts to play. First frame is perfect. However, play is very jerky (stop/start) and have a lot of macroblocks / corruption. I am used to the video being all "green" when it's encrypted so I am not sure what to think.

			My current train of thought is that the DVDRom that I have will not let me read the data without first authenticating with the drive. With all my hacks, I must have eventually done so, which enabled LimHD to attempt to play the DVD. The jerks and corruption could be failure to descramble the blocks, but not all blocks are scrambled.

			I am thinking I should call all the ewhlib functions to authenticate the drive now.

			But ultimately, if a title changes key in the middle, we have no way to succeed.

Lundman at 12:53, 19 September 2007

2007-09-19T12:53:29Z

← Older revision		Revision as of 12:53, 19 September 2007
Line 91:		Line 91:

	and then it hangs. Quite peculiar. ioctl actually returns, and successfully at that. And yet the machine dies before the program can exit.		and then it hangs. Quite peculiar. ioctl actually returns, and successfully at that. And yet the machine dies before the program can exit.



			Minor success. Using moduleId of '''9''' make it do "something". It loads both disckey and titlekey without crashing. Then when I try to play that vts_02_1.vob file it actually starts to play. First frame is perfect. However, play is very jerky (stop/start) and have a lot of macroblocks / corruption. I am used to the video being all "green" when it's encrypted so I am not sure what to think.

Lundman at 11:13, 19 September 2007

2007-09-19T11:13:54Z

← Older revision		Revision as of 11:13, 19 September 2007
Line 81:		Line 81:
	block internal state. This is required when a context switch occurs while a DVD sector is		block internal state. This is required when a context switch occurs while a DVD sector is
	only partially processed.		only partially processed.


			I grabbed a disc and title key from a known disk, wrote a program to issue the '''ioctl''' to set the keys, setting moduleId to 0 (what should it be I wonder?) but unfortunately:

			uclibc[/tmp]# ./2dvd_em8xxx /dev/em8xxx0 1
			./2dvd_em8xxx: Patch Disc and Title keys into em8xxx.o
			1' ...
			set_CSStitlekey says 0

			and then it hangs. Quite peculiar. ioctl actually returns, and successfully at that. And yet the machine dies before the program can exit.