Besides a dictionary attack, what can I do?
I'm trying to find out what properties do DirectShow filters have. I know one of the properties is FriendlyName (that's the only one MSDN mentions), so I tired searching for it through quartz.dll with a hex editor thinking that names of other properties might be nearby, but apparently quartz.dll does not contain the string "FriendlyName".
(No, IPropertyBag2 is not available.)
Actually, quartz.dll does contain the string "FriendlyName", but it's in Unicode (UTF-16), not ASCII. From a quick look, quartz.dll also tries to get properties "CLSID" (VT_BSTR), "Merit" (VT_I4), "FilterData" (VT_UI1|VT_ARRAY).
There might be additional properties, but it is unlikely. Those powerder WDM kernel drivers expose DriverPath property. Others might have additional properties mapped from additional registry keys. Anyway, you are not going to find anything interesting there...
Related
Wrote a plugin to handle some custom format stuff in yaml files that I've written for a huge project. It's a chat bot that can respond in a huge number of ways. There is a lot of slang and non-standard words in the yaml.
I don't want to disable spellchecking as I want to fix legitimate speeling errors. But the annotations under the "misspelled" slang words are conflicting with the annotations in my plugin, and causing issue.
One yaml file has 349 "typos". 10% or so are legit. The rest are slang and custom words.
I need to do one of two things. Either add those words to the dictionary (I've found the method to do that - SpellCheckManager.getInstance(project).acceptWordAsCorrect()) OR get a list of the words and create a custom dictionary from them. Both approaches require me to grab a list of all typos in the document/editor/project.
That's the part I can't find. Looked everywhere. (List of current Annotations? List of current Problems?) Googled my fingers off. Anyone able to point me in the right direction?
This is not the IDEAL solution, but it worked for my means, and I'm leaving the answer in case this is googled.
In DaemonCodeAnalyzerImpl, there is a method:
DaemonCodeAnalyzerImpl.getHighlights(Document document, HighlightSeverity minSeverity, Project project);
This returns a list of all highlights in the document. The method is Annotated with #TestOnly, and docs state that it should only be used in Test code because it breaks/shortcuts the normal way to access that. It still works in non-test code however.
Since the only thing I wanted was the strings of the typos, I pulled the list, then looped through the HighlightInfo's in the list, and pulled the .getText()s.
No danger of screwing anything up.
Then pushed all those strings into:
SpellCheckerManager.getInstance(project).acceptWordAsCorrect(word, project);
Viola! All current highlighted typos are now added to the dictionary.
Proper solution? No. Good enough for what I needed to accomplish? Yup.
I am trying to make a dyld extractor similar to dyld_decache and dsc_extractor. But I am having trouble parsing the __objc_selrefs section.
For testing purposes I used libsystem_trace.dylib, and was able to find and parse its mach_header and its segments and sections. But looking at the __DATA.__objc_selrefs section I find pointers like 0x201b8647fc8 and 0x201b860d716, which are way too high and point outside the cache.
In contrast, in a normal Macho file, the pointers in the __objc_selrefs section point to their corresponding string in the __TEXT.__objc_methname section.
I know that dyld slides and rebases sections, but after a lot of tinkering, I still could not fix the pointers. Any guidance would be amazing, especially given how little resources there is out there.
These "addresses" don't just point outside the cache, they point outside the maximum range iOS allocates for the userland address space.
The thing is that these aren't raw addresses, they're addresses with some flags mixed into them. I've seen at least 0x20000000000 and 0x40000000000, and they seem to be exclusive to Objective-C code. I have no idea what they mean or what the true bitmask for these flags is, but so far keeping the lower 40 bits (0xffffffffff) of the addresses has done the job for me.
That would turn e.g. your 0x201b8647fc8 value into 0x1b8647fc8, which should be well inside the shared cache boundaries.
This is actually a two-fold question, I guess. On one part, I'd like to know whether there's a neat way to enumerate all declared UTIs on a given system.
I know lsregister -dump is an option, given some grep and parsing on my side; however, I'm left to wonder if there isn't a better solution.
Further... I'm wondering if there's a way to retrieve a list of imported/exported UTIs given an app's path. I know the reverse should be possible (i.e. finding which bundle has declared a given UTI).
One of the reasons why I'm wondering about this is because a possible solution for the first part of the question would be to iterate through all apps and retrieve their imported/exported UTIs (although I think it would probably not be a very efficient solution)
I've searched everywhere I can think of and am not really any closer to an answer. So far, it would seem it's either parse output of lsregister -dump, or try to read UTI keys directly from apps' Info.plist files...
Finally, in my searching I've come across a private API that might be of use, but I have absolutely no idea how to use it, since there's absolutely no documentation for it online... I'm talking about "__UTCopyDeclaredTypeIdentifiers"... maybe somebody is aware of which (if any) parameters does that function take, and/or what exactly does it return?
import Foundation
#_silgen_name("_UTCopyDeclaredTypeIdentifiers") func UTCopyDeclaredTypeIdentifiers() -> CFArray
let UTIs = UTCopyDeclaredTypeIdentifiers()
print(UTIs)
Should print all the UTIs that the function knows about.
I'm currently trying to write a program in VB.NET which fluidly changes the DWM window colorization colors in Windows 7.
I first tried to edit Registry values directly, but I had to restart the UXSMS service. This solution was unsatisfying, because of the toggle of the taskbar.
I'm now searching for a function in a DLL such as user32.dll or themecpl.dll which can reproduce the behaviour of control panel when setting the window color.
I'm now on IDA, searching for the adquate function (CColorCplPage::SetDwmColorizationColor seems good!). If anyone has one, please share it!
(If anyone need screens or code, please ask. Sorry for my poor English.)
Your first attempt failed because manually editing the Registry is never the correct way to change system settings. As you found out, lots of Windows components (and other applications!) read those configuration values once and cache them, preventing your changes from being propagated. Another problem (and you'd be surprised how often I see this) is applications that attempt to muck around in the Registry generally end up corrupting things.
Instead, you should call the documented API to change the settings. There's almost always a documented way of doing this, and if there isn't, well then you shouldn't be doing it.
This appears to be one of those cases. There's a documented DwmGetColorizationColor function, but there's no corresponding DwmSetColorizationColor function, as one might expect.
The reason is that the user is supposed to be the only one who can change their colorization settings, not other applications. You might promise not to abuse this, and to only make such changes at the user's explicit request, but not all applications can be trusted to do this. Lots of people would use it maliciously, so these functions have not been documented and exposed.
But as usual, if you press on, you can usually find an undocumented way of doing things. The problem with using undocumented functions is that there's no guarantee they'll work or continue to work. They've been intentionally left undocumented because they're liable to change on new versions of Windows. You should only use them at your own risk.
In this case, if you use a program like DumpBin to obtain a list of all the exported functions from the DWM DLL (dwmapi.dll), you'll see a number of undocumented exported functions.
The ones you're interested in are DwmGetColorizationParameters and DwmSetColorizationParameters. Both of these functions take a COLORIZATIONPARAMS structure as an argument that contains the values they need.
So, you need to reverse engineer these functions and obtain the appropriate definitions. Then, you can call the DwmGetColorizationParameters function, passing in a COLORIZATIONPARAMS structure to obtain the current configuration settings; modify the member of the structure that contains the current colorization color; and then pass that modified version of the structure to the DwmSetColorizationParameters function.
Did I mention that I don't recommend doing this?
I read some examples of code necessary to make an application Applescript-able, but I still don't understand if the Apple codes used to identify a command, a class, a property can be any value I want (with the exception of the code for the application class), and if they must be registered in some site.
Is there a list of codes with a particular meaning for Applescript?
This is what you want: AppleScript Terminology and Apple Event Codes. More can be found in this Apple document.
Four-letter codes consisting solely of lower-case letters are reserved to Apple. Otherwise you're perfectly free to choose one.
You don't have to register them, as far as I know.
Choose your own. They must be unique. There is no way to know if they are unique, but they must be.
Love it.