My problem is about WinApi clipboard formats. The scenario is:
Service application enumerates processes and looks for my application. If it's not found it will spawn process with winlogon.exe duplicated token from user session to act as system.
Each time clipboard has been updated application is enumerating formats. It works for CF_TEXT, CF_UNICODE, etc... But I need CF_HDROP - it's missing. It always have 49161 IDataObject with no formats inside.
If I try to run application manually from user context it detects CF_HDROP.
Where did I go wrong?
The user token integrity level is an answer.
This is why some clipboard formats were missing.
Related
I'm having trouble with my own AppleScript applications and Accessibility in "Security & Privacy".
I've written an application called "open cubase" that I've granted accessibility rights. I used Apple's advice on how to prevent repeated re-authorization (http://support.apple.com/kb/HT5914). But now even when the application is listed and selected in the Accessibility list, it says that it doesn't have assistive access.
And when I'm using
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/Tcc.db 'SELECT * FROM access WHERE client LIKE "%%"'
to check what's going on, I can see this:
kTCCServiceAccessibility|com.atonus.open-cubase|0|1|0|??
Why is there ?? at the end of that? Is there anyone who would know how to resolve this?
I'm using OSX 10.9.2.
Update, based on feedback from the OP:
The OP's issue is not the use of property statements that normally cause an AppleScript-based application to self-modify the application bundle's embedded Contents/Resources/Scripts/main.scpt script file when property values change at runtime.
However, Apple's workaround at http://support.apple.com/kb/HT5914
IS specifically meant to address not requiring re-authorization as a result of this self-modification issue for a given version of an application.
is NOT meant to allow updating the app (changing its source code or resources) without re-authorization.
For security reasons there is NO way to grant one-time authorization to an app based on its bundle ID and then keep it authorized no matter how it changes (e.g., through updates).
You have two options:
Either: Re-authorize the application every time you update it.
After updating your app, go to System Preferences > Security & Privacy > Privacy > Accessibility and toggle the checkmark next to the list item representing your application (if you application isn't there, drag it there).
Note: With Apple's workaround in place - which for security reasons is NOT a good idea unless you truly need to use property statements that persist their values - it may be sufficient to re-sign the application - haven't verified that.
Or: Use a workaround - not recommended for security reasons:
Make your app an unchanging wrapper that loads the true script code at runtime from a location OUTSIDE the app bundle - that way, the app stays the same and doesn't require re-authorization even if the script file loaded at runtime changes.
Example: Say your true script code - involving code requiring assistive access - is stored as ~/Desktop.test.scpt; your wrapper application, once authorized, can then invoke that script with run script file ((path to home folder as text) & "Desktop:test.scpt")
I don't have a specific explanation, but a recommendation:
Do not use properties (e.g., property FNAME : "Input.txt") in your AppleScript-based applications: AppleScript persists these automatically (preserves their values between runs), but the feature is implemented awkwardly (the persisted values are written to the *.scpt file itself - this is what causes the repeated authorization problem) and flimsily (if you modify your application and save (the *.scpt file at the heart of the) application again, previously persistent values are lost).
If you stay away from properties, the problem with repeated authorization simply goes away (unless you update your application). You can roll your own persistence, e.g., via AppleScript's support for .plist (property-list) files (see the System Events dictionary).
You also won't need the workaround described in the linked support article (http://support.apple.com/kb/HT5914), which is also a plus, given that the workaround is based on opening up a security hole.
As for your specific question:
The ?? is the - unhelpful - representation of the csreq columnn value from the TCC.db database and is not a problem per se; OSX manages that column behind the scenes; it contains a fingerprint of sorts identifying the application in its specific current form (similar to an MD5 hash, though I have no idea what is actually being used), so as to be able to detect tampering later.
However, I suspect you may be looking at the wrong database entry:
I'm puzzled by your bundle ID being com.atonus.open-cubase: if your app is an AppleScript-based *.app bundle, its bundle ID would have the fixed prefix com.apple.ScriptEditor.id., e.g., com.apple.ScriptEditor.id.open-cubase. Did you manually modify the bundle ID via the bundle's Info.plist file, or am I missing something?
When the OS determines tampering/a change in an authorized application:
It resets the allowed column value to 0, i.e., revokes authorization
It resets the csreq column value to NULL.
Thus, after you've seen the ... is not allowed assistive access dialog, the database entry should be reported as kTCCServiceAccessibility|com.atonus.open-cubase|0|0|1| - note the changed Boolean flags and the absence of the ?? at the end.
I have read this post and I had little success with the given answer. It said to
use WTSEnumerateSessions to find the right desktop
but all I got was the station name in the WTS_SESSION_INFO struct. The names I saw (e.g. "console", "service") were nothing like the station/desktop names like "Winsta0\default". The answer proceed to state
then CreateProcessAsUser to start the application on that desktop (you pass it the handle of the desktop as part of the STARTUPINFO structure)
I don't think it's referring to a HANDLE variable for the desktop since STARTUPINFO has no members for that. What I think it's referring to is the lpDesktop member which allows you to specify the station/desktop name. Using names returned by WTSEnumerateSessions failed to launch any visible UI, whereas "Winsta0\default" did.
What did I do wrong?
Just tried WTSEnumerateSessions on Windows Seven: my user session (session 1) is named "Console".
I have a launcher app that starts another app. For the other App to play nicely with Windows 7's taskbars, I have to set the Application User Model ID.
Usually a process has to set this id for itself, by calling SetCurrentProcessExplicitAppUserModelID(), but in this specific case I do not have control about the other apps startup code, so I have to set this externally, at best by using some kind of ShellExecute which passes the ID to the app.
Is this possible?
Windows will auto generate a id for the process if it does not call SetCurrentProcessExplicitAppUserModelID, this should be enough for the recent files jumplist section.
If you for whatever reason really want to set a specific id for a 3rd party app, I would try one of these (I have not tried any of these suggestions)
use SHGetPropertyStoreForWindow on the apps window (I have never tried to set the id like this, but I know you can read the id of another process this way)
Create a temporary shortcut that launches the app with a specific id
Inject into the process and call SetCurrentProcessExplicitAppUserModelID
I'm looking for a way to dump (export) the contents of an OS X keychain into a file that I can easily process elsewhere, such as tab-delimited plaintext or something of the sort.
The Keychain Access app does not offer any such functionality, and getting a key's data involves opening each in turn, and having to type in the keychain's password to see the password stored with the key, every time.
After a bit of digging, I found somebody's solution by using AppleScript and the Keychain Scripting app to access keychains (can't link to individual post; scroll down about two thirds to the end of the page):
http://discussions.apple.com/thread.jspa?threadID=1398759
Using Keychain scripting, you can access all data fields of all the keys – including the plaintext password! – and it's fairly easy to dump this data into a text file etc. I've tested it and it works well.
However, this solution still involves having to confirm access to each key by clicking OK on a dialog. This is much better than having to type in the keychain's password every time, but it's still irritating. Furthermore, you have to confirm access twice for each key; once for Script Editor (or the script itself if it's running as an app) and once for Keychain Scripting. So, if you're processing a keychain with 100 keys, you have to manually click OK on 200 dialogs.
I'm now looking for a solution to get around this. I realize that as it's the purpose of keychains to safeguard the sensitive data and prevent precisely the kind of thing I'm trying to do, any such solution would probably involve some kind of hack.
I'd be very interested in your ideas!
Allright, I'm stupid. There's a command-line tool called security that does just this (and lots of other actions on keychains).
An example usage:
security dump-keychain -d login.keychain
This will dump all the data in the login.keychain (the default keychain for a user) as plaintext, including the passwords. You still have to confirm access , but only once for each key, and it's much faster than (and doesn't throw weird errors when trying to access certain fields) using AppleScript. And it's no hack.
Without the -d option, it will dump all the fields except for the password.
The dumped data for a key looks like this (for an internet key; program keys and certificates have other fields, but the format is the same):
keychain: "/Users/<username>/Library/Keychains/login.keychain"
class: "inet"
attributes:
0x00000007 <blob>="tech.slashdot.org (<username for this web login>)"
0x00000008 <blob>=<NULL>
"acct"<blob>="<username for this web login>"
"atyp"<blob>="form"
"cdat"<timedate>=0x32303038303432333038323730355A00 "20080423082705Z\000"
"crtr"<uint32>=<NULL>
"cusi"<sint32>=<NULL>
"desc"<blob>="Kennwort des Web-Formulars"
"icmt"<blob>="default"
"invi"<sint32>=<NULL>
"mdat"<timedate>=0x32303038303432333038323730355A00 "20080423082705Z\000"
"nega"<sint32>=<NULL>
"path"<blob>=<NULL>
"port"<uint32>=0x00000000
"prot"<blob>=<NULL>
"ptcl"<uint32>="http"
"scrp"<sint32>=<NULL>
"sdmn"<blob>=<NULL>
"srvr"<blob>="tech.slashdot.org"
"type"<uint32>=<NULL>
data:
"<the plaintext password for this key>"
Please read this: https://gist.github.com/rmondello/b933231b1fcc83a7db0b
Ignore:-----
I found a sollution to the "Always Allow" dialog in each key!
Just run the previous command with sudo.
sudo security dump-keychain -d login.keychain
This way you'll only need to enter your password two times. One on the Terminal to sudo and another to unlock the keychain! ;)
Have a nice day!
Update, there is now a tool that does this nicely:
Keychaindump is a proof-of-concept tool for reading OS X keychain passwords as root. It hunts for unlocked keychain master keys located in the memory space of the securityd process, and uses them to decrypt keychain files.
Source: https://github.com/juuso/keychaindump
Actually I was just looking for the same:
Modified applescript from github somebody posted. To be run in ScriptEditor and must be allowed in Preferences & Security.
set keychainPassword to "yourpasswordgoeshere"
tell application "System Events"
repeat while exists (processes where name is "SecurityAgent")
tell process "SecurityAgent"
delay 0.1
try
set value of text field 1 of window 1 to keychainPassword
click button "Allow" of window 1
end try
end tell
end repeat
end tell
You must click each window separetly in order to activate them. For that I used tool "murgaa auto clicker" I had known from runescape many years ago (http://www.murgaa.com/auto-clicker-mac/ seems still active). You just set shortcut for autoclicking (eg. Command+R) and set timer to 10ms and it works like charm.
Keysafe
Keysafe reads and decrypts Apple Keychain files. Use Keysafe to securely access your passwords and credentials without a Mac.
I wrote a tool called Keysafe to extract the contents of Keychain files. The tool is available on Mac, Windows, and Linux.
Keysafe is not free; a licence is required to fully decrypt a Keychain. Without a licence the contents are still extracted but the decrypted values are partially redacted and secure notes are not post-processed into RTFD files.
If you have a Keychain that does not "just work" with Keysafe, please get in touch. The Keychain format is expansive and finding edge cases is always interesting.
I found solution for not clicking "Allow" multiple times
sudo su
security dump-keychain -d /Users/YourUsername/Library/Keychains/login.keychain
I used to be able to launch a locally installed helper application by registering a given mime-type in the Windows registry. This enabled me to allow users to be able to click once on a link to the current install of our internal browser application. This worked fine in Internet Explorer 5 (most of the time) and Firefox but now does not work in Internet Explorer 7.
The filename passed to my shell/open/command is not the full physical path to the downloaded install package. The path parameter I am handed by IE is
"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\
EIPortal_DEV_2_0_5_4[1].expd"
This unfortunately does not resolve to the physical file when calling FileExists() or when attempting to create a TFileStream object.
The physical path is missing the Internet Explorer hidden caching sub-directory for Temporary Internet Files of "Content.IE5\ALBKHO3Q" whose absolute path would be expressed as
"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\
Content.IE5\ALBKHO3Q\EIPortal_DEV_2_0_5_4[1].expd"
Yes, the sub-directories are randomly generated by IE and that should not be a concern so long as IE passes the full path to my helper application, which it unfortunately is not doing.
Installation of the mime helper application is not a concern. It is installed/updated by a global login script for all 10,000+ users worldwide. The mime helper is only invoked when the user clicks on an internal web page with a link to an installation of our Desktop browser application. That install is served back with a mime-type of "application/x-expeditors". The registration of the ".expd" / "application/x-expeditors" mime-type looks like this.
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.expd]
#="ExpeditorsInstaller"
"Content Type"="application/x-expeditors"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller]
"EditFlags"=hex:00,00,01,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell\open]
#=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell\open\command]
#="\"C:\\projects\\desktop2\\WebInstaller\\WebInstaller.exe\" \"%1\""
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MIME\Database\Content Type\application/x-expeditors]
"Extension"=".expd"
I had considered enumerating all of a user's IE cache entries but I would be concerned with how long it may take to examine them all or that I may end up finding an older cache entry before the current entry I am looking for. However, the bracketed filename suffix "[n]" may be the unique key.
I have tried wininet method GetUrlCacheEntryInfo but that requires the URL, not the virtual path handed over by IE.
My hope is that there is a Shell function that given a virtual path will hand back the physical path.
I believe the sub-directories created by IE are randomly generated, so you won't be able guarantee that it will be named the same every time, and the problem I see with the registry method is that it only works when the file is still in the cache...emptying the cache would purge the file requiring yet another installation.
Would it not be better to install this helper into application data?
I'm not sure about this but perhaps this may lead you in the right direction: try using URL cache functions from the wininet DLL: FindFirstUrlCacheEntry, FindNextUrlCacheEntry, FindCloseUrlCache for enumeration and when you locate an entry whose local file name matches the given path maybe you can use RetrieveUrlCacheEntryFile to retrieve the file.
I am using a similar system with the X-Appl browser to display WAML web applications and it works perfectly. Maybe you should have a look at how they managed to do it.
It looks like iexplore is passing the shell namespace "name" of the file rather than the filesystem name.
I dont think there is a documented way to be passed a shell item id on the command line - explorer does it to itself, but there are marshaling considerations as shell item ids are (pointers to) binary data structures that are only valid in a single process.
What I might try doing is:
1. Call SHGetDesktopFolder which will return the root IShellFolder object of the shell namespace.
2. Call the IShellFolder::ParseDisplayName to turn the name you are given back into a shell item id list.
3. Try the IShellFolder::GetDisplayNameOF with the SHGDN_FORPARSING flag - which, frankly, feels like w'eve just gone in a complete circle and are back where we started. Because I think its this API thats ultimately responsible for returning the "wrong" filesystem relative path.
Some follow-up to close out this question.
Turned out the real issue was how I was creating the file handle using TFileStream. I changed to open with fmOpenRead or fmShareDenyWrite which solved what turned out to be a file locking issue.
srcFile := TFileStream.Create(physicalFilename, fmOpenRead or fmShareDenyWrite);