PDA

View Full Version : D-T Log OR CD-Rom activity monitor?



badilator
27.09.2004, 17:35
Operating System: na
Burning Software: na
Anti-virus Software: na
DAEMON Tools Version: na

I need a way to log wich sectors are read from a cd for debugging pourposes, so i thought that perhaps D-T may have the option to write down its activity.
I can make an image of the cd and mount it in D-T, that's not a problem.

If D-T does not have a log, is there a tool that can track/log/monitor what sectors are accessed on a cd-rom drive?

Thank you very much.

Development
27.09.2004, 22:13
Yes, you can use BusHound or BusTrace.

badilator
28.09.2004, 13:36
Thank you very much, that was what i was looking. Only bushound has a trial version, so i tried it.
Starting a game protected with safedisc i've monitored this access to the alchol image i've done and mounted with D-T.



Device Phase Data Description Cmd.Phase.Ofs(rep)
------ ----- -------------------------------------------------- ---------------- ------------------
5 CMD 00 00 00 00 00 00 TEST UNIT READY 1.1.0
5 SENSE 70 00 06 00 00 00 00 0a unit attention 1.2.0
5 CMD 00 00 00 00 00 00 TEST UNIT READY 2.1.0
5 OK 2.2.0
5 CMD 43 02 00 00 00 00 00 03 READ TOC/PMA 3.1.0
5 IN 00 12 01 01 00 14 01 00 ........ 3.2.0
5 CMD 43 00 00 00 00 00 00 03 READ TOC/PMA 4.1.0
5 IN 00 0a 01 01 00 14 01 00 ........ 4.2.0
5 CMD 28 00 00 00 00 10 00 00 READ 5.1.0
5 IN 01 43 44 30 30 31 01 00 .CD001.. 5.2.0
5 CMD 28 00 00 00 00 10 00 00 READ 6.1.0
5 IN 01 43 44 30 30 31 01 00 .CD001.. 6.2.0
5 CMD 28 00 00 00 00 11 00 00 READ 7.1.0
5 IN 01 43 44 30 30 31 01 00 .CD001.. 7.2.0
5 CMD 28 00 00 00 00 12 00 00 READ 8.1.0
5 IN 02 43 44 30 30 31 01 00 .CD001.. 8.2.0
5 CMD 00 00 00 00 00 00 TEST UNIT READY 9.1.0
5 OK 9.2.0
5 CMD 00 00 00 00 00 00 TEST UNIT READY 10.1.0
5 OK 10.2.0
5 CMD 00 00 00 00 00 00 TEST UNIT READY 11.1.0
5 OK 11.2.0
5 CMD 00 00 00 00 00 00 TEST UNIT READY 12.1.0
5 OK 12.2.0
5 CMD 00 00 00 00 00 00 TEST UNIT READY 13.1.0
5 OK 13.2.0
5 CMD 00 00 00 00 00 00 TEST UNIT READY 14.1.0
5 OK 14.2.0
5 CMD 12 00 00 00 38 00 INQUIRY 15.1.0
5 IN 05 80 02 02 20 00 00 10 .... ... 15.2.0
5 CMD 00 00 00 00 00 00 TEST UNIT READY 16.1.0
5 OK 16.2.0
5 CMD 00 00 00 00 00 00 TEST UNIT READY 17.1.0
5 OK 17.2.0
5 CMD 00 00 00 00 00 00 TEST UNIT READY 18.1.0
5 OK 18.2.0
5 CMD 5a 08 2a 00 00 00 00 08 MODE SENSE 19.1.0
5 IN 00 20 00 00 00 00 00 00 . ...... 19.2.0
5 CMD 00 00 00 00 00 00 TEST UNIT READY 20.1.0
5 OK 20.2.0

I think that the 4k trial limited buffer now is full and more data is accessed,
but for now i looked into the image (.mdf) and found the four accessed consecutive sectors, I guess...


00009300h: 00 FF FF FF FF FF FF FF FF FF FF 00 00 02 16 01 ; .яяяяяяяяяя.....
00009310h: 01 43 44 30 30 31 01 00 20 20 20 20 20 20 20 20 ; .CD001..

00009c30h: 00 FF FF FF FF FF FF FF FF FF FF 00 00 02 17 01 ; .яяяяяяяяяя.....
00009c40h: 01 43 44 30 30 31 01 00 20 20 20 20 20 20 20 20 ; .CD001..

0000a560h: 00 FF FF FF FF FF FF FF FF FF FF 00 00 02 18 01 ; .яяяяяяяяяя.....
0000a570h: 02 43 44 30 30 31 01 00 00 20 00 20 00 20 00 20 ; .CD001... . . .

0000ae90h: 00 FF FF FF FF FF FF FF FF FF FF 00 00 02 19 01 ; .яяяяяяяяяя.....
0000aea0h: FF 43 44 30 30 31 01 00 00 00 00 00 00 00 00 00 ; яCD001..........

QESTION1) I'm not able to relate the 4 CMD READ command (28 00 00 00 00 [10/10/11/12] 00 00) to the indexing of the image.
Well, at least there is the case that the byte before the last one of each first line is a decimal counter of the sector and the previous bytes are a sort of multiplier starting from 02 at the begining of the image... so the hexadecimal [10/10/11/12] in the CMD are referring in some way to sectors [16/16/17/18] but with no indication of the multiplier byte [02]. Can you give me a tip on this?


Then i tried to look forward, I idendified sectors of repetitive patterns, when they ended i left some blank sectors (they seems to be needed) and cut the .mdf image.
So i have a pair of a mds/mdf file with the mdf cut just after 2 MB (instead of 700 MB).

Mounting those file let the game start like the original and like the full image.

Before I said that "4k trial limited buffer now is full" becase there is a lot of sectors between dhe CD001 sectors and the cut that are needed or the game crush before starting. So probably i can't get the full list of sectors accessed due to the trial limitation, but this is a guess, I really do not know what i m doing... by the way the cropped image works if the cut is after the sector :


00243f60h: 00 FF FF FF FF FF FF FF FF FF FF 00 00 15 35 01 ; .яяяяяяяяяя...5.
(perhaps even some sectors earlier but not many)


CONCLUSION1:
Spending 800 or 1100 $ for a tool just for seeing wich sectors are accessed is not an option, do you know of any other tool?

CONCLUSION2:
I was wandering if an option could be implemented in D-T to dump to file wich sectors are read.
Someting like a "start/stop logging". In that way everyone, even me, can make a log parser, look for the highest sector, and crop the image just to hold the game launching sequence of bytes.
(One of the main use of D-T, in my opinion, is to run your original game without bothering looking for the cd, so I think that the option to store on the hd only what is really needed goes well with the D-T idea)

If that could be done with a plug-in, i could try to look into it, even if I have no experience in ring0/device programming.
If you have some sort of sdk/plug in template/source code of other plug in let me know.

I think that game jack does something like this, but hey, with D-T you could do it better and cheaper.

Do you think all this is crap? Or should be moved in features request forum?

In any case, thank you for D-T, is a great tool.

LocutusofBorg
01.10.2004, 16:47
we think about your suggestion. Maybe we implement such function for
one of the later releases. For further discussion you can also mail us directly
(venom386@daemon-tools.cc or locutus@daemon-tools.cc)