I got curious what my binary iphone files contained, so I opened some in a text editor. To my surprise, there are a lot of methods and stuff being mentioned, even in the binaries that are code signed (I thought they got encrypted?). Not that it is a problem, I'm just curios. Why are there so many things in plain text?
http://pici.se/pictures/VRujRvhUi.png http://pici.se/pictures/VRujRvhUi.png
There are all sorts of plain text strings in executables, such as string table entries, string constants, and so on. An Objective-C, being very dynamic, uses method names at runtime also (hence the need for names in the binary). While the executable image may be signed, the contents is not necessarily encrypted. The signature will be applied to some form of hash of the file's contents, which can be used for verification.
The encryption is only on a portion of the binary when it is encrypted by Apple - so even in the released version of your binary, some things are visible as plain text.
-t
Related
I saved the face "savouring delicious food emoji" to database, and read it in php json_encode which show "uD83D\uDE0B"。 but usually we use one <img /> label to replace it .
however,usually I just find this format '\uE056' not "uD83D\uDE0B",to replace with pic E056.png .
I don't know how to get the pic accroding to 'uD83D\uDE0B'.someone know ?
What the relation between 'uD83D\uDE0B' and '\uE056'， they both represent emoji "savouring delicious food"?
The Unicode character U+1F60B FACE SAVOURING DELICIOUS FOOD is a so-called Plane 1 character, which means that its UTF-16 encoded form consists of two 16-bit code units, namely 0xD83D 0xDE0B. Generally, Plane 1 characters cause considerable problems because many programs are not prepared to deal with them, and few fonts contain them.
According to http://www.fileformat.info/info/unicode/char/1f60b/fontsupport.htm this particular character only exists in DejaVu fonts and in Symbola, but the versions of DejaVu I’m using don’t contain it.
Instead of dealing with the problems of encodings (which are not that difficult, but require extra information), you can use the character reference 😈 in HTML. But this does not solve the font problem. I don’t know about iPhone fonts, but in general in web browsing, the odds of a computer having any font capable of rendering the character are probably less than 1%. So you may need to use downloadable fonts. Using an image is obviously much simpler and mostly more reliable.
U+E056 is a Private Use codepoint, which means that anybody can make an agreement about its meaning with his brother or with himself, without asking anyone else’s mind. A font designer may assign any glyph to it.
IMPORTANT: As of this posting, the only browser that doesn't automatically support emojis is chrome.
FOR CHROME:
Depending on what server side language you are using, you should be able to find a library that converts emojis for you. I recently needed to solve this issue with php and used this library:
https://github.com/iamcal/php-emoji
The creator essentially created a sprite and adjusts the css according to the unicode of the emoji. It isnt pretty, but luckily he/she did all the grunt work for you. If you're using a different language you should be able to find something similar.
how do I put those little boxes into a php file?
Same way as any other Unicode character. Just paste them and make sure you're saving the PHP file and serving the PHP page as UTF-8.
When I put it into a php file, it turns into question marks and what not
Then you have an encoding problem. Work it out with Unicode characters you can actually see properly first, for example ąαд™日本, before worrying about the emoji.
Your PHP file should be saved as UTF-8; the page it produces should be served as Content-Type: text/html;charset:UTF-8 (or with similar meta tag); the MySQL database should be using a UTF-8 collation to store data and PHP should be talking to MySQL using UTF-8.
However. Even handling everything correctly like this, PCs will still not show the emoji. That's because:
they don't have fonts that include shapes for those characters, and
emoji are still completely unstandardised. Those characters you posted are in the Unicode Private Use Area, which means they don't have any official meaning at all.
Each network in Japan uses different character codes for their emoji, mapped to different areas in the PUA. So even on another mobile phone, it probably won't display the correct character, unless you spend ages manually converting emoji codes for different networks. I'm guessing the ones you posted above are from SoftBank (iPhone?).
There is an ongoing proposal led by Google and Apple to collate the different networks' emoji and give them a proper standardised place in Unicode. Until then, getting emoji to display consistently across networks is an exercise in unhappiness. See the character overview from the standardisation work to see how much converting you would have to do.
God, I hate emoji. All that pain for such a load of useless twee rubbish.
I have an iOS application, which stores all downloaded *.pdf files in its cache. Is there a way to prevent this data from extracting? Encryption or something else? Thanks in advance.
There are quite a few ways to encrypt files, and I'm sure everyone will have an opinion on the best way to do so.
In a project I've recently been working on, we've been using CommonCrypto (https://github.com/AlanQuatermain/aqtoolkit). Just take any NSData, encrypt it, and save it to a file, and vice versa. You can even write an easy Transformer by subclassing NSValueTransformer, which abstracts all of the encryption to one spot and you will never have to worry about it again.
You can protect PDF files with a password. I assume you create the PDF files not within the application but externally. For example you can use Preview.app in Mac OS X to secure existing PDF files with a password (Hit Cmd-P, then select PDF in the print menu and there you can set security options. Or even more simple: in the menu choose Export...).
In iOS you can then open the PDF files like this:
CGPDFDocumentRef documentRef = CGPDFDocumentCreateWithURL((__bridge CFURLRef)[NSURL fileURLWithPath:filePath]);
if (!CGPDFDocumentIsUnlocked(documentRef))
CGPDFDocumentUnlockWithPassword(documentRef, password);
...
There are actually 2 Documents folders in which your app can store content. One can be extracted, and one is private. Check the accepted answer in this ticket.
Access files in "private Documents" folder transferred with iTunes
Assuming you want the PDF files from getting extracted on jailbroken devices, the most straight forward approach would be along the following lines:
generate a random string during the first launch of the app
save the random string either in NSUserDefaults in state file inside your own app's sandbox
using this random string create a secret key using a deterministic but hard to figure out algorithm
use this secret key, which you don't store anywhere but always generate on demand, symmetrically encrypt your buffer with AES or something similar
You would probably find the source code here very helpful.
Recently i've asked about the security implications of storing sensitive info in the xml string resources in Android: the answer? Heavy security implications, is really easy to get the contents of every xml file with a simple command line tool, so it is almost mandatory to have important info encrypted.
Now, how is it like in iOS? How secure it is to have a certain data in a plist or a .strings localizable file, in plain text, non encrypted?
Still not very secure.
There is nothing stopping a user from unzipping an application stored on their computer in iTunes and viewing the contents. Its very easy to do, even without a jail broken phone. Any strings resources, plist files etc will be immediately accessible.
Even hard coded string literals are visible in the compiled binary when one views it with the strings utility. And going a set further, using the nm utility one can see all your applications symbols, such as method names, constants, etc.
I would recommend against storing anything that could be considered sensitive in plain text.
You can access any file on a jailbroken iPhone, so you'll need to encrypt sensitive data.
If your app ships with a .plist file, then the end user can unzip the .ipa app file and see the .plist file and do whatever they want with it.
The exact same problems, a plist is a very common file for Mac OSX and iOS and it is just a XML file. Secure your sensitive data on ALL platforms!
I would like to add that apple does provide a way to securely store sensitive information in the Keychain.
So I started developing my firefox addon.
Most of the work is performed by a referenced javascript file.
Problem is that when I edit some of the html elements on the page and say, set their text it's written as pure giberish. I am writing the text in hebrew. Can't for the life of me figure the reason.
Any ideas?
Javascript strings are already Unicode at runtime. However, you have to make sure that your files are encoded correctly.
Always use utf-8 (without BOM) file encoding for all your js, XUL, DTD, properties files to be sure.
Firefox might try to guess the file character set incorrectly otherwise, and even worse some stuff might not even try guessing the encoding and instead simply always assume utf-8.
Better yet, do not hard-code strings in js/xul, but use DTD/properties files for localization (XUL tutorial, XUL School).
This, e.g. snippet works pretty well for me (on this very page):
document.getElementsByTagName("h1")[0].textContent="русский язык";
(Just fire up the Firefox Web Console)
"Inline" hewbrew embedded in js files might create additional problems because it is right-to-left and bidi sucks, so the localization approach should be preferred.
I would like to create my own data format for an iPhone app. The files should be similar structured as e.g. Apple's iWork files (.pages). That means, I have a folder with some files in it:
The file 'Juicy.fruit' contains:
Fruits
---> Apple.xml
---> Banana.xml
---> Pear.xml
---> PreviewPicture.png
This folder "Fruits" should be packed in a handy file 'Juicy.fruit'. Compression isn't necessary. How could I achieve this? I've discovered some open source ZIP-libraries. However, I would like to to build my own data format with the iPhones built-in libs (if possible).
Best regards,
Stefan
Okay, so there are three ways I am reading your question, here's my best guess on each one:
You want your .fruit files to be associated with your app via Safari/SMS/some network connection (aka when someone wants to download files made for your app or made by your app).
In this case, you can register a protocol for your app, as discussed here:
iPhone file extension app association
You want the iPhone to globally associate .fruit files with your app, in which case you want to look into Uniform Type Identifiers. Basically, you set up this association in your installer's info.plst file.
You want to know how you can go from having a folder with files in it to that folder being a single file (package) with your .fruit extension.
If that's the case, there are many options out there and I don't see a purpose in rolling your own. Both Microsoft and Adobe simply use a standard zip compression method and use their own extension (instead of .zip). If you drop any office 2007 document, such as docx or Adobe's experimental .pdfxml file into an archive utility (I like 7z, but any descent one will do), you will get a folder with several xml files, just like you're describing for your situation. (This is also how Java's jar file type works, fyi). So unless you have a great reason to avoid standard compression methods (I vote gzip), I would follow the industry lead on this one.
I can definitly appreciate the urge to go DIY at every level possible, but you're basically asking (if it's #3) how you can create your own packaging algorithm, and after reading how some of the most basic compression methods work, I would leave that one alone. Plus I really doubt that Apple has built in libraries for doing something that most people will just use standard methods for.
One last note:
If you are really gunning to do it from scratch (still suggest not), since your files are all XML, you could just create a new XML file that will act as a wrapper of sorts, and have each file go into that wrapper file. But this would be really redundant when it came time to unwrap, as it would have to load the whole file every time. But it would be something like:
Juicy.fruit --
<fruit-wrapper>
<fruit>
<apple>
... content from apple.xml
</apple>
</fruit>
<fruit>
<banana>
... content from banana.xml
</banana>
</fruit>
<fruit>
<pear>
... content from pear.xml
</pear>
</fruit>
<picture>
...URL-encoded binary of preview picture
</picture>
</fruit-wrapper>
But with this idea, you either have to choose to unpack it, and thus risk losing track of the files, overwriting some but not all, etc etc, or you always treat it like one big file, in which case, unlike with archives, you have to load all of the data each time to pull anything out, instead of just pulling the file you want from the archive.
But it could work, if you're determined.
Also, if you are interested, there is a transfer protocol intended specifically for XML over mobile called WBXML (Wap Binary XML). Not sure if it is still taken seriously, but if there is an iPhone library for it, you should research it.