I'm looking to modify ODBC calls either directly before hitting the ODBC stack or between the ODBC stack and the dll driver for the connection I am using. For instance, if the application does a SELECT, I want to be able to modify it be SELECT_ALL How can I do that?
The ODBC setup information points to the driver DLL. You could replace that with your own DLL that has the ODBC entrypoints. Simply make all the ones you don't care about be simple calls to the "real" DLL. The execute and prepare entrypoints could modify the given statement before passing it on to the driver DLL.
For example, if using a User DSN, you might replace the value in HKCU\Software\ODBC.ini\datasourcename\Driver with your own shim DLL.
After a bit of googling, I am not finding an obvious empty shell project that would be an ideal starting point. The API reference has details about the API. In general, though, you shouldn't really need information from there. You just need to pass the parameters for each API to the actuall driver DLL. The function prototypes could be extracted from sql.h and sqlext.h.
An alternative method that might be easier than writing a shim DLL would be to hook just the execute and prepare functions (probably just SQLExecDirect and SQLPrepare). This article is the first hit I saw on doing that.
Related
Is there any way to encrypt the SQL Packages (Stored procedure, Functions etc) in oracle using specific key and decrypt using the same key for security purpose???
i am using oracle 12c....
Thanks,
Yes, you can use the wrap tool for this, see PL/SQL Source Text Wrapping
You can wrap the PL/SQL source text, thereby preventing anyone from displaying that text with the static data dictionary views *_SOURCE.
In principle decryption is not supported, however you can use tools like Unwrap It!.
I like Wernfried's answer. I would like to expand a little if I may.
Assuming you will try the WRAP method (some say easily cracked), here are things to try to check it's effectiveness:
Check with tkprof if executing the WRAPd objects reveals any logic or SQL
Check the V$SQL and related views to see if executing the WRAPd objects reveals any logic or SQL
Check with OEM to see if executing the WRAPd objects reveals any logic or SQL
I've never tested the above, but if I was considering using WRAP I would do so that I know the limits of whatever protection it gives. Given the importance of DBAs being able to monitor and tune queries, I would be surprised if the SQL at least was not ascertainable via standard performance views/queries.
Also note, if your code has any dynamic SQL or PLSQL, this could show up in the symbol table of the wrapped file (as hex codes).
I think you cannot wrap TRIGGER code (though, you could of course have triggers call PLSQL procedures that are wrapped).
If you are a software vendor concerned about customer DBA poking around your code, given the above point about SQL monitoring, and assuming the DBA have access to a suitable cracker I don't think there is much you can do to stop them them. You might be able to prevent non-DBA users from doing this by restricting access to DBA_SOURCE, V$SQL and related views.
Out of interest I had a look at Native Compilation of PLSQL, to see if the compiled M-code could be shipped instead of the PLSQL source, but it seems that you have to ship the PLSQL code too.
What other options are there? Can the PLSQL be hived off to a remote protected database and consumed via REST API calls? That depends heavily on application logic and data access, and if having such a service on a protected remote server is feasible.
The one last thing I'd consider if it was absolutely necessary to hide the logic would be to implement as ProC/C/Java modules to create EXTERNAL LIBRARIES. But note here as well, SQL calls within the ProC/C/Java will still be exposed in V$SQL. Plus, there aren't many around who write Pro*C anymore.
Using wrap functionality is only obfuscation, not encryption. It is easily undone with a variety of available web sites, python scripts, and other PL/SQL procedures. There are additional obfuscations that you can do to make interpretation of your code more difficult (Oracle's SQL Developer has some built-in functions for this) so that even if your code is unwrapped it is still difficult to read. Here's an example of one other custom obfuscation toolkit, too: https://pmdba.wordpress.com/2020/02/24/code-obfuscation-toolkit/. For a commercial-grade toolkit, check this out: http://www.petefinnigan.com/products/pfclobfuscate.htm
I am trying to read sap change log using rfc + vbs as buffer.
I know that I need to use CHANGEDOCUMENT_READ_HEADERS and CHANGEDOCUMENT_READ_POSITIONS functions to do this, but have not found any research how to do this properly with the help of vbscript.
I have already found out how to read normal tables using BBP_RFC_READ_TABLE but it doesn’t work with CDPOS...
Any ideas?
First, if you want to use VBscript to integrate with SAP, you will go through RFC channel using SAP NWRFC library or SAP .Net Connector 3.0, and the SAP functions or BAPIs you can call must be remote enabled. Unfortunately, the two functions, CHANGEDOCUMENT_READ_HEADERS and CHANGEDOCUMENT_READ_POSITIONS, are not remote enabled. I could imagine CDPOS is difficult for you because CDPOS has wide fields which cannot be processed by BBP_RFC_READ_TABLE.
Once we are aligned with the objective challenges, there are two options to help you move forward:
Write your own custom "Z" function module, which is remote enabled, and call CHANGEDOCUMENT_READ_HEADERS and CHANGEDOCUMENT_READ_POSITIONS inside the function;
Use third party commercial library (our company AecorSoft developed such ADO.NET compliant library for SAP integration).
I would suggest you explore #1 first. You can follow this blog https://blogs.sap.com/2017/02/09/how-to-use-dotnet-connector-nco-inside-vba/ to get started.
Dunno about BBP_RFC_READ_TABLE but RFC_READ_TABLE perfectly reads CDPOS
If you need to header-based query you will need 2 sequential reads: first for CDHDR headers and the second for positions, constructing second query from the first.
In powershell, when using new-object to instantiate, or get a reference to (or whatever you want to call it), a COM object I recall that the COM object needed to have a certain property to be able to expose it's functionality (through the registry I think is how it did it, via its Class-Id or something).
I can't for the life of me remember what the technical term for the "exposing" was, just that if the object/module/dll/assembly wasn't configured appropriately, the object wasn't available for instantiating with new-object (so that you couldn't just start instantiating objects within 3rd party software I assume is why an explicit setting must be made).
If anyone knows what this term is called it would be very helpful. Its the first step I'm taking in reusing a clients software functionality from a webservice, so I don't have to rewrite all over.
Much appreciated...
You have to register the COM server (binary) which creates a number of registry entries. The primary one PowerShell needs is the ProgID. Also, register a typelib should help PowerShell provide you with member information on the created object. You typically use regsvr32 for a native COM binary and regasm for a managed COM binary.
I want to develop one driver so i have create one service and one .sys file for driver to be display now i do not know how to attach that two file or how to register my driver to windows.
so just tell me the step which i should follow.
Thanks and hoping for positive response.
You can load driver by using StartService API. And you can also use ZwLoadDriver. It's a native API. You can find more information about them in MSDN.
Depends on the driver you write. If it's a device driver it's automatically loaded once the system needs it for the previously defined device classes.
For drivers which don't need devices you need a special driver service. See this CodeProject example - section "Dynamically Loading and Unloading the Driver"
Basically the most straightforward is using the following apis (in that order). I think it should be pretty straight forward.
http://msdn.microsoft.com/en-us/library/ms684323%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms682450%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms686321%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms682028%28v=VS.85%29.aspx
First, my concrete question: In my attempt to access cursor raw data, my call to LockResource succeeds, but the SizeOfResource call tells me that the data is only 20 bytes, which is just too small...
What I'm really trying to do: I am exploring possibilities for remoting cursors from mixed code server application to a CLR client application. My (quite possibly naive) idea is to use LockResource to access the binary data of a resource (embedded in a native dll), pass this data to the client and treat it in the same way as resource data that has been retrieved from a local assembly using Assembly.GetManifestResourceStream to get the resource stream and Resources.ResourceSet to iterate through the resources. I am hoping that since .NET no doubt makes the same underlying system calls as native code, this makes sense. On the other hand...
Does anyone have any comments or better ideas ? (It would of course be easier to simply provide a compatible resource package on the client and remote some cursor id, but we seem to have a requirement for cursors to be dynamically added at runtime.)
Any comments gratefully received!
In the end, I used Win32 calls to get at the cursor bitmap, serialised this and the hotspot location to the client, and recreated the cursor there using the Win32 API again. Once you've got an HCURSOR cient-side, you can construct a .NET WinForms Cursor from it if you want (but such an object cannot be serialised using straightforward .NET - otherwise that would have been a much easier way to remote it!).