Specifically, a perl script. Parameters need to be passed, but nothing needs to be returned.
I've searched the web and the Reference Manual, with no results.
The answer depends a bit on the operating system you are using. You may ecute a command by using the function
void system(string command)
on Windows. On Unix, use
void system(string command, void childCB(int) [,void parentCB()])
Check the DXL Reference Manual, Chapter 10 Operating system interface for details. Here is example usage:
if (platform=="WIN32")
system "notepad"
Related
I think this is more of a Tcl configuration question rather than a Tcl coding question...
I inherited a whole series of Tcl scripts that are used within a simulation tool that my company built in-house. In my scripts, I'm finding numerous instances where there are function calls to functions that don't seem to be declared anywhere. How can I trace the path to these phantom functions?
For example, rather than use source, someone build a custom include function that they named INCLUDE. Tclsh obviously balks when I try to run it there, but with my simulation software, it runs fine.
I've tried grep-ing through the entire simulation software for INCLUDE, but I'm not having any luck. Are there any other obvious locations outside the simulation software where a Tcl function might be defined?
The possibilities:
Within your software. (you have checked for this).
Within some other package included by the software.
Check and see if the environment variable TCLLIBPATH is set.
Also check and see if the simulation software sets TCLLIBPATH.
This will be a list of directories to search for Tcl packages, and you
will need to search the packages that are located outside of the
main source tree.
Another possibility is that the locations are specified in the pkgIndex.tcl file.
Check any pkgIndex.tcl files and look for locations outside the main source tree.
Within an unknown command handler. This could be in
your software or within some other package. You should be able to find
some code that processes the INCLUDE statement.
Within a binary package. These are shared libraries that are loaded
by Tcl. If this is the case, there should be some C code used to
build the shared library that can be searched.
Since you say there are numerous instances of unknown functions, my first
guess is that you have
not found all the directories where packages are loaded from. But an
''unknown'' command handler is also a possibility.
Edit:
One more possibility I forgot. Check and see if your software sets the auto_path variable. Check any directories added to the auto_path for
other packages.
This isn't a great answer for you, but I suspect it is the best you're going to get...
The procedure could be defined in a great many places. Your best bet for finding it is to use a tool like findstr (on Windows) or grep -R (on POSIX platforms) to search across all the relevant source files. But that still might not help! It might not be a procedure but instead a general command, which could be implemented in C and not as a procedure, or it could be defined in a packaged application archive (which are usually awkward to look inside). There are also other types of script-implemented command too, which could make things awkward. Generally searching and investigating is your best bet, but it might not work.
Tcl doesn't really differentiate strongly between different types of command except in some introspection operations. If you're lucky, you could find that info body tells you the definition of the procedure (and info args and info default tell you about the arguments) but that won't help with other command types at all. Tcl 8.7 will include a command (info cmdtype) that would help a lot with narrowing down what to do next, but that's no use to you now and it definitely doesn't exist in older versions.
I am trying to hack into an exe to find the implementation of certain functions and perform actions in an injected dll.
The exe is a sort of screen saver, and fortunately very simple, so it uses important strings to identify code sections.
My dilemma is that one of the functions, 'getaxis', is a virtual function. I know this thanks to the strings window and other telltale info on the string (Audioplayer.Tracklist::GetAxis) that i traced back to an rdata section
.data:01E204B0 off_1E204B0 dd offset aAudioplayer_to ; DATA XREF: _call_vfuncr
.data:01E204B0 ; _call_vfunc+26r
.data:01E204B0 ; "Audioplayer.Tracklist::Internal_GetTrack"
...
Using ida pro i have successfully traced the very function call, but I am unable to find the actual virtual function implementation.
So here's my problem:
1- I am ignorant on the subject, being a newbie in disassembling: is there a way to actually find a virtual function's implementation?
Ida clearly shows the various 'subs' in the "functions window", but there's a couple hundred of functions in there, and i'm hoping there's a better way of finding a virtual functions' declaration.
2- is there any association between a sub name and a virtual function. i was unable to find any.
So how can I find the actual virtual function declaration in disassembled code?
Is this possible at all?
Thanks.
Do you know what compiler/language was used to generate this program? I'm only familiar with how most C++ implementations generate vftables. "Knowing your enemy" is key to reverse engineering.
From the looks of it, those '_call_vfunc' functions may be some sort of implementation detail of some other language's compiler (say some random Pascal compiler, or whatever) which may have a need for retaining such metadata. call_vfunc may throw an error when a pure/nullptr entry is used in whatever they used for a vftable, hence the use of/reference to that string.
If call_vfunc is used to perform ALL virtual function calls, you could hook said function and log the vftable addresses it ends up using. Unless this is an overly complex screen saver, there shouldn't be too many vftables that are used. If IDAPython has any debugger APIs, you could possibly do all the logging via a Python script while debugging with IDA.
I have downloaded the MySQL Connector/C driver from the official website, the version that I believe is supposed to be released next to 5.6.
I then obviously wanted to use the library so I wrote a small application. During linkage, I however got a strange linker errors saying it cannot find the functions mysql_library_init() and mysql_library_end().
When I use a command to check for the functions inside the library, nm /usr/lib64/mysql/libmysqlclient.a > ~/Desktop/symbols, I indeed cannot find the functions the linker mentioned.
The functions I do find however are mysql_server_init and mysql_server_end, which are according to the documentation, marked as deprecated. (There are more functions in there too)
What am I doing wrong? I am using version 6.1.2 of the driver.
It seems like the problem is that the documentation is ahead of the code.
I am a DBA, not a C programmer, though I dabble in server internals. If the file include/mysql.h in the MySQL Server source files is any indication, the mysql_server_* functions are the ones you're looking for.
/*
mysql_server_init/end need to be called when using libmysqld or
libmysqlclient (exactly, mysql_server_init() is called by mysql_init() so
you don't need to call it explicitely; but you need to call
mysql_server_end() to free memory). The names are a bit misleading
(mysql_SERVER* to be used when using libmysqlCLIENT). So we add more general
names which suit well whether you're using libmysqld or libmysqlclient. We
intend to promote these aliases over the mysql_server* ones.
*/
#define mysql_library_init mysql_server_init
#define mysql_library_end mysql_server_end
"We intend to promote these aliases over the mysql_server* ones."
They promoted them in the documentation, apparently.
It looks like Bug #65887 was a report of the same problem, that they never really got around to doing anything with.
You might also find MariaDB's implementation of the C API "for MariaDB and MySQL" to be a viable and perhaps more agreeably-licensed alternative.
I've installed the Yojson library for OCaml via GODI:
http://martin.jambon.free.fr/yojson.html
I want to start an interactive ocaml session (i.e. via the ocaml command) and execute functions from the Yojson library e.g.
Yojson.Safe.from_string;;
How do I do this? The above command gives "Error: Unbound module Yojson". I've worked out how to compile via ocamlc with Yojson available, but I want to launch an interactive session instead.
I know this seems like a horrible beginners question but Yojson comes with no samples and minimal instructions so I'm really stumped. I've tried various combinations of "#load" and compiler switches and I'm stuck.
The tool you are after is called findlib. It is included in the base GODI installation. The tools that come with findlib allow you to easily compile against most OCaml libraries and use those libraries from a toplevel session (ocaml). The findlib documentation is fairly comprehensive, but here is a quick summary to get started.
To start using findlib from within a toplevel session:
#use "topfind";;
This will display a brief usage message. Then you can type:
#list;;
This will show you a list of all of the available packages. Yojson will likely be among them. Finally:
#require "yojson";;
where yojson is replaced by the appropriate entry shown by #list;;. Yojson's modules should be available for you to use at this point.
In order to distribute a function I've written that depends on other functions I've written that have their own dependencies and so on without distributing every m-file I have ever written, I need to figure out what the full list of dependencies is for a given m-file. Is there a built-in/freely downloadable way to do this?
Specifically I am interested in solutions for MATLAB 7.4.0 (R2007a), but if there is a different way to do it in older versions, by all means please add them here.
For newer releases of Matlab (eg 2007 or 2008) you could use the built in functions:
mlint
dependency report and
coverage report
Another option is to use Matlab's profiler. The command is profile, it can also be used to track dependencies. To use profile, you could do
>> profile on % turn profiling on
>> foo; % entry point to your matlab function or script
>> profile off % turn profiling off
>> profview % view the report
If profiler is not available, then perhaps the following two functions are (for pre-MATLAB 2015a):
depfun
depdir
For example,
>> deps = depfun('foo');
gives a structure, deps, that contains all the dependencies of foo.m.
From answers 2, and 3, newer versions of MATLAB (post 2015a) use matlab.codetools.requiredFilesAndProducts instead.
See answers
EDIT:
Caveats thanks to #Mike Katz comments
Remember that the Profiler will only
show you files that were actually used
in those runs, so if you don't go
through every branch, you may have
additional dependencies. The
dependency report is a good tool, but
only resolves static dependencies on
the path and just for the files in a
single directory.
Depfun is more reliable but gives you
every possible thing it can think of,
and still misses LOAD's and EVAL's.
For MATLAB 2015a and later you should preferably look at matlab.codetools.requiredFilesAndProducts
or doc matlab.codetools.requiredFilesAndProducts
because depfun is marked to be removed in a future release.