Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
How can I prevent the user running my web page after downlading the page source?
We can't prevent downloading the source code, but can encrypt it.
But it doesn't good enough for me, because the encrypted code can work after downloading.
Thank in advance.
As a general rule, if the code runs on a remote machine it can be manipulated so they can execute it anyway.
You can make this more difficult through code obfuscation or by implementing some sort of DRM, but I would suggest that this will largely be more trouble than it's worth (since it just takes one person to break it and your code is back out).
1) You could, for example, require that some key be downloaded from a site you control before it'll execute, but the recipient might simply sniff their traffic and pass that value to the game themselves.
2) Or you could possibly set up your game to stream each of the levels or some important aspect of it to your game client, but again, there's not a whole lot stopping someone from just reading these aspects and implementing this mechanism themselves.
3) Perhaps you could encrypt these level packages dynamically on the server with a time-based key, but it just takes that one bored programmer with the technical know-how to reverse-engineer what your method is.
4) Another option that comes to mind is requiring some regular polling to a server you control and requiring some sort of response, but again, if your client can predict what this response is supposed to look like, it's easy for someone to rewrite the game to talk to their own program instead of your server.
5) You could also daisy chain a ridiculous number of dependencies of your javascript logic (breaking your own code into a number of dependencies) so it's slightly more difficult for another user to rebuild the required paths on their system. This might be useful to put off a casual user, but I doubt it'd put off a more knowledgeable user.
All in all, I'd suggest that you simply make the game available as is. Various game companies larger than you have attempted to implement DRM measures of their own with disastrous results (when they don't work as advertised) or just plain annoying for the end user.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm a C# developer, and use XAML for user interfaces. Lately I've been wondering something regarding HTML5+JavaScript development (used in Universal Windows App development, as well as for websites). Javascript is compiled and executed at run-time on the client device. So any user can go into the folder where they're stored on computer, and see all the code in it, right?
There is no unreadable alternative for js and html5. That's why so many websites are so slow in adopting html5 video and replacing adobe flash.
But if your entire application is client side and you worry about your code being stolen you're doing something wrong. Almost any application requires serverside code that isn't accessible.
And it doesn't matter anyway, who cares about some js that makes a div draggable or moves some html around.
I dont think readable javascript code is of any value...what matters is the server side code like php or ASP which really matters in the security of the websites
And even if the developer didnt want the user to read the javascript framework.. what option does he/she have to prevent it..?none!
The client side code is indeed visible by the client. If something is available client side, then you won't need a round trip to the server to get it.
For example you could imagine a simple calculator application. You could write it client-side, in Javascript, the app can ouptut the calculations immediately. Or you could write it server-side (in wathever language you want), which means you need to ask the server for the calculation (with an ajax request probably), and wait for it to respond.
Also some things doesn't make sense on the server-side. Pretty much any action that changes the DOM, which only exists client-side, in the browser.
I wrote about this on my blog a while back, see Protecting Your Code,
as an addendum to my free ebook, Programming Windows Store Apps with HTML, CSS, and JavaScript, 2nd Edition.
The short of it is that JS code it not protected, though you can make things a little more difficult with minification/uglification like many website authors do. You can also take steps by putting some of the code you care about into Windows Runtime Components written in C++ (C# can be decompiled). The only really secure solution is to have code on a server, and draw from that in an app which of course doesn't work for all cases, but is an option.
Note that some of my comments in that blog from 3 years ago might be a little dated. I believe that current Windows Store policy now allows you to load code from a remote server at run time.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Aloha, Stackoverflow.
I frequently come across web applications, and wonder to myself, "How could I write a script/application which would interface with that?" (purely academic, not for spamming purposes!).
For example, the website Omegle; people have written Python scripts to interface with the website and run a chat without opening the browser... how? I will admit that WEB programming is not my strongest area, but I would really like to know how one could extract the protocol being used from such applications, and use this knowledge to create custom apps and tinker with the service.
So basically, how can I figure out the inner workings of a web app (ie. imeetzu.com such that I can write code to interface with it from my desktop?
Thank you in advance!
You'll need a set of tools to start with:
A browser with a debugging window (Chrome is particularly good for this). This will allow you in particular to access the network calls that your browser directly makes (there's a caveat coming), and to see:
their content
their parameters
their target
A network packet sniffer to trace down anything that goes through Flash (or WebSockets). I'm quite fond of Ethereal (now called Wireshark), though if you're in the US, you could be breaking the law by using it (depends on the use you make of it). This will allow you to see every TCP frame that enters and leaves your network interface.
The knowledge you will need:
Ability to identify and isolate a network stream. This comes through practice
Knowledge of the language the app you are trying to reverse-engineer is written in. If JavaScript isn't your cup of tea, avoid JS-based stuff
Maths and cryptography. Data may very well be encrypted/obfuscated/stegg-ed from time to time. Be aware and look out for it.
In this particular case, looks like you might have to deal with Flash. There are additional resources to help on this, although all of them are non-free. There is one particularly good Flash decompiler called SoThink SWF decompiler, which allows you to turn a SWF into a FLA or a collection of AS sources.
That's all for the tools. The method is easy - look what data comes in/out and figure out by elimination what is what. If it's encrypted, you'll need IVs and samples to hope to break it (or just decompile the code and find how the key/handshake is done). This is a very, very extensive field and I haven't even touched the tip of the iceberg with this - feel free to ask for more info.
(How do I know all this? I was a contributor to the eAthena project, which reverse-engineered a game protocol)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a method I'm testing right now for hiding javascript so that the user can't go around searching for it in the source files.
The method is this:
You have a bunch of javascript files included to make your application work. Libraries like jQuery, dojo, and your own code. This is pretty standard.
There is one critical piece of javascript code without which the app will not function, nor will any curious user be able to make heads or tails of the app without it. This critical piece does not get loaded by script tags. Instead, a small unobtrusive script calls to a database and returns the javascript in a big long string.
This string gets eval()-ed to make it live code. But the code was dynamically generated, so it won't show up if the user is looking through the source code or saves the website. Furthermore, you can add some kind of a salt or time-stamp to prevent users from trying to trick the database into revealing your javascript kernel.
I'm trying to get feedback on this from the community, and most of the examples I've turned up for hiding javascript with server-side code has just been people wanting to to include a .php file in the tags instead of .js. This is totally different.
So there you have it. Is this a good idea? What are the weaknesses?
eval() is generally frowned upon, but regardless, the big weakness is that I can simply sniff the HTTP requests and get your script. Obfuscation can make this more inconvenient, but with a good debugger its not that hard to follow a stack trace and get a good idea of what is occurring.
Even if the resource is transferred over SSL, it can be perused/manipulated once it has been loaded by the browser. To test this, I went to a secure website and examined a raw TCP response (both synchronous and asynchronous using XML HTTP) using SmartSniff. As expected, it's encrypted and unreadable. However, the same requests are all visible as plain text in Chrome's network activity inspector.
It's trivial to make Javascript code unreadable by humans (and even highly resistant to reverse engineering) - and you don't need to hide it in a of of other code. But why? Generically, the name given to this kind of code is malware.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm interested in producing some sort of multiplayer RPG as a purely browser based game, with little or no plugin requirements. Having done quite a bit of research I've arrived at the following plan. I'm aware that some of the tech I'm referencing here is not adopted across all browsers ( specifically IE ) but I'm willing to accept that for the moment.
Also - I'm aware that an MMO is a lofty goal to strive for in any case, but having done lots of smaller projects in the past in a similar direction, I feel like I want to give this a really good go finally.
So heres a rough outline, I'd love to hear of glaring problems anyone can see in this arrangement:
CLIENT:
WebGL / Javascript ( probably three.js ). Use browser local storage to hold game assets, accepting that deleting the browser cache will remove these.
MESSAGING:
encode messages between client / server using google protocol buffers, for convenience and size reduction. Message delivery would be via WebSocket.
GAME SERVER:
running on top of gevent in python ( looks to be a good solution for dealing with many concurrents ). Would be built using the sharded pattern, based on the design here:
DB SERVER:
MySQL for the database, PHP acting inbetween the game server and the DB.
DETAILS:
I intend to have the game server update an individual client roughly 15-20 times per second, and use client-side prediction to fill in the gaps. Clients may send key input / messages to the server in the region of 30 fps. I'd prefer to go for an experience that is as close to realtime as possible, rather than turn-based. My main concern is the TCP based protocol of WebSocket, will this make the whole thing impossible?
Does this solution seem realistic to SO?
many thanks,
You generally get 5MB of space with the localStorage API. If you really have a 3D game with sound/music, that's going to get eaten up really quickly by your assets (how big is a good-quality mp3 these days?). You'll need to be super aggressive with compressing your assets and most likely have to come up with a mechanism to stream stuff in and out of local storage while the game runs.
I would ask why you need PHP between the game server and the database. Can't the game server speak directly with the database and save you some work?
Good luck with your project.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I was wondering what would be the most ethical way to consume some bytes (386 precisely) of content from a given Site A, with an application (e.g. Google App Engine) in some Site B, but doing it right, no scraping intended, I really just need to check the status of a public service and they're currently not providing any API. So the markup in Site A has a JavaScript array with the info I need and being able to access that let's say once every five minutes would suffice.
Any advice will be much appreciated.
UPDATE:
First all thanks much for the feedback. Site A is basically the website of the company that currently runs our public subway network, so I'm planning to develop a tiny free Android app for anyone to have not only a map with the whole network and its stations but also updated information about the availability of the service (and those are the bytes I will eventually be consuming), etcétera.
There will be some very differents points of view, but hopefully here is some food for thought:
Ask the site owner first, if they know ahead of time they are less likely to be annoyed.
Is the content on Site A accessible on a public part of the site, e.g. without the need to log in?
If the answer to #2 is that it is public content, then I wouldn't see an issue, as scraping the site for that information is really no different then pointing your browser at the site and reading it for yourself.
Of course, the answer to #3 is dependent on how the site is monetised. If Site A provides advertistment for generating revenue for the site, then it might not be an idea to start scraping content, as you would be bypassing how the site makes money.
I think the most important thing to do, is talk to the site owner first, and determine straight from them if:
Is it ok for me to be scraping content from their site.
Do they have an API in the pipeline (simply highlighting the desire may prompt them to consider it).
Just my point of view...
Update (4 years later): The question specifically embraces the ethical side of the problem. That's why this old answer is written in this way.
Typically in such situation you contact them.
If they don't like it, then ethically you can't do it (legally is another story, depending on providing license on the site or not. what login/anonymousity or other restrictions they have for access, do you have to use test/fake data, etc...).
If they allow it, they may provide an API (might involve costs - will be up to you to determine how much the fature is worth to your app), or promise some sort of expected behavior for you, which might itself be scrapping, or whatever other option they decide.
If they allow it but not ready to help make it easier, then scraping (with its other downsides still applicable) will be right, at least "ethically".
I would not touch it save for emailing the site admin, then getting their written permission.
That being said -- if you're consuming the content yet not extracting value beyond the value
a single user gets when observing the data you need from them, it's arguable that any
TOU they have wouldn't find you in violation. If however you get noteworthy value beyond
what a single user would get from the data you need from their site -- ie., let's say you use
the data then your results end up providing value to 100x of your own site's users -- I'd say
you need express permission to do that, to sleep well at night.
All that's off however if the info is already in the public domain (and you can prove it),
or the data you need from them is under some type of 'open license' such as from GNU.
Then again, the web is nothing without links to others' content. We all capture then re-post
stuff on various forums, say -- we read an article on cnn then comment on it in an online forum,
maybe quote the article, and provide a link back to it. Just depends I guess on how flexible
and open-minded the site's admin and owner are. But really, to avoid being sued (if push
comes to shove) I'd get permission.
Use a user-agent header which identifies your service.
Check their robots.txt (and re-check it at regular intervals, e.g. daily).
Respect any Disallow in a record that matches your user agent (be liberal in interpreting the name). If there is no record for your user-agent, use the record for User-agent: *.
Respect the (non-standard) Crawl-delay, which tells you how many seconds you should wait before requesting a resource from that host again.
"no scraping intended" - You are intending to scrape. =)
The only reasonable ethics-based reasons one should not take it from their website is:
They may wish to display advertisements or important security notices to users
This may make their statistics inaccurate
In terms of hammering their site, it is probably not an issue. But if it is:
You probably wish to scrape the minimal amount necessary (e.g. make the minimal number of HTTP requests), and not hammer the server too often.
You probably do not wish to have all your apps query the website; you could have your own website query them via a cronjob. This will allow you better control in case they change their formatting, or let you throw "service currently unavailable" errors to your users, just by changing your website; it introduces another point of failure, but it's probably worth it. This way if there's a bug, people don't need to update their apps.
But the best thing you can do is to talk to the website, asking them what is best. They may have a hidden API they would allow you to use, and perhaps have allowed others to use as well.