I saw allot of companies offering exe wrappers , but is there any in pdf side security programmatically ?
Well, you can encrypt the PDF. You can also use custom encryption handler and thus make your file unreadable with stock Acrobat or Reader (one will need to install your decryption plugin to Acrobat or Reader to make them understand your encryption). The problem is acrobat's DRM SDK (the one that allow you create encryption plugins) once had enormous cost (smth. like $25K to start). I don't know if this is still the case, though.
Another not-so-bad option is render everything to graphics - this makes text copying harder (though one can print everything and OCR it back).
The short answer is no. When you give someone the ciphertext, key, and cipher they will always be able to reproduce the plaintext. DRM fails universally for just this reason.
The long answer is that you can sometimes try little gimmicky tricks to prevent copying in some circumstances which may "work" if your audience doesn't try breaking it, but not in the general case. You can't really call something secure which is "safe as long as nobody tries to break it".
The PDF format itself has an "owner password" which allows the author to disallow readers from printing the document, modifying it, etc... Of course there's not actually any mechanism for preventing anyone from doing so. If you are trying to prevent the guys in the marketing department from printing it off or something, then maybe. But if you're releasing it out into the Internet, just assume that it can and will be copied however users see fit.
Related
My embedded linux gets its data files from an external source (sd card). As this media is easily detachable I'd like to protect it in a certain way.
First idea that comes in mind is to do encryption. I'm afraid though this would take too much processing power. My files are not deeply sensitive, but I don't want that people can put the card into their desktop and see/copy my files. I assume these people know how to mount a standard ext4 drive.
Content is initially loaded on to the disk via a desktop linux box, so the process should be
I wouldn't care too much if the solution is not hack-proof. Basically I want to avoid to have my content copied by the general copycat.
I'm not looking for a turn-key solution, but like to get some pointers into the right direction.
A simple XOR Cipher requires very little processing. The security is limited in the sense that if someone has a both the encrypted and plain-text data, by XOR'ing the two the encryption key is revealed. However so long as you can avoid someone being knowingly in possession of both, and the key itself remains confidential, it may meet your requirements of simplicity and security.
Obviously you need a longer key that the simple 8 bit one in the example in the link. The key itself can be arbitrarily long with no impact on performance.
Does windows clipboard store copied Strings locally, or, as with files, does it only deal with pointers?
If it does, is it possible to modify the clipboard to make a logfile of all Strings that are routed through it?
I would imagine this could be a dangerous tool against people who hide high entropy passwords somewhere deep in their system (maybe encrypted) and then just copy paste them where needed.
It's certainly possible -- there are plenty of commercial keyloggers (this one, for example) that can log text copied to the clipboard.
You're absolutely right that this is a security risk.
Yes, it looks like you can actually log everything that goes through the clipboard with the AddClipboardFormatListener API call: relevant SO question here. Simply pass the handle of your window in as the only parameter. The SetClipboardViewer function will also work for older versions of Windows.
This is certainly a security risk.
This Microsoft forum suggests that the clipboard is stored entirely in memory, and this part of MSDN talks about receiving a global memory handle on the clipboard.
I'm putting together a mobile version of a webpage which consists entirely of client art. For the old-fashioned desktop version, I just used PNGs, but I really wanted to use SVG for mobile. SVGZ would be smaller and resolution independent, so it seemed like a perfect use case.
But the client is worried that, once his art is online in SVG, anyone could download the files and use his art illegally (he's had stuff he worked on pirated before, so he takes this pretty seriously.) This had never occurred to me until he brought it up, but the SVG would basically be his original source art.
I was wondering if there's any way to prevent the SVG files from being accessed by the user. As far I know this is impossible -- making the files available to the user-agent means making them available to the user -- but I wanted to ask around to be sure.
Thanks for any help.
No, this is impossible. If a web browser can request the files for display, then any computer anywhere can request the files and save the direct results.
Serving up intentionally degraded artwork (e.g. rasterization) is the only way to prevent people from having the originals. Of course, a determined thief could still re-trace the PNG and get a vectorized, resolution-independent close approximation of the original.
Your client could alternatively:
Include copyright comments in the source, proving ownership. (Yes, a thief could delete these.)
Include 'hidden' elements (0% opacity or placed under another item), proving ownership. (Yes, a thief could delete these.)
Use data steganography in the source SVG to watermark it (e.g. vary the decimal values in a path in a manner minor enough to not effect the result, but still embed custom data). (Yes, any thief suspecting this could lower decimal precision or transform all values in a manner that might remove this.)
Trust in the law to protect his works, or provide a recourse if they are stolen.
Trust in the goodness of most of mankind to not do this.
Decide that theft is the sincerest form of flattery, and not worry about it. :)
The POP3 client is an homework assignment at one of my courses. It has to be done in Qt from scratch. Target platform: Linux (Ubuntu).
What solution would you recommend when it comes to mail storage ? Since it is a homework assignment it has to be done "right"...
P.S. For now I think I would go with plain text, each message in a separate .txt and another file as an index. I'm not sure how this will be handled when the folder with the messages will get really big.
If my options where totally open, I'd pick a database tool (MySQL is overkill, SQLite would be perfect) because the tool can deal with sorting, IO access, file locks (if multiple instances are possible), deleting, defragmenting/cleaning/vacuuming.
On the other hand... there's a pair of standards for storing mail: MBOX and maildir (nice primer here) which it wouldn't be too hard to adopt into your programme.
What of attachments, text encoding and transfer encoding? That's where the real work's going to lie (unless it's out of scope of the assignment).
I want to code a trading bot for Magic: The Gathering Online. This bot should wait until someone offers to trade, accept, look through the cards available from the other trader (the information is shown on screen), and perform other similar functions. I have several questions:
How can it know that someone is offering a trade?
How can it know that the other trader has some card (the informaion is stored in pictures)?
I just cannot imagine right now how to do it, I have no experience with it, until now I've been coding only console programs for my physics neŃessities.
First, you should note that some online games forbid bots, as they can give certain players unfair advantages. The MTGO Terms of Service do not seem to say anything about this, though they do put restrictions on anything that might negatively impact the service. They have also said that there is a possibility they will add an API in the future, so they don't seem to be against the idea of automation, but are not supporting it at the moment. Tread carefully here, but it looks like it should be OK to write a bot as long as it is not harmful or abusive. This is not legal advice, and it would be a good idea to ask the folks who run MTGO for permission. edit since I wrote this, it has been pointed out that there are lots of bots already, so there should be no problems writing bots.
Assuming that it is not forbidden by the terms of service, but they do not have an API, you will have to find a way to detect what's going on, and control the game automatically. There's a pretty good series of articles on writing poker bots (archived copy), which has some good information on how to inject a DLL into an application, scrape the screen, and control the application. That might provide you with a starting point for doing this sort of thing.
You might also want to look for tools that other people have already written for doing this. It looks like there are several existing MTGO bots, but they all seem a bit sketchy (there have been some reports of them stealing passwords), so be careful there.
Edit
Since this answer still seems to be getting upvotes, I should probably update it with some more useful information. Since writing this, I have found a great UI automation system called Sikuli. It allows you to write programs in Python that automate a GUI. It includes image recognition features which make it very easy to recognize buttons, cards, and other UI elements; you just take a screenshot, crop it down to include just the thing you're interested in, and do fuzzy image matching (so that changing backgrounds and the like doesn't cause the match to fail). It even includes a custom IDE that allows you to embed those screenshots directly in your source code, so you can see exactly what the code is looking for. Here's an example from the documentation (apologies for the code formatting, doing images inline in code is not easy given StackOverflow's restricted subset of HTML):
def resizeApp(app, dx, dy):
switchApp(app)
corner = find(Pattern().targetOffset(3,14))
drop_point = corner.getTarget().offset(dx, dy)
dragDrop(corner, drop_point)
resizeApp("Safari", 50, 50)
This is much easier to get started with than the techniques mentioned in the article linked above, of injecting a DLL into the process you are debugging. Sikuli runs entirely at the UI level, so you never have to modify the program you are automating or worry about changes to the internals breaking your script.
One thing it is a bit poor at is handling text; it has OCR features, but they aren't all that good. If the text is selectable, however, you can select the text, copy it, and then look directly at the clipboard.
If I were to write a bot to automate something without a good API or text-based interface, Sikuli is probably the first tool I would reach for.
This answer is constructed from my comments.
What you are trying to do is hard, any way you try and do it.
Arguably the easiest way to do it is to totally mimic the user. So the application presses buttons, moves the mouse etc. The downside with this is that it is dependant on being able to recognise the screen.
This is easier if you can alter the games files as you can then just skin ( changing the image (texture)) the required cards to a single unique colour.
The major down side is you have to have the game as the top level window or have the game running in a virtual machine. Neither of which is ideal.
Another method is to read the processes memory. You may be able to find a list of memory locations, which would make things simpler, otherwise it involves a lot of hardwork, a debugger to deduce the memory addresses. It also helps (a lot) to be able to understand assembly.
The third method is to intercept the packets, and alter them. This is easier that the method above as it (at least for me) is easier to reverse engine the protocol as you have less information to deal with. It is just a matter of setting up a packet sniffer and preforming a action with one variable different (for example, the card) and comparing the differences.
The thing you need to check are that you are not breaking the EULA. I don't know how the game works, but most of the games I have come across have a EULA that prohibits (i.e. You get banned) doing any of the things I have mentioned.