Analyzing Alcohol 120% DPM

[reentrant]

Which 4 byte enumeration?

[Nemok]

Which 4 byte enumeration?

The DPM sample itself I guess.

Code: Select all

DPM sample     value     timing

1C 05 00 00    1308
38 0A 00 00    2616      1308
53 0F 00 00    3923      1307
6E 14 00 00    5230      1307
88 19 00 00    6536      1306
A2 1E 00 00    7842      1306
BB 23 00 00    9147      1305
D4 28 00 00    10452     1305
ED 2D 00 00    11757     1305
05 33 00 00    13061     1304
1D 38 00 00    14365     1304

sarami,
If I rely on the values you were getting in 2020, the sampling seems to be wrong in the first place :

Code: Select all

value ?        timing ?

154.500100
154.566300     0,0662
154.758100     0,1918
154.850500     0,0924
154.853000     0,0025
155.114800     0,2618
155.013000     −0,1018
155.249500     0,2365
155.350000     0,1005
155.493100     0,1431
155.512100     0,019
155.672400     0,1603
155.690200     0,0178
155.774200     0,084
156.011200     0,237
156.051600     0,0404
156.179200     0,1276
156.326700     0,1475
156.385200     0,0585
156.486800     0,1016

These timings look inconsistent. I would be curious to see if they also vary across multiple dumps though (same disc, same drive, same settings).

[sarami]

The DPM sample itself I guess.

Ah, yes. I don't know yet how A120% outputs these values.

These timings look inconsistent.

Yes. It's a research phase and useless.

[Nemok]

About reverse engineering, I'm not sure that the alcohol application is the best candidate to start from. I've only recently discovered that the old .bwa file format used by Blindwrite back in 2002 was in fact storing DPM information the exact same way than the very latest Alcohol 120% version released in 2023.

The thing is that those .bwa files were created by a much smaller dedicated stand-alone program called BWA builder. Since smaller probably also means it's simpler, it might be more interesting to analyze it with Bus Hound, or even to decompile it.

[reentrant]

This is used by BWA Builder in the driver: https://learn.microsoft.com/en-us/windo … ncecounter

ULONGLONG performanceFrequency = 0;
ULONGLONG performanceCounter = KeQueryPerformanceCounter(&performanceFrequency);
ULONGLONG ticksMicroSeconds = 1000000 * performanceCounter / performanceFrequency;

I guess on APP side (before DeviceIoControl is made to ASPI driver) the same value is calculated (QueryPerformanceCounter / QueryPerformanceFrequency) and substracted after the call.

There's no driver in DIC but I think it can be emulated purely in user mode just by (QueryPerformanceCounter / QueryPerformanceFrequency) and slow read speed.

[sarami]

ULONGLONG performanceFrequency = 0;
ULONGLONG performanceCounter = KeQueryPerformanceCounter(&performanceFrequency);
ULONGLONG ticksMicroSeconds = 1000000 * performanceCounter / performanceFrequency;

I implemented the following in a test version(/viewtopic.php?p=41293#p41293).

Code: Select all

    LARGE_INTEGER freq = {}, current = {}, end = {};
    QueryPerformanceFrequency(&freq);
    double time = 0;

    QueryPerformanceCounter(&current);
    (Read the CD multiple times)
    QueryPerformanceCounter(&end);
    time = static_cast<double>(end.QuadPart - current.QuadPart) * 1000 / static_cast<double>(freq.QuadPart);

[Nemok]

Wish I could help you, but for now that's beyond my understanding.

All I know is that BWA builder had an alleged precision of about 6 µs.

[Nemok]

I did a bit of testing with different time stamp functions. It seems that after simply iterating a printf in a for loop, clock(), QueryPerformanceCounter() in Windows, and clock_gettime() in Linux give extremely close results when CLOCK_PROCESS_CPUTIME_ID is used.

If that behavior is consistent in any situation, which needs to be checked, I find it even harder to understand how one would achieve the task of measuring DPM with these functions, unless the I/O latency is deduced, because they try to assess the same thing, that is the CPU time spent on a process, while the time NOT spent by the CPU is required for DPM (as I see it).

I wonder if calculating the difference between clock_gettime(CLOCK_MONOTONIC) and clock_gettime(CLOCK_PROCESS_CPUTIME_ID) is enough to approximate the drive's latency variations.

[Nemok]

I have added a graphical representation of the timings in DPM SCN. Simply drag and drop a mds file on 'scan' and press Escape key to close the window. A corresponding .bmp file will be created, along with a .log file that contains the stats and all DPM values in a human readable format.

Linux : https://github.com/jonblau/dpmscn/relea … _64.tar.gz
Windows : https://github.com/jonblau/dpmscn/relea … x86_64.zip

For example, a SecuROM 7 disc (https://redump.info/disc/105429/) :
- timings in red
- timing variations in blue

[reentrant]

Looks nice, could you write something more?