When I was looking at the www.bing.com/maps html source file I came across some
strange "streetsidePrefetchFileUrls" URLs to .xap.png archives:
For exmaple:
hxxp://c0.ecn.catalogservice.virtualearth.net/cs/dc/pf/Xaps/bcbc3954e568c46cf8c3cc00737da32c_Microsoft.Maps.Framework.xap.png
This file has a PNG Header and contains an IDAT chunk. The IDAT chunk doesn't contain pixel data but a (corrupt) PKZIP archive with Microsoft Maps DLLs inside.
Does anybody know why Microsoft uses PNG as a container for xap Archives?
I've tried to unpack that archive with unzip and 7z. They all detect the ZIP-Archive inside the PNG but abort unpacking with an error.
Yes I noticed this they changed to this kind of protection just before the map app api came out of Beta. I presume it is their way of providing some protection for xap code from 3rd party developers, we have tried lots of ways to decrypt these without any luck but the code for it must be in the initial silverlight code so with a lot of decompiling you could probably find it
Many of the Bing Maps App's available on http://bing.com/maps contain proprietary algorithms and code. The png encoding is there to help prevent people from decrypting the XAP files and decompiling them. That said, if there is something you are trying to figure out how to do then try asking that question instead.
Related
I am confused a bit about .bin files. Basically in Linux we use elf, .ko type of files for upgrading the box or to copy in it . But, while upgrading a NAND flash in router or any Networking Gaint products why always .bin files is preferred. Is this is something like converged mix of all the OS related files. Does it possible to see the contents of a bin file. How to play with it. It is something like contents of BootROM. How is is prepared? How do we create and test on this. How Linux support for this. Any historical reasons behind this?
Speaking about routers, those files are usually just snapshots of a router's flash memory, probably compressed and with some headers added. Typical things are a compressed squashfs image or simply gzip'ed snapshot of memory.
There is no such thing as .bin format, it's just a custom array of bytes and every vendor interprets it in some vendor-specific way. Basically this extension means “it's not your business what's in the file, our device/software will handle it”. You can try to identify (thnk, reverse-engineer) what's actually in those files by using file utility or just looking at those files through a hex editor and trying to guess what's going on.
I really want to know what the XAP file on Windows Phone 7 is; how important it is; and how I can create it. Could you help me?
XAP is the application package - it is the distributable unit that allows you to install the application on a device (or emulator). Basically, it is a ZIP file with a different extension. If you change XAP to ZIP, you'll be able to read its contents fairly easy.
The XAP file format was inherited from standard Silverlight, and since WP7 is built around the same fundamental core, the file format remained unchanged.
Here is a pretty good description of what it does (remember, that even though it talks about Silverlight, the same main idea applies to WP7):
http://beyondrelational.com/blogs/dinesh/archive/2010/08/18/what-is-xap-file.aspx
In addition to Dennis' excellent post, one other thing about a XAP file - it's a ZIP file - so if you want to look inside one, then just rename it to .zip and then open it using a normal ZIP browser (e.g Windows explorer)
I'm working on a WinForms C# 3.0 / .NET 3.5 project involving building some canned reports. One of the requirements of the project is to export to PDF format, and currently doing so to disk is working just fine. The question was raised, however, if it's possible to export the file to a stream and open it directly in the native viewer on the client, skipping entirely writing it to disk. I know that this is somewhat possible with ASP.Net through the use of Response.Write() headers and the like, but I need to try to do this with standard WinForms/WPF, and I've exhausted my own ideas for it. Anybody have any insight on how it might be done, if it's possible at all? Or does the file have to be written to disk first, then opened separately?
I think it is important that you ask yourself what you accomplish if you bypass the file system. Writing to a the standard temporary folder is a perfectly acceptable solution. This is typically how browsers let you view media files and pdfs. I would concentrate on writing a nice cleanup function, that removes the temporary file after it has been create. Also what would be the purpose of exporting to PDF if you are not saving the file?
Under Unix / Linux you could have made a named pipe in the file system. This make sense if you have a huge media stream that you want to buffer between applications. In the PDF case you win very little.
Export to a temporary folder. It is Ok.
You will need to write the PDF to a temp directory.
The only way to display a PDF from an in-memory stream is to embed a third-party PDF viewer control
I've an application, that uses encrypted (txt) files to store data. After investigating the decompiled assembly I concluded that it's a file of some DBMS. So how can find out which DBMS is this application using to store it's data, so that I can attach that file to the correct DBMS.
This is little application and there is no license problem. I can just ask the owner to gimme the data, but just curious to solve this myself.
MORE INFO:
Platform is Windows, and after trying couple of decompilers I concluded that it WAS written in Visual C++. However I couldn't fully decompile this exe, otherwise I just could find out it from the source code.
A couple ideas.
If opening the file in a HEX editor doesn't give you any information (like a magic identifier at the start of the file, which you can pop into google, then:
Use the depends tool from microsoft to grab a list of the DLLs being loaded by the application. Chances are whatever DBMS it's using is contained in an external library.
If the first two suggestions yield nothing, load the executable into IDA pro freeware and have a look at the code which is creating these files.
I don't quite understand how Silverlight code works within the browser. Are the assemblies downloaded to the client machine? Is there any chance of the code getting decompiled using Reflector or some similar tool? If so, what options does one have to protect the code? Do .net obfuscators work with Silverlight?
Whenever you are in a web browser, all client side code is downloaded to the machine and can be examined by the user. This goes for Javascript, Flash, and Silverlight.
If you have proprietary code that absolutely must be hidden then you need to put it on the server and expose an API that the clients can call to show information to the user.
To view a Silverlight application the client download a .xap file that contains the dll and one configuration xml and optional resources. The dll contains compiled c# code that runs in a Silverlight runtime in client machine. Silverlight runtime is basically a subset of complete .net runtime. So the point is user gets the code in dll and then can use tools to get original source code. So at most you can do is obfuscation. Still for very critical code that should not be the option. You can use some other way (WCF or other webservices to hide some part of your code may be) if it shouts your need.
If you want to see just how easy it is to look at the code in a silverlight app just run SilverlightSpylink text by FirstFloor. As long as your have .NET Reflector installed you will be able to see (as you interact with the app) all the source code including the xaml files.
Since the code does get downloaded to the client (and even trying to prevent it with pragma no-cache won't work since they can hit the URL) you will need to protect your code by keeping important logic on the server.
If your afraid some one will steal your intellectual property and that law is not enough, Then you will need to obfuscate your code. But I would not call that protection per say but a deterrent to the casual reverse engineer.
Putting a pragma -No Cache- will prevent the .xap from being stored on the machine, instead it will be streamed by the Silverlight plugin. Without the pragma the .xap file is stored in the temp internet files.
Putting the application on a page on https will further protect the transmition of the .xap
If possible require authentication to view the web page / .xap file (thanks Joel)
Emrah,
Yes obfuscation is possible for SL application.
Yes, Silverlight xap files are nothing but zip files with your assemblies in them, so they do need protection via obfuscation. Give Crypto Obfuscator a try - it directly obfuscates xap files, it can also obfuscate XAML files in your assemblies by renaming class references, stripping comments, whitespace, newlines, etc