XboxHacker BBS
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
June 20, 2013, 03:30:39 AM


Login with username, password and session length


Pages: 1
  Print  
Author Topic: How does the TS-943A determine an orginal is inserted?  (Read 3873 times)
BlueCop
Master Hacker
****
Posts: 316


"When the going gets weird, the weird turn pro."


View Profile
« on: May 09, 2006, 06:50:37 AM »

I testing to see if backups i made for commodore4evas firmware would work with a 360 drive.

I started by patching 36B0 from 00FD021E to 00F9FA00 to read the SS at PSN $F9FA00 instead of $FD021E

next step was to patch where it thinks an orginal is inserted. i think this takes place somewhere 348B-34F9 and tried patching various places to try to force it to read the security sector. some patches broke the SS reading all together.

i have had 2 test discs. my orginal halo 2 disc and the copy i made for commodore4evas firmware.

i took the lid off where i could see the laser movement.

I won't go through all the patches i have tried but there is a jump to 35f0 that begins reading the security sector that i try to get executed with backup discs without success. at least i don't see the laser move to read the SS like it does when i insert my orginal halo 2. i know the orginal will only play the video when inserted because it doesn't have the SS at the PSN its reading.

I have heard multiply times that xbox 1 doesn't use the security placeholders. is this true for the 360 with xbox 1 games? i didn't know if other checks were possible but not implemented in the orginal xbox.

I have heard conflicting data from xt5 and TheSpecialist about how commodore4eva handles the SS in the samsung firmware and the absense of CPR_MAI. while xt5 says that what commodore4eva firmware dumps and uses is just the orginal sector data. Someone else mentioned that he might be reading the SS and redoing it for a CPR_MAI that is all 0s.

So does anyone know which is correct?  if i can actually get the drive to think my burn is an orginal will it even boot?

Thanks for any help.
Logged
Boris
Newbie
*
Posts: 3


View Profile
« Reply #1 on: May 09, 2006, 07:29:23 AM »

I'm trying to  mod my 8050l firmware that's a bit similar to 360's Hitachi firmware. I've some problems with the routine that check the control data block, Could someone give me some hint?                                                          Sorry for my bad english. Thank you.
« Last Edit: May 09, 2006, 07:31:35 AM by Boris » Logged
BlueCop
Master Hacker
****
Posts: 316


"When the going gets weird, the weird turn pro."


View Profile
« Reply #2 on: May 09, 2006, 07:33:45 AM »

that is a totally different drive and controller then what i am working with.

I am using the Toshiba-Samsung drive. NOT the hitachi.
Logged
Boris
Newbie
*
Posts: 3


View Profile
« Reply #3 on: May 09, 2006, 07:59:59 AM »

I know i know. I've posted here only because the argument was similar.  Grin
Logged
xt5
Hacker
***
Posts: 61


View Profile
« Reply #4 on: May 09, 2006, 11:04:42 AM »

I have heard conflicting data from xt5 and TheSpecialist about how commodore4eva handles the SS in the samsung firmware and the absense of CPR_MAI. while xt5 says that what commodore4eva firmware dumps and uses is just the orginal sector data. Someone else mentioned that he might be reading the SS and redoing it for a CPR_MAI that is all 0s.

about CPR_MAI, at least on XBOX1 (I have don't see any 360 stuff yeat as I don't have one yet):

CPR_MAI is not required at all, CPR_MAI (4 bytes of 6) is the challenge part of changelles type 1, there are many parts where you can get it:
  - writing it somewhere in the disc
  - when are send to the drive with MODE SELECT
  - from the challenge response table
  - having the tables scrambled, do a kind of bruteforce. bruteforce a CPR_MAI is very fast, there are a lot of method to get it even in a non exponencial way  Wink.

for XBOX stuff I have only played with 8050L, and to do clear hack is need to reescramble the SS, dunno what method use commodore4eva to handle SP stuff or if he simply ignore it (that would work without any problem), ignoring them at all is not problem to unlock the disk, but we are hackers and like to know how thinks works, don't you?.

in the 8050L when you read the "unlocked game partiton" the firm read through the SP PSNs list and skips if is in range.

for compatibility with Hitachi drives I suggest ppl writing the SS also  in a sector finished with 0xE (ie: $F9FA00->$F9FA0E), beacose the hitachi drive read an entire DVD block (16 sectors) to the memory to get SS from, and if you put the SS in a sector other than 0xE, you need to patch a lot and the hack will be very crap.
« Last Edit: May 09, 2006, 11:11:26 AM by xt5 » Logged
Zenofex
Member
**
Posts: 18


View Profile WWW
« Reply #5 on: May 09, 2006, 07:38:34 PM »

next step was to patch where it thinks an orginal is inserted. i think this takes place somewhere 348B-34F9 and tried patching various places to try to force it to read the security sector. some patches broke the SS reading all together.

I know weve talked about this before but, What patches did you do to "force" the reading of the SS?

thanks -Zenofex-
Logged

---------------------------------------------------------------------------
Check out my website http://www.gtvhacker.com/
BlueCop
Master Hacker
****
Posts: 316


"When the going gets weird, the weird turn pro."


View Profile
« Reply #6 on: May 09, 2006, 08:23:30 PM »


I know weve talked about this before but, What patches did you do to "force" the reading of the SS?

thanks -Zenofex-
It won't really matter because the patches didn't work but i tell you what i tried. I don't know much about asm
Code:
X34ed:
jb 21h.5,X34f3 ; 34ed   20 0d 03   
ljmp X35f0 ; 34f0   02 35 f0   
;
X34f3:
jb 23h.1,X34f9 ; 34f3   20 19 03
ljmp X376f ; 34f6   02 37 6f   

If 23h.5 bit is not set then it jumps to X35F0 because it thinks and orginal disc is inserted. The SS is reading further down at 36ad.

i tried noping out this jb so it would always jump to 35F0. that didn't work when i tested my copy. when i tested with my orginal halo 2 it would attempt to read the security sector still so it wasn't geting executed with a copy inserted.

someone told me the jump to 376f is the normal read dvd struct.

Code:
X34c8:
clr 23h.1 ; 34c8   c2 19
setb 21h.5 ; 34ca   d2 0d
mov r6,#82h ; 34cc   7e 82
mov r7,#8ah ; 34ce   7f 8a
lcall Xd9f6 ; 34d0   12 d9 f6
mov 38h,r7 ; 34d3   8f 38
mov a,38h ; 34d5   e5 38
anl a,#60h ; 34d7   54 60
jz X34ed ; 34d9   60 12
setb 23h.1 ; 34db   d2 19
mov a,38h ; 34dd   e5 38
jnb acc.4,X34e8 ; 34df   30 e4 06
clr 21h.5 ; 34e2   c2 0d
mov r7,#83h ; 34e4   7f 83
sjmp X34ea ; 34e6   80 02
;
X34e8:
mov r7,#82h ; 34e8   7f 82     
X34ea:
lcall X096b ; 34ea   12 09 6b
I tried lots of patches in this code. i tried playing with 21h.5. None of which worked. with a few patches it would break the reading of a ss from an orginal this makes me think i am in the right spot but not patching the right stuff because i don't really understand what all is going on. i can understand the execution but not the reasoning.

above that at 348b is the code that executes when a disc is inserted.
Code:
X348b:
mov r5,#0 ; 348b   7d 00
mov r6,#8 ; 348d   7e 08
mov r7,#88h ; 348f   7f 88
lcall Xd915 ; 3491   12 d9 15
mov r5,#0 ; 3494   7d 00
mov r6,#8 ; 3496   7e 08
mov r7,#89h ; 3498   7f 89
lcall Xd915 ; 349a   12 d9 15
mov r5,#0 ; 349d   7d 00
mov r6,#8 ; 349f   7e 08
mov r7,#8ah ; 34a1   7f 8a
lcall Xd915 ; 34a3   12 d9 15
mov r5,#0 ; 34a6   7d 00
mov r6,#8 ; 34a8   7e 08
mov r7,#8bh ; 34aa   7f 8b
lcall Xd915 ; 34ac   12 d9 15
mov r6,#82h ; 34af   7e 82
mov r7,#98h ; 34b1   7f 98
lcall Xd9f6 ; 34b3   12 d9 f6
mov a,r7 ; 34b6   ef
jnb acc.7,X34c8 ; 34b7   30 e7 0e
mov r0,#1ah ; 34ba   78 1a
mov a,@r0 ; 34bc   e6
mov r7,a ; 34bd   ff
swap a ; 34be   c4
anl a,#0fh ; 34bf   54 0f
xrl a,#1 ; 34c1   64 01
jz X34c8 ; 34c3   60 03
lcall X095c ; 34c5   12 09 5c

I am going to look at it closer but any help is appreciated thanks.
Logged
n8thegr8
Member
**
Posts: 32


View Profile
« Reply #7 on: May 10, 2006, 12:43:03 PM »

sorry for the noob question bluecop, but what are you using to reassemble your firmware for testing? and also, if using dis8051, I always get a bunch of unresovled address references down at the bottom, can those be ignored? I'm dissassembling each bank individually, so I'm guessing these are references to part of the other banks that will be fixed when I put them all back together and reassemble? I really wanna get started with working on this firmware, but need to be pointed in the right direction, thanx!
« Last Edit: May 10, 2006, 12:48:06 PM by n8thegr8 » Logged
BlueCop
Master Hacker
****
Posts: 316


"When the going gets weird, the weird turn pro."


View Profile
« Reply #8 on: May 10, 2006, 03:58:23 PM »

i am not using an assembler. I am patching by hand.
« Last Edit: May 10, 2006, 04:12:47 PM by BlueCop » Logged
n8thegr8
Member
**
Posts: 32


View Profile
« Reply #9 on: May 10, 2006, 07:13:04 PM »

ah, lol, thanks then, not quite sure how one would go about doing that, but I'll search some more before bein too much of a noob
Logged
BlueCop
Master Hacker
****
Posts: 316


"When the going gets weird, the weird turn pro."


View Profile
« Reply #10 on: May 10, 2006, 07:42:55 PM »

well most of the patches i am trying at really simple.

I have been using dis51 which will also include the offset and hex values after the disassembled code. as you can see above.

i am using the instruction set at http://www.8052.com/set8051.phtml
if you look at each instruction it contains the hex value and format for the opcode.

like if i wanted to patch a jz(jump if a=0) which hex value is 60 to a unconditional sjmp i could just patch the 60 to 80. the relative address of the jump is still that same. hope thats helps. I am an amateur. i am sure some other ways might be easier
Logged
n8thegr8
Member
**
Posts: 32


View Profile
« Reply #11 on: May 10, 2006, 09:56:24 PM »

thanks man, actually, that sounds like a lot better Idea than what I was tryin to do, sweet, I'll look into this
Logged
Pages: 1
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM