I have this linux executable which loads some so libraries and I want to know if is possible to patch it with ida for example and makes it include a new library?
It is a game server and it loads a so library which have functions for each skill, I want to duplicate the so library, include it together with the original and edit function skill numbers in the duplicated so library. So I can add new skills to the game. Is that even possible?
Related
I've been working with a programmer on an app and we've since gone our separate ways. I was passed on a copy of what was supposed to be the source code of everything at the end. However, I believe I'm missing a crucial file from the app build.
It's a pretty cool, but fairly basic 2D game. Built with Starling (gamua.com/starling) in ActionScript 3.
My question is, with all the files and assets mentioned below, is it possible to recover, reverse engineer, perhaps decompile, what I need to complete the app. Or will this project's code need to be re-written from scratch?
In my game 'build' I have following folders:
assets, bin-debug, extensions, libs, src, and system.
I am a bit of a noob in coding (as you've probably gathered), but it looks like I'm missing the .fla file from the 'src' folder. The contents of that src folder is:
com, utils (folders), Constants.as, Game.as, Main-app.xml, Main.as, Menu.as, Root.as
I was hoping that there is enough information in the .as files intact, that the restoring of the .fla to compile the build is not a big ask?
If other questions stand out to you, please ask.
Thanks!
Normally, Starling game is not built in the same way as a regular Flash game in the old days. You files look to me a lot like FlashDevelop project (there also should be .as3proj file somewhere in the root folder of the sources), which does not use FLA and compile the game from .as classes directly.
P.S. Or, maybe, Flash/Flex Builder project. Regardless, the possibility there were no FLAs to begin with is high.
I'm trying to generate a VxWorks 6.9.4.8 kernel configuration that is identical to another kernel workbench project. The Workbench 3.3.6 only allows GUI configuration.
Is there an underlying kernel configuration file, produced by the GUI, which can be replaced?
After updating the kernel configuration using the Workbench GUI, I see the following files have changed:
linkSyms.c,
prjComps.h,
prjConfig.c, and
prjParams.h
I guess my question is, which one, if any uniquely identifies the kernel as built?
prjComps.h will contain all the component's names, as you have chosen in your kernel configuration GUI.
First step to create new Kernel configuration based on some other Kernel configuration is to use GUI configurator and add the missing component in prjComps.h, Better use some diff tool like 'beyond compare', and keep reducing the differences by adding/removing the components. Remember not to edit this file directly, but via GUI configurator only. As the tool calculates the dependent component and adds/removes them.
Second step is to create the new prjParams.h as above.
The Workbench actually allows to use command line to edit Kernel configuration via vxprj tool in vxworks 6.9(this tool has been replaced by "wrtool" in vxworks 7), you can right click on the Image project and chose 'Open Wind River vxWorks 6.9 Developement Shell'.
If you want to add a component for e.g. telnet client (INCLUDE_TELNET_CLIENT)
, you can use the following command
vxprj component add INCLUDE_TELNET_CLIENT
To remove a component
vxprj component remove INCLUDE_TELNET_CLIENT
For more of vxprj tool, you can look up the documentation in the workbench itself.
The project configuration is held in a handful of files in the kernel project directory.
These are:
.project
.cproject
.wrproject
projectname.wpj
Files such as prjComps.h, prjParams.h prjConfig.c are all generated by the configuration tool, however these are not configuration files themselves. Instead, this is generated C code that contains, amongst other things, a list of selected components.
These files are also re-generated, I believe, when you rebuild the project.
As such, these are not really the authoritative source you are interested in.
For this, you need to look at the project files. In terms of a list of components, the most interesting is the .wpj file, which contains amongst other things a list of explicitly and implicitly included components.
The explicitly included components are those you manually selected in the Kernel Configuration GUI, the implicitly included are those that were then included to satisfy dependencies.
This distinction can sometimes make comparing kernel configurations tricky, then you may want to fall back on the generated files eg prjComps.h, however you should always remember that this is a representation of the configuration, not the source.
The .project etc configuration files are big and complex, but a decent diff tool, such as BeyondCompare can make comparisons of the project directories fairly easy
Thanks for the clue, #endTunnel. I looked at that file, and noticed that a few files get modified when I save my GUI selections.
prjComps.h - all the components #included in the kernel build
prjParams.h - the additional parameters set for the enabled components
prjConfig.c - the configuration and initialization calls for each module included.
'linkSyms.c' also gets modified. Not sure how that is used, yet.
I can now use diff to compare kernel configurations, and perhaps even duplicate a configuration (haven't tried that yet).
My workflow usually goes like this: i create a symbol in Flash IDE with textfields, containers, etc. Then I select "export for actionscript" and type in the classname (automatic declaration of stage instances, of course, is off).
Then i create a corresponding classfile in FDT and declare all this textfields and other objects that are in my symbol. This is pretty routine and boring process that takes a lot of time.
Is there a way to automate it? Maybe some plugin for flash IDE that will automatically create a class file based on symbol exported for AS?
Update: So, following the answer Pavel fljōt provided, i wrote my own command to accomplish this task. It is now available on Adobe Exchange here: http://www.adobe.com/cfusion/exchange/index.cfm?event=extensionDetail&loc=en_us&extid=3021022
You could use JSFL to work with .fla library. You can write a script that runs through library items, finds the ones exported for AS and creates .as file you need (if it's not created yet, not to overwrite your existing one for instance). (To create public properties you got to run through objects on symbol stage, grab their names and types to create appropriate fields in your class).
Worth to mention the great framework xJSFL, which can really help you to write more compact and elegant scripts.
We are currently using the RazorGenerator library to generate pre-compiled views for a project. Up until now we have been using the Visual Studio Extension to handle the generation, with these generated files also being committed to our repository.
This is causing bit of a pain point as we constantly have to resolve merge defects in a generated file. With that in mind I've set about to try and integrate the RazorGenerator.MsBuild target library into our build process so we can get away from storing the code-genned files in our repository.
So far I've disabled the VS Extension, and got the build target working as required however I've now lost intellisense and resharper support for the generated files as they are no longer part of the Solution.
I'm wondering if anyone else has come down this path before, Ideally what I'm trying to achieve is using the Build target to generate the cs files, removing the need to include these cs files in the repository, and still having Intellisense/Resharper coverage for the generated files.
Any thoughts?
I've resolved this problem by creating a an empty partial class for each of the cshtml templates which implements our own base class, which in-turn implements RazorGenerator.Templating.RazorTemplateBase.
By doing it this way we have access to all the publicly accessible properties and methods exposed on those classes which makes intellisense/resharper happy and at build time the templates .cs files are generated which do the heavy lifting for outputting the layout etc.
I want to give credit to all open source libraries we use in our (commercial) application. I thought of showing a HTML page in our about dialog. Our build process uses ant and the third party libs are committed in svn.
What do you think is the best way of generating the HTML-Page?
Hard code the HTML-Page?
Switch dependency-management to apache-ivy and write some ant task to generate the html
Use maven-ant-tasks and write some ant task to generate the HTML
Use maven only to handle the dependencies and the HTML once, download them and commit them. The rest is done by the unchanged ant-scripts
Switch to maven2 (Hey boss, I want to switch to maven, in 1 month the build maybe work again...)
...
What elements should the about-dialog show?
Library name
Version
License
Author
Homepage
Changes made with link to source archive
...
Is there some best-practise-advice? Some good examples (applications having a nice about-dialog showing the dependencies)?
There are two different things you need to consider.
First, you may need to identify the licenses of the third-party code. This is often down with a THIRDPARTYLICENSE file. Sun Microsystems does this a lot. Look in the install directory for OpenOffice.org, for example. There are examples of .txt and .html versions of such files around.
Secondly, you may want to identify your dependencies in the About box in a brief way (and also refer to the file of license information). I would make sure the versions appear in the About box. One thing people want to quickly check for is an indication of whether the copy of your code they have needs to be replaced or updated because one of your library dependencies has a recently-disclosed bug or security vulnerability.
So I guess the other thing you want to include in the about box is a way for people to find your support site and any notices of importance to users of the particular version (whether or not you have a provision in your app for checking on-line for updates).
Ant task seems to be the best way. We do a similar thing in one of our projects. All the open source libraries are present in a specified folder. An Ant task reads the manifest of these libraries, versions and so on and generates an HTML, copies into another specified folder from where it is picked up by the web container.
Generating the page with each build would be wasteful if the libraries are not going to change often. Library versions may change, but the actual libraries don't. Easier to just create a HTML page would be the easiest way out, but that's one more maintenance head ache. Generate it once and include it with the package. The script can always be run again in case some changes are being made to the libraries (updating versions, adding new libraries).