How do they crack our software?(3rd ed)
| Tue, 2008-01-22 17:18 | |
|
I'm at the final stage of developing my application and this question popped up in my head? We pay for signing our applications, right? And the signing process is supposed to ensure this application came from me intact? So how can a cracker change the code inside to brake my registration |
|
We all know they do.
Forum posts: 110
I too have wondered about this. My understanding (which I freely admit may be completely wrong) is that it is possible to unsis a signed sis file and therefore get access to the files in order to hack them. However it shouldn't be possible for the hacker to re-create the sis so that it is still using your certificate. In other words there is no way a hacker can hack the file and still have it looking as if it came from you.
Of course maybe it is possible and this Platform securrity and Symbian signed stuff is just a big con!?
Forum posts: 125
"We all know they do."
I'm curious as to who and why would go to the trouble of intercepting (how?) a sumission to Symbian signed and hacking it so that it would fail?
Forum posts: 139
Simple, they take the sis file, break it apart using dumpsis, remake the sis file and then apply for a devcert, which fortunatly is why now it is a lot harder to get a devcert without verifying your identity and spending money.
One thing you can do is making sure you have an API that requires manufacturer set capabiltiies for Symbian Signed so the binary links to a manufacturer set API and so the capabilty cannot be removed by setcap.
Paul Todd
Forum posts: 147
Developer certificates work on limited sets of IMEIs. But cracked programs are out there for anyone to download, so I guess this is not the way. I can understand how they provide keygens. But what about the case when the application works with any unlock key given? They have surely messed up the exe file. And the application comes signed from the original producer(or at least it looks so). No developer certificate warning. Can anyone explain this? How can we protect ourselves if we don't know how they do it. I guess I will have to go back to good old 2nd ed methods. The worst thing is this security system restricts ME when it comes to hiding my secret information.
Forum posts: 684
No matter how much you "obfuscate" regisration key systems, the principle always boils down to roughly this:
if registration_valid() {
run_application
} else {
exit
}
All a hacker needs to do is to remove everything else except
run_application
and such protection is eliminated.
Or they can figure out the way to generate license keys, and then write a key generator.
Etc.
And, without the source code, this of course is done by looking at the compiled machine code directly, disassemblers, in-circuit debuggers, etc., and so on.
Of course, it isn't quite this straight-forward (you can hide stuff in very complex and convoluted ways, use/rely on encryption, etc.), but the general principle doesn't change.
Then you must consider how much added value does it provide to spend time developing such mechanisms vs. spending the same effort in writing a better application in the first place.
You can also consider commercial solutions (e.g., Psiloc and Openbit) offer/license products for this purpose (you pay them for a more or less tested/proven solution, but get more time to concentrate on your application, or can release it to the market faster so that people start buying).
In some cases (like a game such as World of Warcraft), you're so dependent on online access that you don't really need to protect the actual game at all. There are also slightly different approaches, such as this one: http://www.ea.com/article.jsp?id=bfheroes012108
Of course, when there is no absolute requirement for on-line connectivity, there's no server where you can block access and prevent the app from being useful.
In any case, all purely software based solutions/mechanisms (or, really, all solutions, period) can be bypassed given enough time, money, skills and/or motivation. Any solution is just buying you time (how much depends on your approach; i.e., will it take minutes, hours, days, weeks, months or years to bypass the system you've put in place).
Forum posts: 979
I wonder why this is possible in the first place. When Symbian and its licensees came up with the whole signing process, why didn't they introduce encrypted SIS files at the same time? Encrypted files along the following lines: Signing encrypts the SIS file with the help of a public key, only to be decrypted with a secret private key, present and closely guarded in the phones, and distributed to a few trusted third-parties that have a legitimate interest to decrypt SIS files, i.e. the test houses.
Does anyone see a technical reason that would have prevented this, or at least would have made it a bad idea?
Could it be that there are none, and that Symbian had all kinds of interests on their minds when they built the signing process, the interests of themselves, of the licensees, of the operators, of the phone users, but, alas, *not* the interests of third-party developers battling against crackers?
René Brunner
Forum posts: 125
I wasn't asking how somebody can physically take apart a SIS file and put it back together again. I was asking why would a hacker specifically want to do this so that somebodies submission to symbian signed would fail?
What gain is there for a hacker to:
- figure out how to intercept your SIS file as it is being delivered to Symbian
- hack it apart, and put it back together so that it will fail
- forward this onto Symbian Signed but making it look to Symbian signed that it has come from the original sender and not the hacker
- the result is that the submission fails.
Why do they care enough to go through all of this trouble just to make somebodies submission/registration fail? (which is what the original posting said, as opposed to hacking/cracking a program after its been released).
Forum posts: 147
Maybe I didn't make myself clear. Noone will go trough the steps you mention. It makes no sense. A cracker takes my already signed application. Takes it apart and changes the exe file, so that it will work with any unlock key given. Then he puts it back together and at the end the application looks just like the original, INCLUDING THE SIGNATURE. How could this be?
Anyway, I don't hope for an answer anymore. I read this whole security section. 4 PAGES. WOW
I will look for another information source.
Forum posts: 4
filio wrote:
>And the signing process is supposed to ensure this application came from me intact?
Hi filio
The signing process ensures that the application has not been tampered with since it was tested & signed.
Numpty_Alert wrote:
> What gain is there for a hacker to:
> - figure out how to intercept your SIS file as it is being delivered to Symbian
Hi NA
Sorry but you have completely misunderstood the first posting. The problem is with crackers unpacking SIS files and breaking the registration key check.
rbrunner wrote:
> Symbian ... why didn't they introduce encrypted SIS files at the same time?
Hi René
An interesting idea, but there are too many people who would want to see inside the SIS file. For instance anti-virus vendors want to check for similarity to known viruses. Application shops (e.g. Handango or Orange) would want to know what they are distributing - e.g. that it contains no hidden pronographic or anti-semetic material. Also copyright owners for audio, video material or resources such as fonts may want to inspect packages for infringements. Even the developer needs to be able to identify which versions of what files are in a particular package.
One possibility for the future is that operators or manufacturers will allow only applications signed with their keys to be installed. This has some benefits for developers of established or existing software, but would make life harder for new authors.
filio wrote:
> Then he puts it back together and at the end the application looks just like the original, INCLUDING THE SIGNATURE. How could this be?
I don't see how this is possible. Some attacks on digital signatures have been proposed but they are still computationally infeasible.
Please send me the files and I will investigate.
Tony N
Forum posts: 979
After working in the IT field for 25 years I pride myself with having developed a fine sense to distinguish real technical challenges from mere power games that I lost.
You mention what I would call the "right and ability to have a look". You argue that so many parties have a legitimate right to look at the content of my SIS file, and must get the ability to have that look, that it would be too hard to establish a trusted key sharing infrastructure, and therefore I as a developer can't get my encrypted SIS files and the support that they would bring in my fight against crackers.
I feel that is just one of these power games that I lost: Third-party developers with their troubles with crackers are not important and not powerful enough that building a key sharing infrastructure seems worthwhile for the ones who hold the power.
I don't want to attack Symbian with this, and I am not angry either, I just don't like to confuse technical problems with just being overruled. Key sharing infrastructures are not a technical problem, they are a cost factor, and if cost can be avoided, businesses avoid them, that's only natural.
I compare this with my right and ability to look at the contents of my phone, as a phone user. There I learn that PlatSec brings me caged, private directories on my phone where even I as the phone owner cannot look what is stored there.
Just another of those power games that I lost, not a real technical problem. I am sure that one could have built PlatSec in a way that it would be a tolerable security risk to let phone users have a look at all files on their smartphones, but again that probably would have been more expensive.
So, my SIS files must be naked, and some directories on my own phone hidden forever, because I am not powerful enough to force my wishes. That's life in mobile IT, and who does not like this, best goes playing somewhere else
René Brunner
Forum posts: 147
Forum posts: 1082
I would go so far to say "Its life", period
There is always more considerations then the ones closes to your own heart, and you don't have total control over everything you care about.
Its your duty though to say so if you think something is handled wrong
Forum posts: 979
It makes me a little sad to say so, but I think at the moment the importance of third-party developers really is small enough that neglecting their problem with crackers costs less than, say, establishing a key distribution infrastructure to make encrypted SIS files possible. With "costing less" I mean "costing less for Symbian, their licensees and the operators".
So you could say that Symbian handles its business right.
One could hope that over time the importance of third-party developers increases up to a point where neglecting their cracker problem becomes more expensive than cracking-countermeasures built into the OS and the Symbian "ecosystem", but I don't hold my breath. Just look at Windows: Vista is full from top-to-bottom with protection stuff, but among all that stuff nothing to make the life of the Windows shareware author easier.
One could get a little cynical and say that even a cracked application makes a Symbian-powered phone more attractive to end-users, so even with cracked applications Symbian sells more licenses, Nokia and SE sell more phones, and operators get paid for more minutes. Just the poor program author is somewhat unhappy, but the monetary damage that this unhappiness causes is severly limited
René Brunner
Forum posts: 6
3rd-party developers for Symbian started to vanish, as a combined result of the constraints by the new security craze, and of the continued efforts by crackers. The lack of applications is already strongly criticized by end-users, so it might be time for the big players (manufacturers, operators, etc.) to realize what's going on, before they feel it on their profit.
By the way, a hacker can just install the program on the memory card, so then he has full access to the .exe, can debug into it, change it as he wish, and then re-packs and signs it using a root certificate. I see no defense at all.
Forum posts: 979
No defense at all is a little harsh. It may be possible, after install, collect all the various files that make up an application that went into various folders, write a new .pkg file for them, and make a new SIS file, but this is still considerably more difficult than just running UnSIS.
And if just only *one* file per application stays encrypted after install and is decrypted on-the-fly when the program is started, this memory-card trick already does not work anymore. Or if just *one* file per application always goes into the (pretty much un-removable) phone memory, again this attack vector is dead in the water.
I did not say it would be easy. I also said it would have cost money for Symbian to implement something. But impossible, no.
René Brunner