I wrote my own LSP which is working fine. However, I can not catch dns queries. For example there is no function like WSPGetHostByName or WSPGetAddrInfo.
My lsp also supports UDP protocol but it is not working. If I run nslookup from console (cmd.exe) it seems working but i can not catch gethostbyname. Does anyone know how to do that? I don't think writing NSP (Name Service Provider) is a solution. But I might be wrong.
Thanks
We have developed a LSP that can "intercept" DNS queries. The only way to do it is by hooking into all of the DNS functions, keep in mind there are a few challenges you need to solve:
You need to use a good hooking library that will support both 32bit and 64bit code.
The library license must be right for your application, there are some free libraries, but can be used freely only with free projects.
When you hook the functions, you need to make sure not to modify certain values that are not IP based and defer the query to the real function.
Intercepting UDP will not work since the queries are going out from MS DNS client, so unless you write a low level driver like: TDI, NDIS or WFP you must hook the functions (or write a NSP). NSLookup works for you because it creates the DNS queries itself.
My solution would be as follows:
Take the well known web browser: firefox.exe
copy it into a new name: icefoxy.exe
modify the EXE so it will load a custom DLL.
I have already done this a few months ago, but since Firefox is constantly getting updates, that means:
EITHER: keep one version and do not update (at your own risk, may cause security problems since that means vulnerabilities will not be fixed)
OR: Update your modification every time firefox.exe changes.
The DLL can easily be written using Delphi.
The Firefox modification needs assembly language, unless you know how to download all necessary files to compile firefox yourself, have access to a C/C++ compiler (likely mingw-gcc), and be prepared of the fact that there are 2 mutually exclusive standards of C++, and if your g++ (part of the gcc suite) is incompatible with your Firefox source, then your attempt will fail.
I am not a C++ expert myself, so I took the (for me, at least) easier route using machine language, that way I do not need to be a C/C++ expert to get the job done.
Some relative points:
What functions must be hooked to intercept all Firefox's access to dns server(s) ?
I noticed, that if you load a Delphi DLL into Icefoxy.exe (a renamed copy of Firefox.exe)
then a Delphi form's colors are missing, eg. if you set (either in object ispector or in code):
Label1.Color := clLime;
you still see a label withOUT lime background color. I do not know the exact reason, but it seems that Delphi VCL is relying to be used in an EXE, and when you use Delphi VCL components inside a DLL instead of an EXE, some things (such as color) does not work as intended.
I'd be happy to post my code (both assembly language modifications to Firefox and the Delphi DLL source code) , but how/where can I post it so it is publicly viewable ?
I used Delphi 7 to make the DLL.
if you use Delphi 2009 or later, you need to take extra care that any string data passed between the Delphi code and any non-Delphi code has the correct encoding, due to the fact that In Delphi 2009 and all newer versions, the type String is an alias to unicodestring, where in older Delphi versions, the type String is an alias to AnsiString.
At the time I did this, it was just a small experiment to find out if I can force Firefox to load my own DLL inti it's process address space.
Another interesting idea would be to get access to the DOM (Document Object Model) of Firefox from a Delphi DLL, that would give a working alternative to using TWebBrowser (based on ActiveX version of Microsoft's Internet Explorer).
I know there have been components like TWebBrowser based on Firefox, but their problem is that nobody cared to update them for a very long time, so they are compatible only with some very outdated version of Firefox.
Related
I need to write a program that uses some COM objects, accessed from the python comtypes package. I use the clsid and/or progid to create and use them. These objects are provided by a third party, and normally they are installed with a normal installer (setup.exe or MSI file).
Let's suppose that these DLL files have a license that allows me to ship them together with my program. Is it possible to load these DLL files into memory, and use them from a portable app without actually registering them? Or alternatively, can I register them from my program?
A related question is this: how to determine the chain of DLL files that are needed to create a given COM object? (Other than trial and error.)
Background: in reality, there are multiple libs and the main problem is that I do not want the users to run 4 different installers before they can start the actual program. That would be too difficult for an average user.
You're asking a lot of questions here. There are a lot of ways to accomplish what you're trying to accomplish, and it's hard to answer such a broad set of questions. If you have specific questions on how to do a specific thing, please start new posts for those.
That said, I will try to give you some information to help you figure out what you need/want to do.
Can you use a COM DLL without registering it?
Yes. There are several ways, depending on the needs of the COM DLL and the platform you're using. However, some options won't always work, and other options are very challenging.
DllGetClassObject - In some cases, depending on the COM object you're trying to load, you can just load the DLL, call the DllGetClassObject function directly, and use the returned IClassFactory to create your object. This is the easiest way -- if it works. If the class you create requires that the DLL be registered (maybe it does a CoCreateInstance internally, or maybe it needs proxy support), this won't work for you. To determine if this will work, it's either trial-and-error, or you have to ask the developer of the COM DLL.
Registration-free COM - This is how it's done in .NET. I'm not sure if you can do anything like this easily in Python.
CoRegisterClassObject - If you are going to create your own registration-free COM implementation, this function is going to be critical. I believe this is a fundamental implementation detail for Microsoft's registration-free COM. However, be aware that this would be a very challenging thing to do, and it would require a very good understanding of COM.
Can you register a COM DLL from your program?
Yes. There are a few ways. However, you are likely to run into security issues here -- typically, COM components register themselves in HKEY_LOCAL_MACHINE, and you typically need admin rights to write here. Some COM components/installers are designed to register themselves in HKEY_CURRENT_USER, which would get around the security thing. However, you may have no control over where a component registers itself, and even if you do, registering in HKEY_CURRENT_USER isn't a perfect solution.
regsvr32.exe - One option is to programmatically invoke regsvr32.exe on the DLL.
DllRegisterServer or DllInstall - If a COM DLL can be registered with regsvr32.exe, then it has at least one of these functions exported. You can load the DLL manually and call these functions just like regsvr32.exe does. DllInstall is less common than DllRegisterServer. If DllInstall is present, it may give you the option of installing in HKEY_CURRENT_USER. If not, you have to just do whatever DllRegisterServer does, since there are no options you can provide to that function.
Write the registry values yourself -- If you can figure out all the registry settings that are needed, there's nothing stopping you from putting them into the registry manually. This would get around the HKEY_LOCAL_MACHINE/HKEY_CURRENT_USER issue -- you can write them wherever you like (but HKEY_LOCAL_MACHINE still probably requires admin rights).
regedit.exe - Another way to write the registry values yourself is to store them in a .reg file and call regedit.exe to merge them.
How do you determine dependencies of a DLL?
Ideally, the developer of that DLL knows and can tell you. That's the only way that's truly fool-proof.
For COM dependencies, it may be impossible to figure this out any other way than asking the developer or trial-and-error. This is because a COM dependency may exist simply because some code in the DLL just calls CoCreateInstance to create some third-party COM object, and since this is something that is only expressed in source code, there is no metadata on the DLL that will help you find these dependencies.
The above is also true for any dynamically-loaded dependencies. For example, if some code just calls LoadLibrary directly, there is no way for you to determine the dependency from the outside.
For statically-loaded dependencies, you can use tools like Dependency Walker. Note that a lot of the dependencies you will see are system dependencies -- you don't want to include, for example, user32.dll and kernel32.dll because these are installed with Windows.
How do you install third-party dependencies?
If you know exactly what files to write, where to write them and what registry settings (etc) need to be applied, you can do all of that yourself. For some dependencies, it can be easier to just include the third-party installer in your installer and just execute it silently. Many installers support a silent mode for just this reason. A good example of this is the Visual C++ runtime (msvcrt*.dll) -- many applications need this dependency, and many installers just include Microsoft's installer as a part of their distribution, and the primary installer just calls the secondary installers silently.
Can you use the InternalsVisibleTo assembly attribute in a AssemblyInfo file of a MonoTouch Library to allow MonoTouch Unit Test (Touch.Unit) access to the internals of the MonoTouch library?
This is something that is great to use in non-MonoTouch world to allow testing of internals without having to jump through hoops. However I am not able to get it working with a MonoTouch Unit Test. So before I go any futher I figured I would ask if it is even possible, since this is an iOS Application that is the test runner, so not sure if an iOS application which is compiled to native code can even do this.
Yes, it should (or it's a bug) even if I do not recall trying it myself.
The key point is that [InternalsVisibleTo] is mostly a compiler trick and it is supported by the C# compiler (smcs) shipped with MonoTouch (as it's used inside the BCL). As such there's no reason why it should not work from a Touch.Unit-based application.
Now keep in mind that all other rules still applies. E.g. if the the managed linker is enabled when all unused code will be removed (even if marked with the attribute).
I am planning to create a Licensing Module which can be commonly used for all Desktop Applications. So i thought of making it so simple without any or less coding in the existing applications which are going to be activated by this Licensing Module.
So is there any way where if the user passes the exe location, the system should capture the exe available in the particular location, and the system should get all the windows forms available inside that exe?
Am not sure whether it is possible or not but i need to know whether there is any way to do it. It would be helpful for me to develop this with less complications.
You can read the actual executable image data from its path and in case, its a managed (.NET) executable, you can use the metadata to do some analysis. In this case, you can browse through all types within the executable assembly (and perhaps other assemblies from the same directory) and find out the number of classes/types that are inherited from System.Windows.Forms.Form.
However, considering that these applications are probably in your control, the saner approach would be have an public API in these executable that will provide you the relevant information.
Guys i found a solution for this....i used the following method...
Assembly SampleAssembly = Assembly.LoadFrom("Assembly path here");
// Display all the types contained in the specified assembly.
foreach (Type oType in SampleAssembly.GetTypes())
{
Console.WriteLine(oType.Name);
}
this worked perfectly for me....
VinayC thanks for your support buddy...really appreciate it....:)
My Delphi Prism program needs to create and read and write into an inifile, but I think I noticed Delphi Prism doesn't really support any sort of Inifile structure. (Correct me if I am wrong.)
This leads me into talking about ShineOn library file, which supports inifile. However, it crashes the program when you run your program on Linux under Mono. It doesn't matter if I use any methods from ShineOn or not. As long as the ShineOn library file is listed under uses keyword, the program does not run but crash completely on Linux. Can you create inifile in Delphi Prism for .net that will work on window and Linux(Mono)? If so, how would you do it?
I did search for answer on the internet and Stackoverflow, which led to me C# Class INI file. I thought, it was promising until I noticed that it needs to load Kernel32.dll file to work. (Again correct me if I am wrong). Apparently, there is very little information on the Internet about Delphi Prism Inifile.
Actually you really shouldn't use .ini - Files in .NET (or Mono) environments at all. .NET and Mono offer complete App.config XML-Configuration infrastructure and you should leverage this for your applications. There are a lot of advantages because everything is available type safe and all is covered in the System.Configuration Namespace.
See http://nini.sourceforge.net/
It documented to work on both MS .NET and Mono
Is there any UI library that can be to build both a text user interface (ncurses) and graphical user interface (GTK? QT?) from the same source?
I know that debconf can be used with various frontends, I would like to build something similar but programmable.
The library that powers YaST independence to do ncurses, gtk and qt with one codebase provides what you are looking for, and it is not tied to YaST itself.
Actually libyui only requires the standard C++ library and phtreads (IIRC). The UI plugins require of course the respective libraries (Qt, ncurses). YaST uses libyui via a set of YCP bindings that export a YCP like API on top of libyui.
The library is a bit lowlevel (one layer below an event loop), my colleage Klaus Kämpf wrote about using it some time ago in his blog, including binding to scripting languages it using swig.
The only part that is SUSE specific is the packaging, so you would need to package it yourself. Stackoverflow did not allow me to link more than once. The code of the library is linked from Klaus blog. Replace libyui for "qt" and "ncurses" for the plugin's code.
Also google for "YaST Independence From YCP" to find a blog entry from Andreas Jäger on the subject.
you could write your program to uses ncurses, and then use PDCurses to convert it to an X11 application - as the readme advertise.
I know it because I've used it as portable curses, though I've never tested its X11 capabilities
Not exactly a library but you could consider writing a web app that degrades well to Lynx
The GoboLinux guys have created their own toolkit for python called AbsTK, they use it for their installer, which actually works really good. I have never used the toolkit myself, but the apps built with it seems solid.
There's Cursed GTK, but it seems a bit dated. I found some references to a port of Qt to ncurses called Qt Console, but it seems to have disappeared.
By using a library that targets both the text-mode and GUI environments, you have a big risk of getting stuck with the worst of both worlds.
You will be better off structuring your code using the MVC pattern, and providing separate views and controllers for each platform you target. Pushing all the logic down to the model classes has several other benefits:
The code will be easier to test because you are forced to keep the user interface out of the actual domain logic.
Your program can have user interfaces that have very little in common, e.g. a web UI, or an UI driven by speech.
You can run the program easily with no UI at all (i.e. script it) by accessing the model classes directly in the same way that the controller classes do.
I think what's used for configuring the linux kernel when compiling is dialog/cdialog/xdialog. But it's been a while since I've compiled a kernel, so my memory may be off. The most promising link I can find is this one for Xdialog.
Maybe tcl/tk would provide what you want http://www.tcl.tk/
Here's the page on interfacing with curses. There is a claim there of integration with ncurses.
http://www2.tcl.tk/2372