I am trying to generate an xls file with Spreadsheet::SimpleExcel that calls a function that is defined in a third party add in (Bloomberg, if it matters). The underlying WriteExcel package does not let me write this out because it does not know about this add-in function. I see the giant hash table of built-in functions that the module knows about and could potentially add this function to it, but I don't know the attributes of the function, especially the 'ptg code'.
Is there a way to either determine what the ptg code (I assume this is something like an opcode) of this third-party function, or is there some way to trick the module into letting me write out these functions without it having to know these details? Or some third plan that I haven't thought of?
Spreadsheet::WriteExcelXML and Excel::Writer::XLSX should be able to generate Excel files with third party functions.
Both modules use the same interface as Spreadsheet::WriteExcel although with fewer features.
I think you need to use Win32::OLE and it's a bit messy. Try:
$xls->AddIns->Add( $xll_path );
$xls->RegisterXLL( $xll_file );
where $xll_path is the full path to the xll for Bloomberg and $xll_file is just the xll name.
Related
I have an .m file which I wish to share with my friends but I am not interested in giving .m file. Could someone help me with best possible ways to convert it to a file that is not decodable?
I tried converting it to .p file by simply typing pcode example.m
however I don't believe it is really protecting it. I was able to convert my .p file back to .m file with the following link. https://sites.google.com/site/sippeyfunlabs/matlab-hacks/please-do-not-secure-your-password-in-matlab-p-code
This actually confirms that my code is not protected.
It'll be nice if someone shares the best methodology to protect .m file and sharing.
Thanks
The link you provided yourself already indicates that it is very difficult to obfuscate MATLAB code:
In fact, MATLAB language is very difficult to be secured or even obfuscated.
This is due to the late binding (or dynamic binding) feature of
MATLAB. [...] The amount of meta information associated with this
feature basically forbid any attempt of adding code level security.
Simply put, if there is a MATLAB file, and it calls a function foo
inside it. Until the runtime, the MATLAB interpreter do not even know
if foo is a function stored in M file or a built-in function or a mex
function or even a workspace function handle. Thus, it must store foo
as is somewhere inside the generated P-code.
Also to best solution is already mentioned on that page:
If there is really a need to do this, using the good old binary is a
much better solution. Or you can put critical code on a server, away
from the user.
Create a binary, i.e. mex file (see the answer of Wolfie): Note that to some extent also binary code can be decompiled especially small ones.
Host your code on a server (and run the code server-side): This is the best method to protect your code. You should let the user upload the input for your script and return the result. You can also automatize this process using a matlab script to make this process transparent to the user.
You could build a mex file.
This will completely obfuscate your actual MATLAB code, since it will be written in C/C++/FORTRAN, but the algorithms will still be there if your friends are determined enough to look for them.
I am using a function for sorting arrays inside my calc document, which is supplied via an extension. However, transferring the file to a different system, where the extension isn't installed, breaks the function. Since the file is designed to be shared with many other users, it is impractical to instruct each of them to install the necessary extension individually.
Is there a way to embed/link the function supplied by the extensions to the .ods-file itself in such a way that the function wont break on file transfer?
When I tried to embed an add-in into a document by modifying manifest.xml, the add-in was ignored. Also, I ran into other limitations of embedding, such as not allowing importing from a pythonpath folder.
The documentation is rather difficult, but these two links perhaps support my conclusion:
https://wiki.openoffice.org/wiki/Documentation/DevGuide/Spreadsheets/Spreadsheet_Add-Ins
https://wiki.openoffice.org/wiki/Documentation/DevGuide/WritingUNO/Deployment_Options_for_Components
So it looks like the possibilities are to either require people to install the extension, or use a user-defined function instead of an add-in. It should be possible to embed a UDF in a document.
I am trying to wrap some UniData Subroutines to SOAP Web Service. I'm planning to use C# and UODOTNET library (IBM U2 Data Management Interface for .NET). Also I'm looking to create an engine to read all the available Subroutines from data server and also reads all the required parameters and dynamically generate required codes for Web Service.
My code would be something like this:
var session = UniObjects.OpenSession(
"192.168.0.1",
"user",
"password",
"account"
);
var cmd = session.CreateUniCommand();
cmd.Command = "LIST SUBURB.INDEX"; // ?????
cmd.Execute();
var res = cmd.Response;
Question 1: Is there any command that I can use to retrieve the list of all available subroutines?
Question 2: Is there any command that I can use to retrieve list of all parameters for specific subroutine?
Cheers
The short answer is no.
The longer answer is yes, but with a lot of work.
Since you are asking this question, I'm going to assume you are missing a lot of generally knowledge about the platform. Hence to be able to do this you'll need to:
Learn about how VOC works, specifically how executable code can be catalogued here.
Learn about the CATALOG and how cataloguing programs globally, locally and direct differ.
Understand how your system in particular is designed. Some places have everything directly catalogued in the VOC, others are a mix. If the former, it'll be easier for your question.
Once you understand the above, you'll know how to get a list of all executable programs from VOC, local catalog and global catalog. For example, a simplified example for the VOC is the UniQuery command LIST VOC WITH F1="C".
The hard part is getting the parameter list, of which there isn't any system command. To do this you have 2 options.
Reverse engineer the byte code of every subroutine and tease out the number of parameters
If you have access to the related source code, parse it to generate the list.
Just wanted to add a comment on this one, in UniData there is a MAKE.MAP.FILE command that will identify Programs and Subroutines ( and the number of parameters) which puts the information in the '_MAP_' file. This does not tell you what the parameters are used for, but it helps.
I'm having this problem for a while now and google have its limits.
I'm writing a powershell file that contain several generic function.
I use the function in vary scripts and now I want to let other personal in my work to use them as well.
the problem is, do to sensitive operation, I want to lock and protect the script (compile to a dll, exe etc').
how do I create powershell library like C# DLL?
one option I try but did not find out how to continue is to compile the script using powerGUI to executable file ( .exe) but then I canot access the function in it let alone pass on parameters to that function.
hope you understood me :)
thank you.
You don't. Rather than trying to obscure this information (if you compile them, they can be decompiled and your "protected" resources will no longer be), remove them entirely and make those parameters for your functions. This both protects your "sensitive" data and makes the code much more reusable.
You can then package your functions into a module
This is a little convoluted, but lets try:
I'm integrating LUA scripting into my game engine, and I've done this in the past on win32 in an elegant way. On win32 all I did was to mark all of the functions I wanted to expose to LUA as export functions. Then, to integrate them into LUA, I'd parse the PE header of the executable, unmangle the names, parse the parameters and such, then register them with my LUA runtime. This allowed me to avoid manually registering every function individually just to expose them to LUA.
Now, flash forward to today where I'm working on the iPhone. I've looked through some Unix stuff and I've gotten very close to taking a similar approach, however I'm not sure it will actually work.
I'm not entirely familiar with Unix, but here is what I have so far on iPhone:
Step 1: Query for the executable path through objective-C and get the path of my app
Step 2: Use dlopen to get a handle to my app using: `dlopen(path, RTLD_NOW)`
Step 3: Use `dlsym( libraryHandle, objectName )` to attempt to get the address of a known symbol.
The above steps won't actually get me to where I want to be, but even that doesn't work. Does anyone have any experience doing this type of thing on Unix? Are there any headers or functions I can google to put me on the right track?
Thanks;)
iPhone does not support dynamic linking after the initital application launch. While what you want to do does not actually require linking in any new application TEXT, it would not shock me to find out that some of the dl* functions do not behave as expected.
You may be able to write some platform specific code, but I recommend using a technique developed by the various BSDs called linker sets. Bascially you annotate the functions you want to do something with (just like you currently mark them for export). Through some preprocessor magic they store the annotations, sometimes in an extra segment in the binary image, then have code that grabs that data and enumerates its. So you simply add all the functions you want into the linker set, then walk through the linker set and register all the functions in it with lua.
I know people have gotten this stuff up and running on Windows and Linux, I have used it on Mac OS X and various *BSDs. I am linking the FreeBSD linker_set implementation, but I have not personally seen the Windows implementation.
You need to pass --export-dynamic to the linker (via -Wl,--export-dynamic).
Note: This is for Linux, but could be a starting point for your search.
References:
http://sourceware.org/binutils/docs/ld/Options.html
If static linking is an option, integrate that into the linker script. Before linking, do "nm" on all object files, extract the global symbols, and generate a C file containing a (preferably sorted/hashed) mapping of all symbol names to symbol values:
struct symbol{ char* name; void * value } symbols = [
{"foo", foo},
{"bar", bar},
...
{0,0}};
If you want to be selective in what you expose, it might be easiest to implement a naming schema, e.g. prefixing all functions/methods with Lua_.
Alternatively, you can create a trivial macro,
#define ForLua(X) X
and then grep the sources for ForLua, to select the symbols that you want to incorporate.
You could just generate a mapfile and use that instead, no?