I need any method to protect pe file resources form editing and thank you very much..
editing like:
1) open pe file as binary file and search about a string then edit it.
or
2) edit assembly code like "jne"(jumb if not equal) to "je"(jumb if equal)
**best regards**
Use exe packer. There are plenty of them, so I'm sure you'll have no problem to pick one that suits your needs.
http://en.wikipedia.org/wiki/Executable_compression
If that's a commercial application and you are willing to spend some money on good protection, consider Themida: http://www.themida.com/
Related
There are some files like .bashrc or linux config files (cannot remind them right now), which contain lines of information inserted by different software/apps/libraries, e.g. when they were installed.
Is there any way to differentiate information in such files, i.e. to know which lines belong to which software? Maybe there is some convention for that? If yes, where can I learn about it. If no, how do software clean up their configuration and other property in OS files on uninstall?
A note about tags:
I mentioned low-level languages as well as linux and shell because I think only guys from those techs may know the answer.
"Is there any way to differentiate information in such files, i.e. to know which lines belong to which software" - No.
You are dealing with plain text files and there is no way to tell who put what into those files. It may have been a program you installed/ran or it may have simply been a user editing the file in a text editor - you don't know.
You also have no way of knowing whether the contents of the file is well formed or not until you parse it.
If the file does not parse (is messed up) you have two options: 1) read what you can and discard everything else. 2) give up and tell the user the file is garbage
In any case, you cannot trust the information in the file. Anyone could have put it there.
I wanna perform some check for PDF files.
I wish to check the width of pages and also figure out if the file contains double-pages.
Is there any frameworkfor that?
Thanks!
Greetings
Magda
Indeed there is. PDF::API2 looks like it will might you what you need.
It's designed for creation and modification of PDF files. If not, search CPAN for other PDF APIs.
I don't fully understand your question, but for a start check out these utility scripts that come with the CAM-PDF distribution. Look at the lower half of this web page, e.g. getpdfpage.pl.
A lot depends on the complexity of your PDFs, though.
is it possible to change text and images in a fla file without ever opening it up and then making the swf via command line? I want to make a flash template and save the fla. Then be able to update my text and image name and convert it to swf. I have one template but tons of different text options and background images. It would be nice to be able to copy the master.fla twenty times and just change the source code (will do this from command line) and then convert to swf (via command line).
Any help would be appreciated.
With CS5, you can do half of what you're asking today, by using the XFL file format instead of FLA. Instead of a binary blob, you get an editable XML file and a tree of separate asset files: PNGs, AS3 files, etc. You can then modify the XML or AS3 files programmatically to get your variants.
(A CS5 FLA file is really just a zipped up version of the XFL, but there's no advantage to using that instead of an XFL. In CS4 and previous, FLA was a proprietary binary format.)
The missing piece is an XFL compiler. Adobe currently provides no such thing, and the third party market hasn't yet produced one.
You could use a systems automation tool to drive the Flash Professional environment through the compilation steps. On OS X, for example, either Automator or AppleScript should be able to do what you want. It'll just have more overhead than the command line compiler you were hoping for.
I agree with Jason, there are a lot of alternatives to what you suggest. Keeping content out of the SWF is good practice actually. This is a good way to avoid large files!
Depending on what you 're looking to achieve, there are a lot of solutions available. XML is an option, JSON another.
If you're looking to build a template, any of the above would seem appropriate.
It sounds like you're working from the Flash IDE, as Jason suggests you may want to have a look at another IDE, such as FlashDevelop, FDT or FlashBuilder as they make coding with AS3 a lot easier.
If someone sends me a document (.pdf,.doc,.xls, ppt, .ogg, mp3, png, etc) without the extension, how can I determine the file type? The /usr/bin/file command doesn't always guess right or it simply says that I have a Microsoft Office document. I would like to know exactly so I can add the extension to the file name.
You can come up with your own rules by adding them to /etc/magic
man file for more details. It is tricky to always get these correct however, I have had reasonable success.
Try mimetype(1).
For Perl, look at File::MimeInfo.
Some of the other posters thus far appear to neglect a few things.
File::MimeInfo uses the same MimeInfo database used by 'file' to identify files. So That's unlikely to do anything different.
File::Type is likely to be interesting though, as it relies only on itself, but this leads to a comically long script full of 'if' statements. But this is, by its very nature, unlikely to cover things 'file' already doesn't cover.
The best you can do with unknown filetypes is try cracking them open with a hex-editor, or running them through 'strings' and seeing if you recognise anything. If you manage how to Identify a file, you may wish to go for File::Type as your solution because as far as I can make out, its at least easy to extend.
You can use the Perl module: File::Type
I need to be able to GZip compress a file in an Excel VBA function. Specifically I need to be able to use the 'deflate' algorithm.
Is there a way to do this without having to exec a command line application? With no dependency on external tools the code will be more robust.
Ideally the code would make use of pre-installed VBA or COM library functions - I don't want to have to implement this logic myself or install DLLs etc.
If possible, I want installation of the function to be as simple as adding a .xla to the available Excel Add-Ins. No DLLs, EXEs, registry entries etc. required.
Edit Can I make use of the .NET GZipStream to do this?
VBA (which is really a dialect of VB6) is slow for these kind of applications. I remember I once implemented Shannon-Fano algorithm on VB6 and on C, the C version was about 10 times faster, even after being turned into a DLLMain and called from there rather than on a command-line executable.
There are lots of COM DLLs that provide compression services, both open source and shareware, and some of them implement GZIP's deflate algorithm. It'd be really simple to just call one function from such a DLL from your VBA code to do the compression on your behalf.
I understand your being reluctant on using something external to your application, though in this case you might have to apply an exception for performance's sake.
In an effort to completely spoil your fun, examine file ZIPFLDR.DLL on windows\system32. you may also like to take a look at these links:
This has an example of how to do what you want (zipping using windows built-in ZIP capabilities) from VB.NET, it shouldn't be much different from VBA or VB6:
Transparent ZIP with DLL call
This one has a sample application on VB6 using windows built-in capabilities to zip (in ZIP rather than GZIP format, of course): Using Windows XP "Compressed Folder" shell extension to work with .zip files
Found both thru googling, you should be able to find more/better examples.
OK, I think I have an answer for you.
zlib is a library written by the guy that wrote the deflate algorithm you don't want to implement. There is a win32 DLL available. Here's the FAQ regarding using it from Windows:
http://www.zlib.net/DLL_FAQ.txt
Check out question 7. The authors don't seem too keen on Windows users, and don't seem at all keen on VB users, but as long as they're kind enough to provide the library we can do the rest.
If this is enough to help you, then great. If you want help with calling the C library from VBA add a comment and we'll figure it out. I haven't done any VB-to-C calls in years--it sounds like fun.
It seems that you want to open a bottle of wine but you definitly refuse to use a bottle-opener. As long as there is no VBA function allowing the GZipping of a file, you will not be able to do the job without some external ressource such as a dll or exe file.
If somebody wanted to compress files without relying on 3rd-party software they would generally implement it as a COM object/DLL so it would be available to more than just Excel. If somebody wanted to incorporate zip functionality into Excel they would use 3rd-party tools so they wouldn't have to re-implement the algorithm. So you're swimming against the tide. However...
http://www.cpearson.com/excel/SaveCopyAndZip.htm
There are two versions. The COM Add-in version "...allows you to zip any workbook that has been saved to disk (but it may be in an unsaved state)." It relies on a Moonlight Software component but all the components and set-up are contained in the installer. It's not quite public domain but the license is less restrictive than the GPL. The end result is an Excel add-in (that uses a 3rd-party component).
But if you really, truly don't want any dependencies on external tools you're either going to have to implement the compression algorithm yourself or wait until Microsoft builds that functionality into Windows and exposes it through Excel.
I hope this helps.
If you want to implement the algorithm in VBA, you would need to (in VBA) save the spreadsheet and then use VB's I/O functions to open the file, deflate it, and save it again. For all intents and purposes it's identical to writing an ordinary VB application that works on a file. You might need to put the VBA macro in a separate workbook to avoid "file in use" types of errors, but if you reopen the file as read-only and save it with a different filename you should be OK keeping everything in one workbook.
But I'm almost certain that shelling out to gzip from within the VBA would be functionally identical and infinitely easier.
EDIT: Some code. It didn't fail when I ran it, so it's OK to keep everything in the same workbook.
Sub main()
ActiveWorkbook.Save
Open "macrotest.xls" For Binary Access Read As #1
Open "newfile.zip" For Binary Access Write As #2
'do your stuff here
Close #2
Close #1
End Sub