86 replies to this topic

[DanP2]

Yep. I encountered this problem with my AutoIt-App too when it is supposed to be started by Windows shell. The catch is: ShellExecute doesn't wait for the application's message loop to run but tries to connect to DDE server as soon as the PID of the app becomes valid.

The Clarion app also had a message loop, so this doesn't completely make sense, unless it is just a timing issue.

I'll take another look at this tomorrow.

Thx, Dan

[doudou]

The Clarion app also had a message loop, so this doesn't completely make sense, unless it is just a timing issue.

No idea what Clarion is

Well, it does not matter. What matters is WHEN DdeNameService() is called to register your server: the only chance in AutoIt to execute anything BEFORE message loop is from within of OnAutoItStart(), unfortunately this is also the very first code interpreted in the script, so NOTHING from the global scope is yet performed not even Const declarations, this fact busts all chances to use a UDF (like DDEML) here. After OnAutoItStart() exists CreateProcess() returns a valid PID to ShellExecute() and it assumes that the connection to the DDE server has failed.

FireFox suffers the very same problem: if it is configured with 'ddeexec' in the registry and no instance of it is yet running the shell would always show an error message on opening a URL or HTML file.

[DanP2]

Well, it does not matter. What matters is WHEN DdeNameService() is called to register your server: the only chance in AutoIt to execute anything BEFORE message loop is from within of OnAutoItStart(), unfortunately this is also the very first code interpreted in the script, so NOTHING from the global scope is yet performed not even Const declarations, this fact busts all chances to use a UDF (like DDEML) here. After OnAutoItStart() exists CreateProcess() returns a valid PID to ShellExecute() and it assumes that the connection to the DDE server has failed.

Here's my solution, which allows you to use a single application:

• In the OnAutoItStart function, add the registry keys for DDE support
• In the OnAutoItExit function, remove the registry keys for DDE support

The initial request gets passed in as a parameter; All others are handled via DDE.

HTH, Dan

[doudou]

Here's my solution, which allows you to use a single application:

• In the OnAutoItStart function, add the registry keys for DDE support
• In the OnAutoItExit function, remove the registry keys for DDE support

The initial request gets passed in as a parameter; All others are handled via DDE.

I didn't say that the work-around with 2 EXEs is the best possible way, so if the registry manipulation satisfies you better then go ahead with that.

Please consider though that your solution bear several caveats:

1. On most mashines a normal user wouldn't be authorized to write to HKEY_CLASSES_ROOT
2. Windows reacts allergically if you try to do something like this with reg keys for, say, HTTP URL protocol
3. You risk leaving registry messed up in case your program terminates abnormally and therefore OnAutoItExit() doesn't get executed
4. It is very difficult to handle if the user decides to run many instances of your prog simultaneously (f.i. by selecting multiple files in Explorer and pressing 'enter')

[doudou]

Although as of 1.4 release one can use the UDF from within OnAutoItStart(), a work-around for ShellExecute() + ddeexec must be applied in server application anyway due to late message loop creation in AutoIt.

[toyotabedzrock]

Is there a restriction in Vista that would make a Client running with normal permissions unable to see a Server running under the same user account, but the Server has full admin permissions(like after the UAC prompt)?

I will try to explain it a different way.

I added a DDE Server into my Admin Tray app. Then i created a small client that takes input from the command line and sends it to the server then it exits. --This works if both are not run with elevated permissions.

When I run Admin Tray with elevated permissions\ high integrity in Vista, the small client app can't connect to the DDE server with its normal integrity level.

Yet it works fine if both are running with elevated Permissions\ high integrity. They also work fine when both are run with medium integrity

So is there a setting i can change to make it so the server in my app can accept data from a client running a lower integrity lever than itself?


Thanks in advance for your help

Edited by toyotabedzrock, 08 January 2008 - 12:18 AM.

[toyotabedzrock]

Anyone? I looked at all the MSDN articles and there isn't very much, if any documentation on security permissions with DDEML.

[doudou]

Is there a restriction in Vista that would make a Client running with normal permissions unable to see a Server running under the same user account, but the Server has full admin permissions(like after the UAC prompt)?

I will try to explain it a different way.

I added a DDE Server into my Admin Tray app. Then i created a small client that takes input from the command line and sends it to the server then it exits. --This works if both are not run with elevated permissions.

When I run Admin Tray with elevated permissions\ high integrity in Vista, the small client app can't connect to the DDE server with its normal integrity level.

Yet it works fine if both are running with elevated Permissions\ high integrity. They also work fine when both are run with medium integrity

So is there a setting i can change to make it so the server in my app can accept data from a client running a lower integrity lever than itself?

There's a very good reason why a lower privileged process CANNOT and SHOULD NOT control an other one running with higher privileges. One of few things MS did right in Vista was to cut off ALL interprocess communication between different security contexts, there's still a way to allow this through changing the ACL of the executable, I strongly recommend however not to. The better way would be to elevate permissions of the client on per case/user basis: the client should always ask if it is allowed to perform administrative task then raise then its security level.

Edited by doudou, 08 January 2008 - 10:09 AM.

[toyotabedzrock]

There's a very good reason why a lower privileged process CANNOT and SHOULD NOT control an other one running with higher privileges. One of few things MS did right in Vista was to cut off ALL interprocess communication between different security contexts, there's still a way to allow this through changing the ACL of the executable, I strongly recommend however not to. The better way would be to elevate permissions of the client on per case/user basis: the client should always ask if it is allowed to perform administrative task then raise then its security level.

Wouldn't changing the ACL just cause the client to always trigger the UAC prompt? And assuming it doesn't trigger the UAC my next question would be is there a way to make sure the server will only accept a connection from just my client?

[doudou]

Wouldn't changing the ACL just cause the client to always trigger the UAC prompt?

Well, this is point, isn't it? A process can communicate only to one with equal or lower integrity level, so we need to elevate it in the client. And this causes the UAC nagging in Vista. Alternatively you could try to lower the level in the ACL of your server, what implications it would lead to - no idea (some functions may fail...).

And assuming it doesn't trigger the UAC my next question would be is there a way to make sure the server will only accept a connection from just my client?

How are you going to assure this? And more important - why?

By silently sending commands from normal user context to a program running with administrative rights you introduce a severe security threat to your system but what is on the profit side? I can't imagine any case one would need this.

[toyotabedzrock]

How are you going to assure this? And more important - why?

By silently sending commands from normal user context to a program running with administrative rights you introduce a severe security threat to your system but what is on the profit side? I can't imagine any case one would need this.

I was asking if windows provides a way to stop just any client from connecting to the server. If i understand what i read on MSDN is that calling _DdeNameService advertises the server to every other process on the system. What i don't want is for some random possibly malicious program to take advantage of something i wrote.

[doudou]

I was asking if windows provides a way to stop just any client from connecting to the server. If i understand what i read on MSDN is that calling _DdeNameService advertises the server to every other process on the system. What i don't want is for some random possibly malicious program to take advantage of something i wrote.

It is correct, the service is registered globally but it just does not respond to requests from less privileged context - Vista blocks this. It's exactly like the case with window messages: you can see windows of administrator's processes in the window list but you are not allowed to send messages to them as normal user. The reason for the restriction is named by you yourself: we don't want someone to abuse this mechanism.

Neither message queues nor DDE (which is internally handled by the windows message dispatcher) provide authentication challenge to distinguish 'good' from 'bad' clients, so the only possibility is to program it manually in the server.

The question is still, why would you want to do something like this? Why should a none-administrator call any functions within a privileged process not providing appropriate credentials (f.i. via UAC)?

[toyotabedzrock]

It is correct, the service is registered globally but it just does not respond to requests from less privileged context - Vista blocks this. It's exactly like the case with window messages: you can see windows of administrator's processes in the window list but you are not allowed to send messages to them as normal user. The reason for the restriction is named by you yourself: we don't want someone to abuse this mechanism.

Neither message queues nor DDE (which is internally handled by the windows message dispatcher) provide authentication challenge to distinguish 'good' from 'bad' clients, so the only possibility is to program it manually in the server.

The question is still, why would you want to do something like this? Why should a none-administrator call any functions within a privileged process not providing appropriate credentials (f.i. via UAC)?

The whole point of the program i wrote so far is to assist admins who are using various programs that require they have "actual administrator privileges" instead of normal admin privileges that you get when you have UAC enabled.

Let me ask this then. Is there anyway to tell my process written in autoit that it should check something without adding another check into the Gui message loop? My concern is that doing so would cause a performance drain on the system. And i had wanted to move away from using checks in the message loop and goto using onevent for everything.

Random windoz security rants removed from main body of the response-

Now of course some people disable UAC, problem is that you lose the extra layer of protection that Vista provides for IE7, and any random program can have its way with your system then as well. UAC is a good idea but perhaps Microsoft should protect the DDE servers it uses for critical windows functions.

In reality if someone is able to get a process they programed running on your system with full admin privileges, restricting a non admin process running under the same user account is not going to help you one bit.

Also the secure desktop cripples systems that have several monitors, for instance my system has dual Xeon 5130 chips overclocked to 2.33GHZ with a 1552Mhz FSB 2gb ram and 2 XFX7600GT video cards and it takes it 3+ times longer to display the UAC prompt than a system with half the ram, a Pentium D935, and a cheap 7300 card.

I think there isn't going to be any real security until every process has its own virtual workspace, and they decide to rewrite the api's available to programs installed on a system to reject any input that is even slightly incorrect. And i don't mean they need to make a wrapper for what they already have. Sorry microsoft you need to bite the bullet and start from scratch, and stop using the code from win2000 its obvious the guy who programed the original functions left you no usable comments since you can't seem to fix all the problems your having.

[Goldesel]

I have a question to this great script. i hope this is the right place to ask.

_DdeInitialize("OnDDE_", $APPCLASS_STANDARD)

$hszService = _DdeCreateStringHandle("MT4")
$hszTopic = _DdeCreateStringHandle("QUOTE")
$hConvSrv = _DdeConnect($hszService, $hszTopic)
;then I start the advise request
$hszItem = _DdeCreateStringHandle("EURUSD")
$res = _DdeClientTransaction($XTYP_ADVSTART+$XTYPF_ACKREQ, $hConvSrv, 0, 10000, $hszItem, $CF_TEXT)ƒo݊÷ Û^ëÞ¬ŠîžØ^–)ÞjëhŠ×6$res = _DdeClientTransaction($XTYP_REQUEST, $hConvSrv, 0, 10000, $hszItem, $CF_TEXT)
$res_b = _DdeGetDataAsString($res)
GUICtrlSetData($lab_info,$res_B)ƒo݊÷ ÙëÞ¯+aŠx0¢¹,~)Þ!ƧëfÈ6­j)ÚÂ¥zZ(¦Šð…«^½êÛºÛajÛ'¢Ü!jÒ0j{^tˆî²ÜžÛh™©¶¬­ê®zËp…éÞ½êí…ë®÷«±¬ªº‹G{'nuè ¢ÙÞÁÖ­iú+ʋªº‹HžØ^±È­yÊ'²‰^ŠÆ°¶­¶ƒuàš–VÚrGîËb¢x¬q©eyÜ!zw¯z»azÇ«½êìzwlu«ZŒjrº)]jw¯z{ajwez¸§k²–)¶¬jëhŠ×6Func OnDDE_DdeCallback($szTopic, $szCommand, $hConv)
    $res = _DdeClientTransaction($XTYP_REQUEST, $hConvSrv, 0, 10000, $hszItem, $CF_TEXT)
    $res_b = _DdeGetDataAsString($res)
    GUICtrlSetData($lab_info,$res_B)
    Return 0
EndFunc

would be nice if somebody could help me

[DieMaiers]

Since we use standard DDE it should be as well usable across network. The keyword here is NetDDE - if it is properly configured there's no difference to local connections from client's or server's point of view.

Hello,
can you give me simple example how to get it work over the network?

Tanks Tom

[doudou]

I have a question to this great script. i hope this is the right place to ask.

_DdeInitialize("OnDDE_", $APPCLASS_STANDARD)

$hszService = _DdeCreateStringHandle("MT4")
$hszTopic = _DdeCreateStringHandle("QUOTE")
$hConvSrv = _DdeConnect($hszService, $hszTopic)
;then I start the advise request
$hszItem = _DdeCreateStringHandle("EURUSD")
$res = _DdeClientTransaction($XTYP_ADVSTART+$XTYPF_ACKREQ, $hConvSrv, 0, 10000, $hszItem, $CF_TEXT)
$res = _DdeClientTransaction($XTYP_REQUEST, $hConvSrv, 0, 10000, $hszItem, $CF_TEXT)
$res_b = _DdeGetDataAsString($res)
GUICtrlSetData($lab_info,$res_B)ƒo݊÷ Ø÷«²‰Ú–ˆÂ‹¥všÞ}ê݊·œ¶·ª¹ë-¦‰¢·±yË­zg­†‡l†Œ½êâ~Ø^­íý±§!¢'jÀçoŠÇ¥¢Šlj·¦¢Ë¢je{§uê뢻žÈ­Š÷ªº‹^©ž

would be nice if somebody could help me

This won't work. To catch a callback just define function with the prefix you chose in _DdeInitialize() and the name of callback you expect to come, f.i. 'OnDDE_AdvData', for complete list of possible callback names s. _DdeCallback() in DDEML.au3.

[doudou]

Hello,
can you give me simple example how to get it work over the network?

Tanks Tom

There's a little prog from Windows shipping package called 'DDE Share Manager' (ddeshare.exe) which you can use to share your DDE server over network. Client side connection - as said - should not differ from normal use with a local server. Further reading: MSDN, keywords - NetDDE, DDE share.

[ian.b]

@doudou - thank you for this

I have tried to make a simple Gui (with a label having data from a file) to work as a DDE Server for the Excel (client) - without success.

Is it possible at all? - if yes, i would appreciate some advice.

Best Regards
ian

[Kenming]

Hello doudou:

I downloaded au3_ddeml_v1.4.zip and au3_ddeml_samples.zip, But I can't execute the examples within the samples.

Can you give a simple and clear sample code ? Thanks!

[Kenming]

Hello doudou:

If I had set a excel's cell which value is "=YES|DQ!'&TWTK1.Price'" , It can update the DDE data souce.

How Can I write the same code by autoit and DDEML ?