So the signature is encoded over the update.zip right so all we need to do is steal the difference between signed and unsigned update files they have to be the same file but uziping and reziping does so. All that needs to be done from there in my thought is calculate each offsets difference and bam signature. Now create a new update.zip with all rooted files. Clockwork and s-off being all we need. Make the update the same size exactly and add the difference we obtained to it and bam rooted it is
Sent from my T-Mobile G2 using XDA App
public key cryptography 101 says it wont work.
Why won't it work if I may ask.
Sent from my T-Mobile G2 using XDA App
What you are proposing sounds acurate in my head, but everything says it doesn't work that way. I guess some things I will never understand..... Women is another one.
Ill do it on my own and test it when I get home again. MORE COFFEEE!!!
Sent from my T-Mobile G2 using XDA App
Chances are the security will relise something is wrong when doing the update even if everything is set perfectly and thus you may end up with a bricked phone.
Yayy for phone insurance claims then
Sent from my T-Mobile G2 using XDA App
More power to you then my friend, go nuts, maybe youll get something out of it that helps with the perm root.
Dom18 said:
Chances are the security will relise something is wrong when doing the update even if everything is set perfectly and thus you may end up with a bricked phone.
Click to expand...
Click to collapse
I highly doubt that will happen. Look at all the failed updates due to the whole goggles thing.
Quick question though how does one set s-off in the image so I can try this. And to clarify I'm using a hex editor to re-add the diff from the signed and unsigned updates so the calculating will be a headache :/
Sent from my T-Mobile G2 using XDA App
Didn't they say decrypting the signature from or the key would take a lot of time, i mean were talking years?
Just incorrect in every way imaginable. That's not how signature verification works. If cryptography could be circumvented that easily no one would use it. I am not going to explain asymmetric encryption in this thread, there are plenty of resources for that. Let's just say what you're proposing here has no chance of working whatsoever.
Start here: http://en.wikipedia.org/wiki/Public-key_cryptography
and here: http://en.wikipedia.org/wiki/Digital_signature
Unless HTC put an idiot in charge of their crypto, what you are proposing won't work.
Yeah, if you are lucky, they will have put jdkoreclipse in charge of that. I think that is the only way the encryption could be done as poorly as you are suggesting.
funkadesi said:
Didn't they say decrypting the signature from or the key would take a lot of time, i mean were talking years?
Click to expand...
Click to collapse
I forget where I suggested this... but I was thinking someone could write one of the [email protected] or bovine (for those who remember) type application, where the client can run on anyone's machine that tries to crack the key by connecting with a central server in a coordinated effort. All of us G2 owners could run the client on 1 or multiple machines 24/7 and we may get lucky and find the real key.
I'm willing to install it on every machine at work if someone will write that client program ;-)
reference: http://www.distributed.net/RC5/en
To the best of my knowledge unzipping and rezipping it wouldn't break the signature...
I don't want to be insulting but if you do not understand PPK cryptography and how cryptographic signatures work please do not try and "break" something that has been evaluated and probed by numerous security experts in an attempt to find vulnerabilities.
It might be possible to crack ppk based signatures but it is not a simple matter of a diff between pre and post signature files. Again, I don't want to hurt anyones feelings but people A LOT brighter than you who actually understand the mathematics involved are not able to do it.
Put simply I will give you 2 documents, a signature for one of the documents, and a public key to verify the signature. If you can derive the key from which the signature is made or a way to create a valid signature for the second without the key you will be famous overnight since you will have found a vulnerability in one of the cornerstones of modern cryptography. Again it is possible but the chance of success without knowledge of the mathematics involved is monumentally small. Even with knowledge of the mathematics such a crack has not been found by people dedicated to researching such vulnerabilities.
Sorry for the rant but voodoo mechanics is a sore subject for me.
The simplest way I can explain it is the following.
Let's say they put a tag in the file that said "Google signed this". All someone would have to do is move that tag to a new file and it would look like Google signed that new file. So, that process doesn't work.
OK, let's say they put a tag in the file and said "Google signed a document that contained these bytes - blah blah blah", well same problem, someone could move the tag and edit the "blah blah blah" part to match their new file, so that doesn't work either.
So, instead Google puts their signature into the file, then they encode that file in a way that only they know how to do, but using an algorithm that they can make public the way to decode it. So, everyone can still get access to the contents, but nobody knows how the magic "encode" process works so nobody can pretend to be Google and produce a file that has their particular encoding. Since their signature is inside the part that was encoded, it is clear that they put their stamp on it prior to running the encode algorithm so you know for a fact that it was "signed at the Google factory".
Someone can try to put Google's signature in another file and then try to figure out how to do that encoding, but they wouldn't be able to mimic the exact way that Google does it so everyone would know that the encoded file came from someone else. Thus they are foiled.
A few details:
- The encode/decode process is actually a backwards encryption algorithm. Google encodes a file by "decrypting" it (i.e. pretending the real data was encrypted and running a decrypt on it and getting some garbage). The public then decodes this file by "encrypting" it (i.e. using the public keys to encrypt a file for Google and running it on the results of their decryption ends up getting back to the original file). Magic
- They don't really encode the entire file as that would be computationally intensive. Instead they generate a "checksum" of the original file that is both fast to compute and unique (i.e. the chances of a different file generating the same checksum is 1 in a HUGE number). They then encode that checksum (which is much, much smaller than the original file) using their special encode mechanism and not only can nobody produce a file that happens to have the same checksum (it is not known how to produce a different data stream that results in the same checksum), but they also cannot reencode the signed checksum due to the properties that make encryption so safe. (Note that the "checksum" algorithm here is quite a bit more complicated than adding up all of the bytes in the data stream - which would be easy to falsify - but it is still easier to compute than an encryption algorithm).
flarbear said:
The simplest way I can explain it is the following.
Let's say they put a tag in the file that said "Google signed this". All someone would have to do is move that tag to a new file and it would look like Google signed that new file. So, that process doesn't work.
OK, let's say they put a tag in the file and said "Google signed a document that contained these bytes - blah blah blah", well same problem, someone could move the tag and edit the "blah blah blah" part to match their new file, so that doesn't work either.
So, instead Google puts their signature into the file, then they encode that file in a way that only they know how to do, but using an algorithm that they can make public the way to decode it. So, everyone can still get access to the contents, but nobody knows how the magic "encode" process works so nobody can pretend to be Google and produce a file that has their particular encoding. Since their signature is inside the part that was encoded, it is clear that they put their stamp on it prior to running the encode algorithm so you know for a fact that it was "signed at the Google factory".
Someone can try to put Google's signature in another file and then try to figure out how to do that encoding, but they wouldn't be able to mimic the exact way that Google does it so everyone would know that the encoded file came from someone else. Thus they are foiled.
A few details:
- The encode/decode process is actually a backwards encryption algorithm. Google encodes a file by "decrypting" it (i.e. pretending the real data was encrypted and running a decrypt on it and getting some garbage). The public then decodes this file by "encrypting" it (i.e. using the public keys to encrypt a file for Google and running it on the results of their decryption ends up getting back to the original file). Magic
- They don't really encode the entire file as that would be computationally intensive. Instead they generate a "checksum" of the original file that is both fast to compute and unique (i.e. the chances of a different file generating the same checksum is 1 in a HUGE number). They then encode that checksum (which is much, much smaller than the original file) using their special encode mechanism and not only can nobody produce a file that happens to have the same checksum (it is not known how to produce a different data stream that results in the same checksum), but they also cannot reencode the signed checksum due to the properties that make encryption so safe. (Note that the "checksum" algorithm here is quite a bit more complicated than adding up all of the bytes in the data stream - which would be easy to falsify - but it is still easier to compute than an encryption algorithm).
Click to expand...
Click to collapse
I wanna add that most of that process is known because of AOSP and how we sign with the test keys. The only piece missing is google's/t-mobile's/htc's private key (because...who knows who really made the one for the G2?).
my 2 cents
Awaiting OPs response
Related
Hi Guys, I've been using phatnotes pro 4.7.2 full version, for as long as I remember now even when they were called something else... anyways they have a protect note option, which adds a password to the notes you make.
How STRONG is this password protection? Does it even add encryption or it's just a simple password block and anyone can override and view the notes using a hex editor or text editor???? is it safe to leave a few credit card numbers in there?
Noone knows, the developer uses 'security by obscurity' by refusing to disclose the algorithm used.
The most secure algoritms used (AES Rjindaal, Twofish/Blowfish etc) have been subject to years of public scrutiny. It's the implementation not the algorithm itself that makes the security. There is no security threat form disclosing the algorithm.
I'd recommend staying away from this until the algorithm is disclosed if you want to encrypt your data.
bydandie said:
Noone knows, the developer uses 'security by obscurity' by refusing to disclose the algorithm used.
The most secure algoritms used (AES Rjindaal, Twofish/Blowfish etc) have been subject to years of public scrutiny. It's the implementation not the algorithm itself that makes the security. There is no security threat form disclosing the algorithm.
I'd recommend staying away from this until the algorithm is disclosed if you want to encrypt your data.
Click to expand...
Click to collapse
So are you saying they DO using some form of encryption within their application when password protecting the notes or you don't know? I don't particularly care for what algorithm or encryption method they are using, my main concern is, are they even using encryption at all.
If my phone ever gets lost or stolen, most people who finds/steals it would just hard reset and wipe everything from the phone, so if there is even a slightest form of encryption, my data should be safe.
Depending on how often you use your 'secret' files. I have 1 particular note (in Notes) that I keep my personal stuff like passport number and others stuff that I may be using them, or not (very often, I don't). Hence I use the ccrryyppttoo (`crypto` with every letter doubled). I use this to encrypt that particular note. There is a certain advantages to it. (a) It still sync over outlook without 3rd party software plugin. (b) others still able to see the note, with non-sense short characters on it (eg, I have passport number a lot of other numbers there, which ended up only in 5 characters). There is also a desktop version available, if you wanted to have it tested (or incases where you have lost your phone and your file encrypted in your PC, you can use it to decrypt it).
hanmin said:
Depending on how often you use your 'secret' files. I have 1 particular note (in Notes) that I keep my personal stuff like passport number and others stuff that I may be using them, or not (very often, I don't). Hence I use the ccrryyppttoo (`crypto` with every letter doubled). I use this to encrypt that particular note. There is a certain advantages to it. (a) It still sync over outlook without 3rd party software plugin. (b) others still able to see the note, with non-sense short characters on it (eg, I have passport number a lot of other numbers there, which ended up only in 5 characters). There is also a desktop version available, if you wanted to have it tested (or incases where you have lost your phone and your file encrypted in your PC, you can use it to decrypt it).
Click to expand...
Click to collapse
1. I think your link doesn't work.
2. Thanks for the suggestion! But that means adding another program to my long list of programs, I rather just use phatnotes if they are somewhat secure.
3. That still doesn't answer my original question =(
4. Can you send me the program for me to try? I use my 'secret' note file on my pc and phone so phatnotes keeps them both sync, very convinient.
5. THANKS AGAIN!
The link does works at my end. Here is it again.
http://www.hfrmobile.com/app_CCrryyppttoo_T1/index.htm
Oops, forgot your original question. You can test the encryption yourself. I didn't try out Phatnotes myself, but you can try to locate the file of which Phatnote stores your notes (either 1 file for all notes, or 1 file per note). Password protect this file, send it over to your PC, open it with your Notepad. If it doesn't show what each and every word that you've typed for that note, it is 'encrypted'. Most amateur people will just use this method to get your secret stuff I guess, unless they know there are information on banking details with £10,000 in it
Hmmm great suggestion!! I just did what you said and the unprotected notes are readable by notepad and the protected notes are just garbled text of mostly "?" and "G" letters. So I guess they do have some form of encryption for those notes then. So how good is the encryption on crypto?
Well, I did a trip to search for the answer for your question of "how good is the encryption on crypto", and it seems that the author is using his way of encrypting the file, which I say ought to be safe enough for everyday usage, but good enough for business/military usage, I guess.
Anyway, while I was looking for the 'answer', I bang my head into this
http://tombo.sourceforge.jp/En/
As this is using the standard 128 blowfish algorithm, which has been proven to be strong and fast. It has both desktop and ppc version, which are interchangable (eg. desktop can decrypt the ppc encrypted file). And, it is free!
I found this too, limited-freeware though. http://www.freewareppc.com/docs/visnotes.shtml
Hmm.. freeware file encryption (AES algorithm): http://www.freewareppc.com/utilities/filebarricader2006mobile.shtml
[Update on Tombo]
I did a test drive on it. It is quite alright. It creates a txt file for each of the note you created and put them into structure folder that you made. There are option of making virtual folders as well. So, you can have your notes sync by syncing your My Documents folder, of which you set this Tombo to put all the notes. It encrypts files and have an added feature of scrambling the file name such that people are not able to guess what your file contents are.
However, there are two flaws that I've just found in a 1/2 hour testing
(a) its Unicode encoding is not working. Once you (really) close the application, it will give '?' for all the non-alpha-numeric characters. Weird consider the author is a Japanese.
(b) there isn't an option of wrapping texts without 'dissecting' them.
Hi all, I have a major concern about privacy and all the 3rd party data collectors...
A lot of apps are uploading user info and stats to companies like Flurry, pinch media etc.
I'm about to make the move from iphone OS to android, and i'm looking for a opt out to keep my privacy intact.
Saurik creaded PrivaCy for the jailbreak community that enabled on\off toggles for the 4 major companies.
My issue on iphone was that Pinch Media alone gathered the following information without my knowledge :
* iPhone’s unique ID (imei)
* iPhone model
* OS version
* Application version (in this case, camera zoom 1.x)
* If the application is cracked/pirated
* If the iPhone is jailbroken
* Time & date I start the application
* Time & date I close the application
* My current latitude & longitude
* My gender (if Facebook enabled)
* My birth month (if Facebook enabled)
* My birth year (if Facebook enabled)
I want the option to chose weither or not this kind of info gets collected and distributed.
I've looked into this issue on the android platform, and it seems like there's no option other than not to install the app.
Take for instance Locale. To my knowledge it uploads my imei nr (+lot of other info) to Flurry, whilst i do see the developers need to gather info, and I do not see why my imei number should be uploaded at all.
When I get my android phone I can only chose NOT to install locale, but I just want to prevent it from uploading such info..
Can anybody create a toggle, preferably one that doesn't aquire root, or some guide as to hosts file editing, or a firewall app that will give me this control over my device?
regards
-e
just add a line in hosts file like the following for each website you want to block:
127.0.0.1 some.company.com
Fantastic, thanks mate.
Unfortunately I will have to have root permissions to edit the hosts file.
(it might take time before the htc desire gets root)
(edit: unless theres another way to get write permissions for that file..?)
If I do mess with the hosts file I'd be keen on adding a fair few entries to block ads too..
Since the hosts file gets loaded in ram at bootup, will there be any noticably difference in speed due to the size increase?
regards
-e
could you please post the host-file or the addresses/ip's of the companies your gonna block?
they should be of interest for everybody here
1. You will need root access.
2. The change shouldn't impact the performance in the least. Any local host lookup is always faster than DNS lookup. Meaning that it should increase performance in cases where it finds the match in hosts file, although I doubt if you will notice it.
3. I wouldn't worry about RAM. The host file, even if you add a hundred entries, given that each line consumes 100 bytes, should still be under 10kb.
Great to hear. Thanks for the replies.
@fabsn: I'll post my hosts file as soon as I get this working.. (gimme a few weeks to get my phone, move to android and root
Although: I'd be keen on using the adblock app in androidstore (the one that modifies the hosts file), but my manual changes will break every time I update the app.
I'll try to get hold of the dev to se if he/she might add these info collectors (like Flurry) in another version so that people can get "the best of both worlds"
By the way: I wish all devs that utilizes info collection in their apps could just provide users with an opt out, then my problem would be solved...
-e
http://textbin.com/x6430
Here is a complete "phone home" list for the iPhone. A lot of this will directly apply to android as well, so perhaps a nice soul here at the forum could compile the most useful adresses for me (I'm writing on my phone and it's a b**** to do this on)
the list is taken from: i-phone-home.blogspot(dot)com/
so credit goes to that community.
I really want to combine this with the hosts file that jamesisbored/droid has for adblock..
I will test this once desire hits my mailbox and someone finds root.
-e
This sounds like a great idea. Once a comprehensive list is compiled it should be passed on to "bigtincan". I know myself and a lot of other people use their "ad free" app to block ads using the same method mentioned by Ady above. Although they may be blocking them already and I don't know. I've never looked closely at the host file.
http://bigtincan.com/downloads/android.html
Any progress made on this end?
ady said:
1. You will need root access.
2. The change shouldn't impact the performance in the least. Any local host lookup is always faster than DNS lookup. Meaning that it should increase performance in cases where it finds the match in hosts file, although I doubt if you will notice it.
3. I wouldn't worry about RAM. The host file, even if you add a hundred entries, given that each line consumes 100 bytes, should still be under 10kb.
Click to expand...
Click to collapse
I am new to modding my phone, would you be so kind as to go into more detail how to do this. Specifically, what is this "Hosts file" you speak of? I do have root access and searched my entire phone for a file like that with no joy.
Also, the links provided to possible host data do not work, can somebody update that?
Thanks!!!:laugh:
You may be interested in the MOAB (mother of all adblockers) thread here on xda. Best ad blocker out there, imo, if you haven't already. Sorry, I can't link it now.
Sent from my SCH-I545 using Tapatalk
I load a linked list of objects (i.e. a struct) at start of app. I want to pass the whole linked list to other Activity(s).
I can do linkListName.toArray() and pass via put.extra and re-create linked list in next Activity, but it just doesn't "feel" clean! ROFL
And most likely it's pass by value, not by reference (not sure if that makes a difference in my app yet, but I bet I'll need a pass by reference call). I've also read about Serialization and Parcels, but I think those are pass by value implementations too.
What I want to avoid is passing a linked list around my app; I would like to load it once, be able to have my custom class do whatever I need (adds, edits, deletes, moves etc.) on it.
Any ideas? I know I could probably just do everything in ONE Activity and just change my ContentViews as required, but I've read that can be troublesome. And note that I"m trying very hard to stay away from any database implementation just because I've done the database thing too many times.
TIA,
Roots
You could make the linked list protected instead of private and just pass a flag that tells your other activity to just access it via SomeActivity.myLinkedList
Protected makes the variable accessible by other classes in your package but not outside
From something awesome
And static...
From something awesome
Well ****, should have known that....THANKS! Guess my OOP is a bit rusty :-( ugh, I got it....seems to be ok...that is, I can see my methods when I do "ClassName.LinkedListName. "
Thank you so very much!!!!
Its happened to me before. Ive gotten caught up in Android Intents, Bundles, Extras, etc and was struggling to pass something till i stepped back and realized im still in Java... Its more of a mindset thing than anything else
From something awesome
08-06 15:46:27.354: INFO/System.out(408): This default is true
08-06 15:46:27.354: INFO/System.out(408): This default is false
Ha! My setter and getter methods are working across Activities! Woo Frikkn' Woo...I could send you $100 for that reply I'm so happy! Note to self: Must remember to write changes to file.
Just a note to ALL programmers, new and old: If you're trying to do something and it seems extremely difficult, you're probably doing it wrong. Go back to the basics and keep it simple stupid!
Can't believe that it almost took me a day to implement a tiny rendering change in my Vexed/HTML5 port. A little backstory:
I know there's already a good Vexed port for Android, but since I needed a web version, making it compatible with Android seemed like a good idea. It's still missing a lot of details, like a menu, manual or win/lose messages, but if you want you can play it here:
http://www.tapper-ware.net/data/devel/web/games/JS.Vexed/
The buttons used to be rendered using CSS3 border-images, which work on Android (at least 2.3+, haven't tested any other versions yet), BUT they are slow as hell. Apparently it's hitting a fallback path that renders the element much like you'd do on legacy-IE with behaviors... meaning that there's also a lot of tearing since the element that you apply the border-image to basically becomes a set of 9 image elements as far as rendering is concerned.
So I decided to implement my own border-image using Canvas (you can find it at line 168 of the HTML file: HTMLImageElement.prototype.renderAsButton)... after all, drawing border-images isn't exactly rocket science.
So far so good: it was working beautifully, but somehow I couldn't get it into my CSS... after basically checking every part of the chain with manually created data urls it really didn't make any more sense, so out of pure desperation I decided to take a look at the data url returned by HTMLCanvasElement.prototype.toDataURL, which was a ... surprise. This thing is wrong on so many levels it never should have shown up in any code. Not only does it not throw and ERR_NOT_IMPLEMENTED, it even returns data to cover the fact that it's not implemented, namely "data:," which doesn't throw an error when used as an image source.
The general workaround seems to be that people use a custom toDataURL implementation that outputs a Windows BMP file... which would be great, if Android supported 32-bit RGBA BMP files. However they usually end up as if they were 24-bit RGB files.
So if I wanted RGBA, i had to create PNG files.
The PNG spec is really very readable and makes it easy to implement a PNG encoder... but there are two shortcomings:
1. The only filter method available requires a filter byte at the beginning of every row. So you can't use the return data of getImageData directly (Array.prototype.splice doesn't work on ImageData, you have to copy it first).
2. It doesn't support uncompressed data directly... and compressing in JS seems like a bad idea. Instead you are supposed to use and ZLIB stream with raw blocks
It also has CRC checks which are annoying for our purposes, but not that hard to implement (you can find my implementation at line 94: Array.prototype.crc32). Costs a bit of performance, but wouldn't be a major problem by itself.
But the reliance on ZLIB proved to be a major annoyance, because the documentation (RFC1950 & RFC1951) is lacking... to put it mildly (the relationship between those two documents is never really mentioned, meaning that you're always guessing if a header belongs to the stream or the block). The endianess is also switched from what PNG uses, meaning that you end up with two different types of integers in the same file. I ended up mostly analyzing THE GIMP's output for uncompressed PNGs (and could have finished everything much earlier if I hadn't tried to work my way through the spec first). The most important part from the spec is the definition of the ADLER32 checksum (line 85: Array.prototype.adler32), which sadly is required for each ZLIB block, meaning that creating a PNG involves calculating two different checksums for (mostly) identical data.
But my little PNG encoder is working now, and in difference to other implementations that I've found, there's no 64kb limit as my implementation splits every stream into 32k blocks correctly. However, it's not as fast as it could be and if there's interest I'll happily put the code in a project if other people want to help improve it or maybe even add proper compression.
EDIT: THE CODE IS NOW PART OF AN OSS PROJECT, SEE THE NEXT POST
I might not check this forum at the time, but you can always reach me at [email protected]
I've published the Javascript-PNG-encoder workaround over at http://code.google.com/p/todataurl-png-js/ under the GNU Affero General Public License, version 3 license in case anybody wants to join and add compression or just general optimization. Just drop me a line if you want to be added to the user directory.
I was looking through some files and i found alot of files that had coding like this :¤¢± –§nLée˜»=“5ê{i!¿èb5n)–~
åðZá
¸cYœúÌ*pa%êÁR "çÓ+©qhÿ˜î™)ZÎmðxŒ)8`Íše*PD×Ú±#jMˆ’Zž1ú}(ñe4Ô*šùØÕÖf[9A‰c
K6lZ®s^ô¢N€é-…BÄ~žÎäÃ6™® ̉ÐhxËòùQç6,mØFŠ,ÈFìo㢋™E¹ÆÆlóS–ñÇøÙ¿DR¶ä:TZKFl/öô§q
s1x„ö ÷Ùç½ÓšÃsäá!˜ˆ•Ä <:} @Óv˜£+×_ãOÉžéd—b#ùƒ
/EJàã$Ä ¹2¸²Æ*Þ„œRbÜïÏ|W’]‹[П6Ðh‰’I»½FýšNÖBJ]tß üŸš!‰Óp 2’aåÖïS¢ ;´-N(’ÅHºuà§' åu£s°·#
•Ë÷¦ÒywÄ•˜š‚
Could someone help me with this!
FIle address
C:\Users\dasd\AppData\Local\Packages\GluGamesInc.SamuraivsZombiesDefense_2mkdfttccc4r6\LocalState
There is a file there called localsave_offline_Save.data it aroused my attention so i looked through it and im no wizard at decoding so help please!
That is because the file is not stored as plain text and is raw binary data. Notepad then attempts to try to load it as plain text and as you can see fails miserably to make anything of it.
SixSixSevenSeven said:
That is because the file is not stored as plain text and is raw binary data. Notepad then attempts to try to load it as plain text and as you can see fails miserably to make anything of it.
Click to expand...
Click to collapse
Then how could i turn it into plain text
Realistically you can't so I suggest learning how to play the game properly rather than editing your save state
SixSixSevenSeven said:
Realistically you can't so I suggest learning how to play the game properly rather than editing your save state
Click to expand...
Click to collapse
Eh im done with the game was just wondering thanks for the help though would've wasted unnecessary time
Yeah... the file could be anything from a binary representation of in-memory data structures to encrypted plain text. Without decompiling the app, I probably couldn't tell you which. Totally not worth the effort.
RE:
GoodDayToDie said:
Yeah... the file could be anything from a binary representation of in-memory data structures to encrypted plain text. Without decompiling the app, I probably couldn't tell you which. Totally not worth the effort.
Click to expand...
Click to collapse
How would one decompile the app?
Also if it was encrypted plain text how could i decrypt this .
P.s
Im using word pad if it makes any difference here it is in notepad : ꊤ넘阞溧䰎早뮘錽楻뼡㕢⥮纖嫰ċ掸鱙Ǻ⫌慰勁*⯓熩罨飿駮娩淎磰⦌怸髍攑傠Ʉ???⎱䵪銈鹚僧⡽旱퐴骭???훕学㦏襁腋氶媏玮亢蔭쑂縎캞쏤餶ޮ觌棐쭸鱗ⰶ???䘔Ⲋ䛈订䖙욹跆匎뿙剄吺䭚汆ꟴᥱ猋ᄆ砱Ⴝ髓珃頡閈߄㨼紁䀇盓ꎘ휫쥏靤⍢菹ጋ䔯ⓣໄ뤞렲욲???鲄劁???쿯坼嶒謕嬚퀓㚟棐銉뭉뵿﵆亚䋖嵊璏???ﰝ骟褡팔쉰㈠憒ᇥꉓ㬉ⶴ亏鈨䣅疺➧輠痥ꌛ猈뀄⎷ଜ쮕꛷秒遷闄骘ஂ???歿ᙊᱲ֪柗錥햑愙╨ꉜ鬀폿벹휵ኩ뾳閥巵숹争퍨逞ꬡ滱ⴡꎣﾯ㉭छ홐曩䝅ꖁ•淴疊苧ᾼ겒溂ꬳ켥ꄕ妕傮ⅼ䪙汵ᙜ???螑䓥坙뛋䟹䷭蘰윾텩뵼㊵⎦⦙椏Ჷꝱ癫୦◴桨???﨏裇鲕ﯬ빍???䌎歹ꍂ歆濌꼂㵢ᙳ㇆䙩敇트???簲䜅ࡦ穚շ浑냗彌㩎㼷鏉׆䳰綔䠡ᄓ콊肨֍碱啷???㥯ܩ栭牄Ȅ咢䪏马킀၌㗂⬃뻝週ᬓ倱㋲㭀ﾫ???㏰շ↚䴊濭൳鳛襉꜌덺铸㡯ᵑ쭷肳牨쁠鵡⏼鿈䭚咔綜眕Ꮮ萿躄ɬ隲윃㵔ᘭ琢ꙝ炙놕뜥묞⬴힒ओᦑㄦߊ䜈䗐⚬쥝묕蝪旭愔薻필勞???萯貿Ȍퟡ慩ꆟ瑠꽴瓼???菙뿮㱶즓馁៛৺娿糗讬睢峿剟ｗ쓘鬐轻㞱齹糗ꞩ쩪勯淒䃴木ᚿ楨봴ꁜ쎋恮䧑◴毝佻雑ⵋⴙ鄅㯨ﴣ察閸必狴醷㕁???隸ᷙഌ쮨竕ᛲᦥ왽充疒咔塐???鏀叁።渵끴쀡뢦蝬뵬䜜Ხᴐᶻ
The file is attached incase you can decrypt if it is plain text
It is not necessarily a straight forward process.
Decompiling the app can be a hit and miss procedure, not really legal either. You would have to attempt to fully reverse engineer the file format from what may be partially broken code and then write your own code in order to load and edit the files.
Not a process which can be done by a newcomer in under half an hour (or insert any other time period), or one that you can easily write a straight up tutorial for.
If it was encrypted plaintext (unlikely) not raw binary structures (very very common), the point of encrypting it is that a person cant decrypt it. There are numerous encryption methods available and they could have used any one. Brute forcing encryption can be very very slow with times to decode ranging from minutes to months, and not knowing what encryption method is used your probably looking at years as you try each method separately. Again, not really something a tutorial can be done for, Cryptography is a fine art, reverse engineering encryption is perhaps the finest part of Cryptography, its an experts field.
Eh... depending on the encryption used, and the way the app is compiled, it may be easy to reverse. You'd be amazed how many apps (mobile or otherwise) use something stupid like AES-ECB with a hardcoded key of something like MD5("THESECRETKEY"), or even just XORing with a constant string. That said, Microsoft does make it easy to do better than that, with their incredibly-simple-to-use-but-hard-to-reverse Data Protection API for apps.