- I believe technically, it could work it required an Internet connection for key exchange. Otherwise, any code decrypting client side would always be able to beMessage 1 of 82 , Feb 11, 2013View SourceI believe technically, it could work it required an Internet connection for key exchange. Otherwise, any code decrypting client side would always be able to be hijacked. I think any basic encryption is good enough to prevent the basic thief. Even multi-rez is effective.
Sacha GriffinSouthern Digital Solutions LLC - Atlanta, GeorgiaOffice: 404-551-4275
On Feb 11, 2013, at 9:08 AM, jimbo <mrjimbo@...> wrote:Well , LOL, does this mean the plot thickens? Wonder how many are saving this post? Anyway, I have a favor to ask.. this has been a pretty brutal thread.. Some of the ego's here are bigger then my winter boots.. ( I'm ok with that except it's tuff to watch a few of you beat each other up so badly)Soooo getting past the ego thing..it's actually a good concept to have encrypted pano's and images etc.. Regardless of using HTML 5 or flash ..encryption to protect an image for you guys is a good thing not bad.. and quite frankly I like to see that developed for your use.. The worlds is just to full of thieves without proper laws to deal with it effectively.. This group has in it's mix some of the best heads I've been exposed to ... your all very very dedicated people..So maybe after taking a few deep breaths (assuming that this script works) how could this encryption be implemented to make it function as intended?I'll be a fly on the wall for a while on this I reckon..j ----- Original Message -----From: luminouslabsSent: Monday, February 11, 2013 2:47 AMSubject: [PanoToolsNG] Re: Html5 xml and image encyrption
I just became aware of your challenge this evening since I rarely read this list. Normally I would pass this by as a waste of time, but with the bragging about the difficulty, I couldn't resist.
It turned out to be dissapointingly easy.
I assumed you were using actual encryption (AES-256, etc...), so I took the difficult but reliable route of manually dissecting the SWF bytecode itself.
What I found was that your "encryption" isn't encryption at all, but rather simple obfuscation consisting of plain old base 64 encoding with 7 garbage characters prepended. Any of the image or XML files can be easily "decrypted" by the following python script:
f = open(inname)
data = f.read()
bindata = base64.b64decode(data[7:])
f = open(outname,"wb")
if len(sys.argv) != 3:
print("Usage: decode.py ")
This brings me to another issue. On your Pano Cocoon product page, you claim that "XML Encryption will encrypt the main .xml file in the project with 256 bit encryption, making it literally impossible to break the encryption."
There is nothing 256-bit about it. It isn't even real encryption. Obviously, the last part is false, but even real encryption can still be cracked since viewing requires decryption. If it used real encryption, my original approach would still have worked. This entire statement is false advertising.
--- In PanoToolsNG@yahoogroups.com, Trausti Hraunfjord wrote:
> Not moving goal posts? Tell that to Apple while you have that thought :)
> Actually you are right, simply because I didn't write exactly what I had in
> mind... I corrected that a bit later. People were saying that the
> encryption didn't work, and it does work perfectly. Both for the images
> and the xml. Same thing.
> People said they could get the images from OpenGL ... no proof, and not
> possible from what I learned by trying to do just that.
> Screenshots are possible, and then there is the possibility of shooting
> pictures of the screen with a camera too.
> Neither method gives the same result as having the original imagery. 100%
> protection is an illusion, but no protection is just being plain stupid.
> None of us would build our home without walls or doors... some protection
> is needed... and most of us use door locks on the exterior doors. That is
> what the encryption should be seen as. People can still walk past the
> house and steal pictures from the outer surface and even peek in the
> windows, but they won't get the same quality of imagery as if they were
> actually inside.
> Keep the pano if you like :)
> On Fri, Feb 8, 2013 at 6:11 AM, Jeffrey Martin wrote:
> > **
> > Trausti,
> > your original "challenge" was not to get the xml, rather, to make a useful
> > pano. don't move the goalposts, dude! this is what you said:
> > "Here you have a project that has been encrypted, and you are more than
> > welcome to take the images from the browser cache and do with them as you
> > like... or in some other magical way turn this into a usable panorama on
> > your end: http://goo.gl/**Q9wyB "
> > I guess if someone stole your pano, you would not care if they did it via
> > screenshots? Or you only go after them if they steal it "the right way" by
> > stealing the xml? :)
> > Anyway, i'm asking "what is your end game" not regarding this security,
> > but more in response to Sacha's comment. Seems like your tool would be much
> > better - and sell a lot more - if it was based on krpano.
> > your pano is still on 360cities, it will earn enough ad revenue to buy you
> > a beer when you come to prague. unless you want me to remove it?
> > cheers,
> > jeffrey
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2897 / Virus Database: 2639/6092 - Release Date: 02/09/13
- Hi, long and important discussion. With hacker skill into digital world we can do everything but i think that a pano-virtual tour would be published with aMessage 82 of 82 , May 20, 2013View SourceHi, long and important discussion. With hacker skill into digital world we
can do everything but i think that a pano-virtual tour would be published
with a mininum of protection to discourage the average user. So with Krpano
what's the best workflow with minimal protection?
View this message in context: http://panotoolsng.586017.n4.nabble.com/Html5-xml-and-image-encyrption-tp4656899p4657423.html
Sent from the PanoToolsNG mailing list archive at Nabble.com.