Tahoma doesn't help Photoshop 7. Neither our nor the one from MS installed using winetricks. Quite possibly it will help Photoshop CS and CS2 - but I will check that tomorrow.

It should have went to bug #9623

Here's another report with more detail, perhaps:
http://appdb.winehq.org/objectManager.php?sClass=version&iId=2631&iTestingId=16561
"Installation (in version 0.9.46) wouldn't allow me to enter a serial number. I just selected the option to install as a trial version, which worked."

So maybe it's just a UI issue!

Yet another report:
http://appdb.winehq.org/objectManager.php?sClass=version&iId=2631&iTestingId=16371
"[With wine-0.9.46,] when I try to activate it, I get an error saying there isn't enough memory, and the program closes."

So perhaps there are both UI and functionality problems...

There is a UI issue in the installer - the serial number field is disabled. There is a second chance to activate after launching the program - on the trial dialog one can either choose "Continue Trial" or enter the serial. I don't know if the second reporter tried this and it worked?

The problem of the first reporter could be that many of our stubs returns E_OUTOFMEMORY. It would be good to have the console output of that operation.

I've asked both people to write something more about it in this bug.

The patch http://www.winehq.org/pipermail/wine-patches/2007-October/045479.html solves the UI issue - the group box control was consuming the mouse events so it was impossible to focus the edit box using the mouse (it was possible to select it using the Tab key). However as I understand at least in the first report the UI was not the only issue.

I just tried activating it in the program, and after I put the key in and clicked "Activation Options" it put up the error "There is not enough disk space to start your application. Please delete some files from your computer and try again". I have 105 GB free space on this partition...

I couldn't o get a terminal output for it though.

The UI issue is fixed in the latest Git/CVS Wine. Of course the problem that one can't activate it much more important.

It's hard to tell what is going wrong without some logs. My Photoshop Elements 5 CD doesn't use SafeCast (it looks like only the PSE that can be downloaded from the Internet Adobe Store uses it) so I would need logs from the users. I'm a bit uneasy if the Adobe servers won't consider that something strange is happening with this serial number if someone will try to activate it several times under Wine. However from what I've read about this copy-protection technology they only block the on-line activation - there is always an option to activate through the phone if one can explain what happened. But I must warn you that I don't have any experience if that's true.

The general procedure to create a log is:

1. Execute `wineserver -k`
2. If your ~/.wine (i.e. you virtual C: drive) contains some important informations then rename it, if not, delete it
3. Run some program (e.g. wine winecfg) to create a new ~/.wine
4. Install Photoshop (maybe currently without activation - only as a trial)
5. Run Photoshop from the command prompt by executing:
   WINEDEBUG=+msgbox,+seh,+tid wine Photoshop.exe &>output
In the directory ~/.wine/drive_c/Program Files/Adobe/Adobe Photoshop CS2/

6. After the error message appears quit Photoshop and the file "output" will contain the terminal output - that's the file that (maybe after gzip-ing) should be attached to the bug.
7. Execute `wineserver -k`
8. Delete ~/.wine. If you renamed the original ~/.wine to something different rename it back to ~/.wine


This may give some insight what doesn't work. Another log that might be useful is the relay log - in point 5 the command should be "WINEDEBUG=+relay,+seh,+tid wine Photoshop.exe &>output". But that log will be huge (some 5GB) and will take some 20 minutes to generate. To avoid making it even larger you shouldn't close Photoshop, you shouldn't even click 'OK' in the error message box but after the message box appears use Alt-Tab to switch to an (already prepared) console and execute `wineserver -k`. Then use `tail -n 20000 output` to take the 20000 last lines of the output and (after gzip-ing or bzip2-ing it) attach it to this bug.

In the AppDB we have a log of trying to activate Photoshop: http://appdb.winehq.org/commentview.php?iAppId=17&iVersionId=2631&iThreadId=26021 . Unfortunately I don't see anything interesting in it (there is a failed COM object creation failure but that a Windows Image Acquisition that probably doesn't have anything to do with activation).

A relay log might still give some more information.

I've posted a new log with new debug flags in the application database. New logs will be posted here. I hope it helps.

Hello,

I just had a live IRC "debug session" with an Adobe Photoshop CS2 owner - thanks @dergringo for having the patience to follow my instructions ;-).
The activation process fails because CS2 tries to query S.M.A.R.T capabilities of first harddisk and the appropriate device ioctls are not implemented.

To get to this point you have either have to give raw access to harddisk/partition or setup a fake device.
I recommend the latter. See http://bugs.winehq.org/show_bug.cgi?id=8298 how to do this (comment #12 and following)
Basically setup fake data, mount via loop device and symlink "ln -s /dev/loop0 $(WINEPREFIX)/dosdevices/c::"

Relevant log:

--- snip ---
0053:Call KERNEL32.CreateFileA(7d942994 "\\\\.\\c:",c0000000,00000003,00000000,00000003,00000000,00000000) ret=0040398a
0053:Ret  KERNEL32.CreateFileA() retval=0000007c ret=0040398a
0053:Call KERNEL32.DeviceIoControl(0000007c,00074080,00000000,00000000,7d942958,00000018,7d942974,00000000) ret=00403782
0053:fixme:cdrom:CDROM_DeviceIoControl Unsupported IOCTL 74080 (type=7 access=1 func=20 meth=0)
0053:Ret  KERNEL32.DeviceIoControl() retval=00000000 ret=00403782
0053:Call KERNEL32.DeviceIoControl(0000007c,0004100c,7d942974,00000006,7d942778,000000df,7d942968,00000000) ret=004035f7
0053:Ret  KERNEL32.DeviceIoControl() retval=00000000 ret=004035f7
0053:Call KERNEL32.CloseHandle(0000007c) ret=004039ba
0053:Ret  KERNEL32.CloseHandle() retval=00000001 ret=004039ba
--- snip ---

Looking at 0x74080 in "include/winioctl.h":

--- snip ---
190 #define IOCTL_DISK_CONTROLLER_NUMBER    CTL_CODE(IOCTL_DISK_BASE, 0x0011, METHOD_BUFFERED, FILE_ANY_ACCESS)
191 #define SMART_GET_VERSION               CTL_CODE(IOCTL_DISK_BASE, 0x0020, METHOD_BUFFERED, FILE_READ_ACCESS)
192 #define SMART_SEND_DRIVE_COMMAND        CTL_CODE(IOCTL_DISK_BASE, 0x0021, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
193 #define SMART_RCV_DRIVE_DATA            CTL_CODE(IOCTL_DISK_BASE, 0x0022, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
--- snip ---

Some "basic" S.M.A.R.T ioctls have to be implemented/stubbed to get the activation id based apps/games to work.
I know this stuff from copy protections, hell even PunkBuster uses parts of this "id" info for their infamous "hardware" bans.

The standard way is to query drive info using IOCTL_STORAGE_QUERY_PROPERTY.
This gives you volume serial number and the like.
The second way is to query the drive SMART capabilities.
Usually the first check is if the drive supports SMART by calling SMART_GET_VERSION.
If succeeded, SMART is usually enabled with SMART_SEND_DRIVE_COMMAND (code B0) and then the data gets queried with SMART_RCV_DRIVE_DATA.

Regards

Created attachment 8900 [details]
CS2 activation trace snippet showing raw device access and SMART ioctls

Hello,

whoops I forgot to attach the trace snippet, showing the problem.
I took it from the user pastebin output.

If you wonder about the additional "PHYSICALDRIVE1" access...
It tries to open all "\\.\<driveletter>:" | "PHYSICALDRIVE%d" until the first call fails.

Regards

Hey guys, what's up?

Did we have any major changes since I've first pasted that bug here? Any S.M.A.R.T code implementation, even if we got stubs?

Increasing priority

Created attachment 9132 [details]
patch which briefly implements SMART_GET_VERSION and SMART_RCV_DRIVE_DATA

Hello,

Ok, I present two possible ways to work around the problem...

Seems Macrovision provided the code for adobe license manager .. sweet SafeDisc memories *g*
The adobe license manager service uses two methods of gathering hardware data needed to calculate the activation code.

1. S.M.A.R.T interface: SMART_GET_VERSION and SMART_RCV_DRIVE_DATA
2. SCSI interface: IOCTL_SCSI_GET_INQUIRY_DATA and IOCTL_SCSI_PASS_THROUGH

If S.M.A.R.T requests fail it uses the second "fallback" strategy, SCSI.
By using ATA PASS-THROUGH SCSI command it wraps an ATA IDENTIFY DEVICE command to get drive controller data (essentially the same like (1))

Though it seems only drive model and serial number are actually used to derive activation code.

============= RECOMMENDED WAY ================

Using the SCSI ATA PASSTHRU method:

Make your primary harddisk block device (/dev/hda or /dev/sda .. whatever, owned by root) raw accessible to the wine user.
At least: chmod g+rw /dev/hda (sda), if you are in "disk" group.
If not: chmod a+rw /dev/hda (sda).
+r is not enough because the block device is unfortunately opened with default READ_WRITE permissions requested.
Don't be scared .. "write" isn't used at all.

Make the following symlink in .wine/dosdevices: "ln -s /dev/hda c::"

Start Photoshop CS2 and wait for activation dialog. It should now show activation code. Fill in required authorization code to activate your copy.

If successful you can remove the symlink and revoke permissions to hda/sda.

===================================================
Using the SMART method:

DISCLAIMER (just to avoid legal issues arising if people use faking IDENTIFY data for activation purposes): I take no responsibility for any damage to any computer equipment, legal action whatsoever, that arises, directly or indirectly, from the using the patch.

The S.M.A.R.T patch is for educational purposes, presented as base for other people to work on.
The ioctl used for SMART_RCV_DRIVE_DATA, HDIO_DRIVE_CMD + ATA_IDENTIFY_DEVICE currently requires certain permissions (problematic without being root user).
Therefore I implemented a second method, faking the ATA_IDENTIFY_DEVICE data without making an ioctl call to ATA driver.
This has the interesting effect of being completely hardware independent (user can swap harddisks without changing activation code).
This setting is the default one. Needless to say that any modification to fake IDENTIFY data changes activation code.
If you want to play with real ioctl, undefine FAKE_SMART_DISK_IDENTIFY in dlls/ntdll/cdrom.c

The attached patch implements the necessary SMART stuff (either with real and fake ioctl data)

You should have a symlink in .wine/dosdevices: "ln -s /dev/hda c::" in place (for the FAKE_SMART_DISK_IDENTIFY case a symlink to any "harddisk like" block device will be sufficient)

Start Photoshop CS2 and wait for activation dialog. It should now show activation code. Fill in required authorization code to activate your copy.

If successful you can remove the symlink and revoke permissions to hda/sda.

=================

The product activation data is stored in "C:\windows\profiles\All Users\Application Data\Adobe Systems\Product licenses\<xxx>.dat"
If you accidentally removed this file (by wiping out .wine) you need to re-activate using same procedure.

Regards

Sounds like maybe we should use the scsi method,
and add a hack in wine to retry read/write opens 
as readonly opens in some circumstances?
I don't see any other way this could work for
the average user without system changes.

(In reply to comment #17)
> Sounds like maybe we should use the scsi method,
> and add a hack in wine to retry read/write opens 
> as readonly opens in some circumstances?
> I don't see any other way this could work for
> the average user without system changes.

An average user can't have read access to /dev/hda either. We'll have to fake it one way or another.

Hey, I've tested the patch, and I still get the same error. 

(Note: I'm trying to activate an already installed photoshop).

Hello,

--- quote ---
Hey, I've tested the patch, and I still get the same error. 
--- quote ---

Did you only apply the patch?
Sheesh ... if you bothered to read my stuff you would have known there are more steps needed ...

If you see activation error _after_ you created dosdevices "c::" symlink and _after_ you adjusted +rw user permissions to primary harddisk block device you may of course supply +relay,+cdrom trace, showing the activation service opened "\\.\C:" and called certain device ioctls (+cdrom debug channel).

Regards

I'm, sorry, what I got from your message is that chmod a+rw (or chmod g+rw) would only be needed on the first method, so that's why I didn't change my drive permissions. It seems that chmod g+rw does the trick. Thanks.

I'm not very good at using chmod though. Will chmod 0666 restore my drive to its original permissions?

Hello,

--- quote ---
I'm not very good at using chmod though. Will chmod 0666 restore my drive to
its original permissions?
--- quote ---

No.
If you don't know how to use this command (and required parameters) I suggest to either "man chmod" or consult the wikipedia: http://en.wikipedia.org/wiki/Chmod which has examples easily understandable even for novice users.

If you forgot the default permissions look at the other harddisks/partitions by using: "ls -la /dev/sd*" or (/dev/hd*) and adjust permissions accordingly (probably brw-r-----).

Regards

Ok, so that translates to chmod 0660.

Anyway, there are a few caveats I'd like to list here. First is that "Windows version" must be set to Windows XP at winecfg, otherwise that dialog doesn't show, and only Photoshop CS2 will work - Image Ready and Adobe Bridge won't. Maybe I'll file against these two? 

I think it might fly to package up wine with a tiny utility -- 
say, a simple subset of sg_inq -- that is installed setuid root,
and spawn that to retrieve the disk id.  

$ sudo apt-get install sg3-utils
$ sudo sg_inq /dev/hda
ATA device: model, serial number and firmware revision:
  FUJITSU MHT2080AH PL                             NP0TT5325HFY 006C

Whatcha think?  Privilege separation, gotta love it.

(In reply to comment #24)
> I think it might fly to package up wine with a tiny utility -- 
> say, a simple subset of sg_inq -- that is installed setuid root,
> and spawn that to retrieve the disk id.  

You can't just make such a package setuid root, that would defeat the purpose of protecting the id. There would at least need to be a configuration part to enable only trusted users, or we'd have to use sudo and somehow prompt for passwords.

In any case the biggest problem is to first get to the point where we have to return the id. We can't require people to create a fake loop device for this, we need some sort of pseudo-device using an ntoskrnl-style mechanism to handle ioctls.

Is the disk ID really that sensitive?  I think not.
It's just that nobody has bothered to carve out a
hole so that users can read it (and not the other stuff
on the disk, and not modify anything) before.
But I will ask some kernel / security folks what they think.

Unique ids are generally considered security sensitive. For IDE the id is available under /proc/ide/hda/identify, and that's explicitly root-only.

(In reply to comment #26)
> Is the disk ID really that sensitive?  I think not.
> It's just that nobody has bothered to carve out a
> hole so that users can read it (and not the other stuff
> on the disk, and not modify anything) before.
> But I will ask some kernel / security folks what they think.

It does seem to be - I once posted my disk ID in the form that you did above to the Linux Bugzilla and the general response was to mask that when posting any disk utility outputs.

Presumably it stops any forging disks in situations just like activation process.

LKML suggests having wine try to read /proc/ide/sda/identify
and having the user chmod that file if they need to run
these apps.  It's not the worst idea in the world...

OK, one more idea: how about a setuid executable that output
the *hashed* disk id?  Would that address the security concerns?
It would be very difficult to turn that back in to the disk id,
but it would otherwise act and feel like a real disk id.

The security concern is about making a machine uniquely identifiable. It doesn't matter if that's done through the serial number or its hash, the end result is the same.

Hello,

the serial number is usually not enough, most tools collect model and firmware revision from ATA_IDENTIFY_DEVICE too when generating unique id's.

Working around with any "needs root access" devices/tools trickery is just a big waste of time... and waiting for any patches to appear in wine tree too (needs some work, unlikely done in near future).

For the time being, just write a simple NT style kernel driver, which creates "\\.\PHYSICALDRIVE<x>" and/or "\\.\<driveletter>:" device object and handles the few required ioctls.
For the SMART case it would be SMART_GET_VERSION and SMART_RCV_DRIVE_DATA which return/fill in required data.
Make it configurable by using registry when it comes to SERIAL NUMBER, MODEL and other ID sector stuff.
Should be easy.

This should please "private security" concerns and allows licensing stuff independent of any hardware changes.
Actually I like this approach because it defeats the activation id garbage and expresses my reluctance to support software which tries to intrude into user's privacy ;-)

Make this a separate "mini" project whatever, distribute .sys and .inf file to install the driver (or just attach it to bugzilla, adding small howto).
Before running applications which require this disk ID stuff, start the driver and you're done.
No wine patches needed.

Regards

My goal is to support the activation scheme, not defeat it.
I'm trying to stay on the good side of vendors like Adobe.

The app I'm proposing would output the hashed serial
number as well as plaintext versions of the other
required fields.

Hello,

--- quote ---
My goal is to support the activation scheme, not defeat it.
I'm trying to stay on the good side of vendors like Adobe.
--- quote ---

Well, "defeating" was not meant to be taken literally ;-)
"defeating activation" would mean providing a program "keygen" which calculates the correct activation code from product key information (install serial + hardware information).
This is of course not the case.
The user would have to provide a valid product install serial anyway before the hardware id process which generates hashed id code to be transmitted over internet/telephone/email.

From their FAQ:

--- snip ---
The only information required to activate is a 55-digit Product Install ID. The Product Install ID is a combination of the product key and a hardware ID generated from a specific computer's hardware configuration. Product activation uses a hash algorithm to generate the hardware identifier and does not scan the computer’s hard drive or detect any personal information.
--- snip ---

Your hash would be another unique id based off user's harddisk serial data.
Technically this is some kind of cheat too because it does not match the real harddisk controller config data - although it's related/derived somehow.

From the "high level" standpoint it meets activation criteria because it locks the product registration to the user's computer (which is the intention of activation).

Regards

I can be wrong, but I vote for using the fake id. Changing permissions of things like /proc/ide/sda/identify opens yet another security breach, and it's not practical for users to do. We should keep the principle of the least privilege in mind.

Perhaps it would suffice to use the real id if /proc/ide/hda/identify
is readable, and a fake id if it's not.
Thus a user who needs to expose the real id can do
  sudo chmod 444 /proc/ide/hda/identify
(possibly via a helper app).  That will take care of
users who really need to be able to blow away .wine,
reinstall apps, and not have the apps think the disk id changed,
while not complicating the casual user's life.

Created attachment 9729 [details]
ntdll/directory.c: add support for \\.\PHYSICALDRIVE to wine_nt_to_unix_file_name

Did this patch to make 'DiskInternals Linux Recovery' detect all my hard disks, has to be changed from hardcoded to either autodetect or winecfg setting.

*** Bug 10957 has been marked as a duplicate of this bug. ***

As of this morning's git, photoshop cs seems to 
activate for me (it fails when I try it with
an old copy, but that's probably just because it
was already activated on some other system).

we better wait before closing this ;)

Yeah, lets get a few people saying they can
really activate first.

I can confirm that with the latest GIT, phone activation works properly.

Awesome work!

I guess it's safe to mark fixed, then.

Hello,

yes the recent disk device emulation changes (mountmgr) seem to please the adobe license manager (physicaldevice support).

Just not failing too early (opening logical and physical devices) seems to be the culprit.
Though the license manager didn't get any disk related data in the end.
Neither by querying disk controller config data (serial numbers) using SMART device ioctl and SPI SCSI passthrough methods nor by raw physical disk access.

For sake of completeness I post the interesting snippets/requests made by adobe license manager and some explanations...

--- snip ---
0021:Call KERNEL32.CreateFileA(6145291c "\\\\.\\c:",80000000,00000003,00000000,00000003,00000000,00000000) ret=0040341b
0021:Ret  KERNEL32.CreateFileA() retval=0000005c ret=0040341b
0021:Call KERNEL32.DeviceIoControl(0000005c,002d1080,00000000,00000000,61452910,0000000c,61452930,00000000) ret=0040343b
0021:trace:cdrom:CDROM_DeviceIoControl 0x5c IOCTL_STORAGE_GET_DEVICE_NUMBER (nil) 0 0x61452910 12 0x61452820 
0021:Ret  KERNEL32.DeviceIoControl() retval=00000001 ret=0040343b 
--- snip ---

First it uses IOCTL_STORAGE_GET_DEVICE_NUMBER query to get physical drive number from logical device (and DeviceType == FILE_DEVICE_DISK), which is later used for "\\\\.\\PhysicalDrive%d" stuff.

--- snip ---
0022:Call KERNEL32.CreateFileA(61562984 "\\\\.\\c:",c0000000,00000003,00000000,00000003,00000000,00000000) ret=0040398a
0022:Ret  KERNEL32.CreateFileA() retval=000000c0 ret=0040398a
0022:Call KERNEL32.DeviceIoControl(000000c0,00074080,00000000,00000000,61562948,00000018,61562964,00000000) ret=00403782
0022:trace:cdrom:CDROM_DeviceIoControl 0xc0 IOCTL_CODE_74080 (nil) 0 0x61562948 24 0x61561c30
0022:Ret  KERNEL32.DeviceIoControl() retval=00000000 ret=00403782
0022:Call KERNEL32.DeviceIoControl(000000c0,0004100c,61562964,00000006,61562768,000000df,61562958,00000000) ret=004035f7
0022:trace:cdrom:CDROM_DeviceIoControl 0xc0 IOCTL_SCSI_GET_INQUIRY_DATA 0x61562964 6 0x61562768 223 0x61562670
0022:Ret  KERNEL32.DeviceIoControl() retval=00000000 ret=004035f7
0022:Call KERNEL32.CloseHandle(000000c0) ret=004039ba
0022:Ret  KERNEL32.CloseHandle() retval=00000001 ret=004039ba 
--- snip ---

Standard S.M.A.R.T device ioctl and SPI SCSI passthrough methods fail.

--- snip ---
0022:Call KERNEL32.CreateFileA(61562918 "\\\\.\\PHYSICALDRIVE0",c0000000,00000003,00000000,00000003,00000080,00000000) ret=004012fd
0022:Ret  KERNEL32.CreateFileA() retval=00000080 ret=004012fd
0022:Call KERNEL32.DeviceIoControl(00000080,00070000,00000000,00000000,61562954,00000018,61562944,00000000) ret=00401343
0022:trace:cdrom:CDROM_DeviceIoControl 0x80 IOCTL_CODE_70000 (nil) 0 0x61562954 24 0x61562850
0022:Ret  KERNEL32.DeviceIoControl() retval=00000001 ret=00401343
0022:Call ntdll.RtlAllocateHeap(00530000,00000000,00000230) ret=00404b77
0022:Ret  ntdll.RtlAllocateHeap() retval=00532f78 ret=00404b77
0022:Call KERNEL32.SetFilePointer(00000080,00000000,61562904,00000000) ret=004013db
0022:Ret  KERNEL32.SetFilePointer() retval=ffffffff ret=004013db
0022:Call KERNEL32.CloseHandle(00000080) ret=00401274
0022:Ret  KERNEL32.CloseHandle() retval=00000001 ret=00401274 
--- snip ---

Raw physical disk device open and certain ioctls now work due to recent changes.
It queries disk device geometry by using IOCTL_DISK_GET_DRIVE_GEOMETRY ioctl (which returns fake data).
The rather interesting aspect of this snippet is that the license manager tries to seek the physical disk device which obviously fails and it doesn't seem to harm.
lDistLow = lDistHigh = 0;
SetFilePointer( hPhysDisk, lDistLow, &lDistHigh, FILE_BEGIN); 

The seek was in preparation to read physical sector (MBR) from disk.
Yes, and there is actually code which writes physical sector to disk - which might succeed in windows.
Looks like some signature into unused MBR area. Bad guys.
Though I wonder how that stuff mixes with common windows antivirus products which usually detect alterations to MBR ;-)

Anyway, the issue seemed to have worked out well for linux.

Regards

could somebody please explain in more simple terms, how i can use this patch?

could somebody please explain in more simple terms, how i can use this patch?


this is what i get if i run it in terminal 

~$ sudo '/media/hda2/nefile' 
diff: unrecognized option `--git'
diff: Try `diff --help' for more information.
/media/hda2/nefile: 2: index: not found
/media/hda2/nefile: 3: ---: not found
/media/hda2/nefile: 4: +++: not found
/media/hda2/nefile: 5: Syntax error: "(" unexpected

nishyl, this bug is fixed, and besides, this is not a support forum.  Closing.

nishyl, just use wine-0.9.54 as described at
http://wiki.winehq.org/AdobePhotoshop
It already supports photoshop cs and cs2 activation.http://wiki.winehq.org/AdobePhotoshop

ok thanks, i did not check the version of wine that got installed thru synaptic, i just heard the news that cs2 was now installable thru wine and decided to give it a shot. worked perfectly on the new version. another lesson learnt about ubuntu..