I have working on some data mining from a game memory, it includes some link with UUID path. Unfortunately, I can only got a small part of the URL because it's already replaced/removed/unloaded from the memory. I want to recover the full UUID path from that, but I wonder is it really possible?
Upon hours of surfing on internet, I can't find a source that covers my problem. The UUID path is really important because its where the server serve the content files. The server will look like this:
www.web.com/en-us/store/pdp?id=[UUID]
Now the UUID I got looked like this:
xxxxxxxx-xxxx-xxx8-492e-xxxxxxxxxxxx
Where the "X" is unknown because it's already unloaded from the memory. I know it's extremely limited but can we generate any possible full UUID from that small part? So far, the only thing I can think of is using a path finder but another problem arises. An available path finder from GitHub requires some wordlist.txt which mean it can't find any random UUID path.
Related
A friend of mine has a problem. He has hundreds of highly confidential .EBIN files for a medical study created by a person that is no longer available.
I figured that it's probably an Erlang directory - I downloaded Erlang and looked for several file type specifications, but I just can't find a way to "open" this binary file.
I feel really stupid right now as I should be able to easily access this as a long-term programmer, but I'm clueless. I don't even know what to enter into a search engine.
I'd guess that they are just containing serialized Erlang data ("terms"). Try starting Erlang and entering the following from the Erlang shell:
erlang:binary_to_term(element(2,file:read_file("YOURFILE.EBIN"))).
See http://erlang.org/doc/man/erlang.html#term_to_binary-2 for details about the term_to_binary() function and see http://erlang.org/doc/apps/erts/erl_ext_dist.html for details about the term format. If the bytes on disk don't look like this, it's likely that the binary data has also been encrypted before writing it on disk.
How easy can it be for people to see the code / inner working mechanics of a published iOS app?
E.g if there was a certain algorithm or function/class, how easily could people be able to read that?
If it’s possible, is there any way to camouflage or encrypt it so the code can’t be read?
Cheers
A certain algorithm or function/class is not going to be visible to anyone just from having access to a published app. The apps executable has been compiled and optimised so the original source does not even exist inside it. The executables are also encrypted and while can be decrypted if you jail brake a device even then you won't get much info.
While a lot of information about how an app works can be deduced by examining how it works individual algorithms is not something to worry about.
Plus what makes you think anyone is even going to bother trying for your app.
EDIT
As there was some confusion here is a link which talks about the binaries being encrypted when producing universal and thinned ipa files:
https://developer.apple.com/library/content/qa/qa1795/_index.html#//apple_ref/doc/uid/DTS40014195-CH1-APP_STORE_CONSIDERATIONS
First time asking a question on here, so please go easy if I don't provide enough info. Basically part of my iOS app allows users to take a picture which will be stored in a Core Data store. The attribute is a Transformable type, and I have created an NSManagedObject subclass which I simply use to set its image attribute to the new image provided by the user.
I know storing large files in Core Data is a bad idea, which is why I was excited when I saw the "Store in External Record File" option under the image attribute in the Core Data entity. However, my app performance says otherwise, taking several seconds on an iPhone 5 to load only a few images (which I know doesn't sound like much time, but considering how powerful the iPhone 5 is, older devices would likely take much longer with the same data).
I've looked around, and some people say that the Store in External Record File option is only applicable to the OS X environment, even though it is available in an iOS app. However, I also saw this under Apple's "What's New in iOS 5" doc (it's the next to last item under Core Data, near the end):
Managed objects support two significant new features: ordered relationships, and external storage for attribute values. If you specify that the value of a managed object attribute may be stored as an external record, Core Data heuristically decides on a per-value basis whether it should save the data directly in the database or store a URL to a separate file that it manages for you.
So my question is, who's right? Is it true that Apple made a mistake in giving this option for iOS apps, and that it actually does nothing unless you're on the Mac, or does it actually do something and I'm not configuring it the right way, or is it doing what it's supposed to do and the performance is bad anyway?
I've seen some guides explaining how to store large files (like images) as files, and save the URL to them in the Core Data store instead, but since this is essentially what this new option is doing, or maybe should be doing, I'm not sure if following these guides would even help.
I'm really sorry if this has been asked before. Normally I'd be fine with figuring this out on my own, but Core Data is totally new to me, and I'm still not sure how I managed to squeak by the initial setup. Thank you for any help you can offer!
who's right ?
the iOS docset for the NSAttributeDescription class does mention the allowsExternalBinaryDataStorage and the setAllowsExternalBinaryDataStorage: methods so there is little chance that there is a mistake from Apple.
are you doing something wrong or is slow anyway ?
You said that
The attribute is a Transformable type
But Core Data has a Binary data type. Maybe only this one is linked to the external storage capability.
if that's not it, we don't have enough info here:
How many pictures do you store ?
What are their sizes ?
Do you automatically fetch all the images ?
Also, the Apple doc states that:
Core Data heuristically decides on a per-value basis…
Did you use a migration or are you starting from scratch ?
You could have a look in your app's sandbox to see if your pictures are really saved outside of CoreData.
Hope this helps.
Good question!
Check this post:
Storing blobs in external location using built-in CoreData option
Apparently it should work. You should also try it in the simulator and inspect the application data folder to see if the folders are created as described (~/Library/Application Support/iPhone Simulator/... - you will figure out the rest of the path). Also you could inspect the sqlite file with the sqlite3 command to see if the binary data is in the database.
I haven't personally used this option as I would prefer to go for manually saving the images in a folder and store a reference to them in the database instead. This way it will be easier to create UIImage object from the file to be displayed, would have better control on what goes where and so on and so forth. Will take some extra labour though!
Hope that helps you out.
I am writing an application for iOS and a requirement I have been given is to remove files securely from the file system that may be given to my app from other applications (think 'Open in...'). These files are placed in a temp folder accessible to my app, but I'd like to securely delete these files once I have encrypted them in my own documents folder via the standard protection APIs. Any idea how to do that?
Quotes from the paper linked to by Bavarious:
We found that none of the available software techniques for sanitizing individual files were effective.
Overall, we conclude that the increased complexity of SSDs relative to hard drives requires that SSDs provide verifiable sanitization operations.
I'm not sure the flash memory in iPhones supports these operations, but if they do I'm pretty sure that Apple will have to make them available through their API and I haven't found anything in the API for this.
So basically it doesn't seem to be possible. Perhaps you could file a bug report with Apple and ask them to fix something like this.
I think you're better of looking into the possibility to encrypt the file before saving it.
First of all, I'm not a hacker :)
We're doing a project where we'll award points to users for visiting certain groups of sites.
Obviously there are major privacy concerns, but we have no interest in actually knowing where they've been, just as long as the program we create can check the history and through an algorithm, rank the site/user.
This would be a downloadable application and we'd tell the user how it worked, since transparency is vital.
Now, with that in mind, is there a way for a local program to access the Cache/History of a browser and make a list out of it?
I've read that Firefox uses SQLite to compile their History, which could potentially be parsed using Adobe AIR.
At the same time, Adobe AIR has access to the filesystem, so it could probably check if the usual IE temporary folders have any files stored. If so, try to read the URL they were downloaded from?
I know all of this sounds very dodgy, but try to keep an open mind :)
Thank you all for your help.
Not a full answer to your question, but you might be interested in the CSS History hack. If you already KNOW the sites you want to rank, you will be able to find out which sites the users visited.
Good thing you said something about a LOCAL program, because there are surely ways to read out the SQLite database from Mozilla and IE's history and you can find plenty of implementations using your favorite search engine.
Particularly easy to use are Nirsoft's utilities MozillaHistoryView and IEHistoryView which you could script to output CSV and parse that file afterwards.