Log in

View Full Version : cracking data files of an unspecified software


kramer
August 22nd, 2005, 21:06
(Whoops, I mentioned the target last time, I only skimmed through the FAQ and missed that part. ),

Anyway, say that there's a file produced by a certain program. The program stores certain kinds of data under one or more user names, with "administrator" as the default. The file produced is somehow encrypted or obfuscated in order to prevent tampering. Also, in this program the registration scheme goes with the file instead of the program, so that any files you create with the trial version will expire and become read-only after a period of time unless you apply the registration key to it. However, the files I'm looking at have been registered already.

So, how to unravel the data file and be able to modify it? the registration key complicates matters, I don't know if it goes on top of the encryption or around it (if that makes any sense... e.g. it could have a checksum stored in the file somewhere to prevent tampering, and also have the "is it registered" stuff somewhere else, OR the whole thing is encrypted).

Come to think of it, I don't think it's encrypted at all (or it's stored in some sort of raw format, or parts of it are encrypted or obfuscated). If you look at the file in a text editor, about 50 percent of it consists of "FF", 25 percent is "00", and then there are some lines of data that are repeated over and over. there are tiny snippets here and there that look fairly arbitrary, but there are also lots of plaintext things that refer to () accounts, transactions and userIDs.

To make the problem a bit simpler, say we want to change the name of a userID in the file (so that all transactions by that person will appear under a different name)

One thing I'm interested in is whether I can change the UserID (e.g. the username is "fred", when you change the username it either changes the name displayed in all associated transactions, or only changes that particular name). Interestingly, there are multiple instances of the username in the dat file (in plain text if I change one instance it says "this is not a valid myob file", if I change all instances it crashes. maybe because the username I changed it to doesn't exist. I'll check that out).

I'd prefer not to reverse the actual prog because the code drove me nuts when I tried looking at this software in ollydbg (i'm not really an asm programmer, i sort of know the basics but really it drives me nuts). but I'm sure looking at the actual program is a sure way to get bits of code that will unravel the file. Only problem is that I'm not an expert at these things, I normally just open data files and see if I can change obvious things, like user names. And maybe knock things up a notch by making sure that I don't change the file length or anything. Bam!

So really I think I'll just try a few obvious things and then give up (like, if I add characters at the end of the file, how will that affect the checksum? What is a checksum anyway? All I know about it is that you add together some bits in the file to get a number). maybe I can do a frequency analysis to see if it's a direct substitution thing.

The file's really odd, there are these lines of data that repeat over and over, but maybe one or two characters will differ from one line to the next. It could be telling the program "here's a list of things all from the same customer/supplier, today he ordered 2, tomorrow he orders 1, and the date's changed". It looks all ordered and repetitive, not random, so my intuition's saying that it's not complex encryption, it's either direct substitution of english, or lists of numbers and codes that tell the program something, or that there's an obfuscator function that replaces a character here and there at random.

Also there's a number in the data file which looks something similar to "{DC3BF49C-6638-4F52-ACB1-D68033331A66}" (that's not the actual number but it looks like that), it looks out of place and seems to be hex. {4-2-2-2-6} groups of chars? I can't see it in the registered file but it's hard to spot (it's in the middle of the file somewhere, seemingly arbitrary) if it were in the registered file it may be a different number, but I can't seem to find it.

I wouldn't have a clue about what to do with that, in ascii it's just randomn chars, so it's probably some sort of number. Not a folder in the windows registry, either.

Hang on chaps, I've just had a breakthrough. I'll rant some more gibberish later.

SiGiNT
August 22nd, 2005, 22:23
I kinda thought when you typed "registry" a light bulb might go off - look for separate entries for each user, but even if you succeed in reading other peeps files you're still going to have to eventually find a way to "register the app" (buy it or roll up your sleeves and get dirty). It sounds as though the data file has a checksum check in the main app so each file is going to need a corresponding piece of data somewhere. Just thinking out loud.

SiGiNT

kramer
August 23rd, 2005, 00:55
sigint33, you don't have to register the app because the app doesn't expire. Only the files expire if you don't register them, and once they're registered they can be used by anyone (but the owner can set a password). So students using the teaching edition can do their homework, but it becomes read-only after 90 days.

That hex number could refer to a registry folder, but since the file can be moved to any computer, the same folder name should exist everywhere. Also, I had two files with two different hex values there, so maybe it refers to the CD key or something.

Anyway, I was thinking along different lines, such as "how to modify data without using the program". I figured out how to change user names, that's about it. (maybe I could change the names of accounts too, but not the corresponding account numbers). Some bits are in plain text, the rest is probably raw data that needs interpreting.

Okay, turns out that the actual data for the user account itself is stored elsewhere within the same file, and encoded well enough to hide it from me (everything must be contained inside the file, the reason being you can pick up that one file, take it to another computer, and it'll work fine) but the plain text usernames in the data file means "this username has done the following: (gibberish representing a transaction)". So last time, when I replaced it with another name, the program looked up this name in the list of users, thought "wtf, this user doesn't exist", and crashed. Whereas I thought it was some sort of protection scheme.

So what I did is create a new username using the software, and do a find and replace job on the file. (I have admin privileges because it's only an example file. If you lose the password then that's another story), say I create the new name "gary"... and I want to replace transactions done by "administrator" so that it looks like "gary" did them... in that case, "gary" is too short, so it'll change the length of the file if I put that in (and if I fill it with blanks that's no good either, has to be an existing username of the exact same length).

Now I have to make the username the same length as the word "administrator". You can't add spaces to the end of a username because they just get ignored. If you create the user "gary . ", it'll look suspect (what's with the full stop?). Easy, I went and looked up some ascii codes looking for a blank one that's not a space, couldn't really find one so I just tried a few, and when I tapped "alt+255" it shows up as a blank char in winXP.

So, (using a hex editor), I change all instances of "administrator" to "gary+[8 spaces]+[alt+255]", and save it. Then I go back to the software and load it up. It works, the transactions show the right ID, but oh no! when I open security settings (user accounts) it throws error messages, because the info's all screwed up (doesn't crash or anything, just won't let you edit users and passwords).

Luckily, the software has an "optimise file" thingy, which fixes things up. sorta. the thing's gone back to "administrator", and the other "fred's" gone back to "gary" (don't ask who fred is, I had to change ALL the transactions to "gary", it's a long story but anyway), the details are fuzzy but i repeated the editing and optimising thing and for some bizzare reason it works this time. There's a few duplicates of the "gary" account so I delete them.

but there are weird side effects. When I exit and open it up again, it won't let me log in as administrator. I have to use "gary [alt+255]". When I log in under that name, I end up having admin rights, because it's really the admin account under a different name. furthermore, I can't create a new user called just plain "gary", or a dummy account called "administrator", because the prog will say "these accounts exist already, even if they don't. QED" (and disappears in a puff of logic ). But administrator is always there by default, can't be deleted, so the prog will say that it exists.

what do you reckon is worse, being locked out of the admin account, or giving an error inside the password settings? Depends on whether the anyone's likely to use either one. by the way, I've only tried it by replacing ALL transactions, if you leave at least one that says "administrator" then maybe the account will remain. maybe I can add a bogus transaction before repairing the file, and delete it afterwards.

Okay, let's say a certain lecturer wants your admin account to work with a blank password because she's got lots of marking to do and doesn't want to use your user ID. this person will complain that the admin account has a password (she can't tell that it's nonexistent, it just won't let her in), and you can just say "I changed the password, whoops", then she says "well set it to blank and resubmit it", "I forgot the password" etc... Could work for a one-off assignment, but if you've got weekly homework tasks then it'll raise suspicion.

Say this teacher is unlikely to want to set passwords, so maybe it's better to leave the error there. In the unlikely event that they optimise the file to fix it, some other person's username could show up in the transactions, but maybe not. I don't remember.

On the other hand, in a workplace all these options would cause problems, your only hope is to leave the error for someone else to "fix" by optimising the file, and they can get blamed for it. (Of course it's unethical. But what if you're an accountant in Nazi Germany, and you want to strike a blow to their economy? It could happen to you!)

Of course, there's not much benefit from changing a userID in the workplace. "Hey, I can take credit for the shipment of nails that fred ordered". Riiiight.

You know, I was about to give up, but for some reason I decided to keep fiddling. I'm just happy I stumbled across the answer.

naides
August 23rd, 2005, 08:48
Kramer, you have too much time on your hands. . .

Anywho,
I doubt you are going to get very far looking at the data files in and on themselves

They likely contain hidden keys that mark their expiration date, their lock up codes, etc etc etc, all that you want to change/manipulate, but the one and only place those keys get used and the data gets interpreted is in the executables.

By looking at the executable interacting with the data file, you can reverse the data strucure; Can you create very simple files and look at how they are constructed?
then make simple changes, and compare how it reflects on the data file hex view.

SiGiNT
August 23rd, 2005, 10:14
Well, I don't think I was totally off-base, my guess is the hex number you are seeing is probably date related, ( I wasn't aware of the time limitation), it still looks suspiously like a registry value or a value that might be stored somewhere in your temp files, and probably is promptly written a soon as you move the file to another computer, data files are extremely orderly, and it follows that changing a user name would require padding, otherwise data fields would probably be offset and all screwed up. I applaud your curiousity and tenacity but the practical point of what you are trying to do kind of escapes me, unless you are just reversing it "because it there" frequently a bug that bites me!

SiGiNT

kramer
August 23rd, 2005, 17:55
Well I think you're right sigint, it's the same length as a typical registry value, so I'll have another look when I have time.

(wow, hackers are telling me I've got too much time on my hands, I'd better quit while I'm ahead ), Well I guess I can tell you that I'm trying to cheat at school, I've got to do assignments in this program, and there are example files on the CD (that comes with the textbook) that are already completed. But the teacher insists that we use our userID for all the work, so that we can't just copy the example files and hand them in.

But mainly I was curious and "because it's there"... I mean, I'm still trying to figure out how long it took me to do all this, maybe 2 or 3 days, and each of these weekly assignments takes me at least 2 days (and isn't nearly as interesting as cheating ).

Sometimes we do 2 per week, it's ridiculous. It's not that I can't do them, I can use this program blindfolded... they just involve typing in lots of data, and it's really time consuming. But if I didn't have the curiosity I wouldn't have bothered because it took me ages to figure out.

So yeah, it's hard to see any point to doing this in the real world.

(Also, if you create a new company file with no data, it still takes up 640kb. probably because it's got lots of database structures built into it by default).

Anyway, thanks for the suggestions.

SiGiNT
August 23rd, 2005, 21:20
Yup!, I understand completely, I frequently spend more time trying the short cut than it would just to "do the actual work". But it seems as though always in the end you end up doing it the "right way" anyway. The whole point is learning something in the process, rather than repeating what you already know.

SiGiNT

FrankRizzo
August 23rd, 2005, 21:53
It was a menu program that saved your options to a file, and if you specified a password, it would encrypt them. According to the author, (who I spoke with), if you lost the password, you were screwed! So, I looked at the programs interaction with the file, and found out that he used the same encryption key everytime, and only set 1 bit in the first byte of the file to say that it was encrypted. So, you change that to a 0, the program would load the file, notice it was encrypted, unencrypt it, and allow you to modify it, and save it back unencrypted.

(I did it on a challenge from the programmer).

I bet this is probably similar. You could see where they read the data from the file in the program, and see what they do with it afterwards.

LLXX
August 26th, 2005, 01:45
The 16-byte hex number is a GUID, i.e. Globally Unique Identifier. It is used when someone wants her own unique number which is practically 100% unique in the entire world. In Windows they refer to its different components; here, it seems like it identifies the file itself.

As for the file, it's definitely not completely encrypted with a standard algorithm like RC4 or DES. The output of these encryptors is totally random, more like that of a compressed file. As you mentioned, the file has a structure to it, with repeating parts. This looks more like a fixed-length-record database. The data itself may be encoded with a simple translation scheme.

Of course the best way is to examine the program himself, he knows all about the file format and you can patch him to make him accept expired files too. In a debugger, tracing the filesystem calls will lead you to the file-handling routines which deserve some good studying on.