Log in

View Full Version : crypto thought crackme #5

mike
January 20th, 2003, 17:52
A company uses a single license file for a suite of programs. There are some cheap features and some very expensive ones. Which features of the programs you can use are encoded in the license file. The license file is encrypted with the author's private key. If you raise it to the power of his public key mod n (2048 bits = 256 bytes) it looks like this:

Code:


struct license

{

    byte zero[1];

    byte userinfo[227];

    byte privileges[8];

    byte sha1[20];

}

sha1 is the hash of the 235 bytes consisting of userinfo and privileges.

What's your attack plan? rot13 if you solve it, as always!
nikolatesla20
January 21st, 2003, 16:47
Jryy, thrffrf ntnva ol zr.

Svefg, fvapr lbh xabj gur fgehpgher bs gur yvprafr svyr, lbh qba'g pner nobhg jurgure vg'f rapelcgrq be abg. Lbh pbhyq whfg zbqvsl gur cevivyrtrf ovgf hagvy lbh trg jung lbh jnag gb jbex. Nsgre lbh zbq gubfr, lbh fvzcyl erqb gur FUN1 lbhefrys naq ercynpr gur fun pbqr nf jryy.

-ag20
r4g3
January 21st, 2003, 18:18
fbzr gubhtugf sbez zr
Jr xabj gur ertvasb fgehpgher gb pbagnva bar cerqrsvarq olgr - mreb, cyhf ynfg 20 olgrf vf n unfu bs gur erfg qngn. Gurer`f ab ceboyrz gb trarengr n inyvq hapelcgrq yvprafr svyr, lrg guvf tvirf hf abguvat fvapr gb rapbqr vg pbeerpgyl jr zhfg cbffrff gur cevixrl.
Ohgr sbepvat sbe 0 nf svefg olgr naq gur ynfg 20 olgrf zngpuvat gur erfg bs cynvagrkg nfu fun1 unfu vfa`g gur jnl, vf vg ?
Nal bgure cbffvovyvgrf ? fbzrubj v qba`g frr nal. Oehgrsbepvat whfg gb zngpu gur svefg olgr gb or '0' jbhyqa`g or n ceboyrz, ohg vagebqhprq fun znxrf gur jubyr svyr vzcbegnag. Jvgubhg gur unfu jr pbhyq whfg trg fher gung (yvp^choyvp zbq a)[0] == '0', guvf jbhyq tvir fbzr genfu olgrf nf hfre vasb, ohg jung n uryy, ertvfgrerq zrnaf ertvfgrerq. Lrg guvf vf abg gur pnfr
ogj "Vs lbh envfr vg gb gur cbjre bs uvf choyvp xrl zbq a (2048 ovgf = 256 olgrf) vg ybbxf yvxr guvf:" naq fvmrbs (yvprafr) == 1 + 227 + 8 + 20 == 256
Ubj qbrf a ybbx yvxr ? Bapr ntnva: jr xabj gur svefg olgr gb or 0k30 - gur uvturfg olgr bs gur erzvaqre Fb jung ? qrnq raq ntnva.

uru guvf whfg cbcrq gb zl zvaq. vs gur nytb hfrq vf efn gura r fubhyq or < 65536
oehgr sbepvat jbhyqa`g gnxr 10^kk lrnef ...

bx rahs bs oyhaqrevat. gvzr gb fyrrc
mike
January 21st, 2003, 18:53
First, r4ge, the most significant byte (the bignum library is big-endian) is 0x00, not 0x30.
Quote:
nt20 wrote:
First, since you know the structure of the license file, you don't care about whether it's encrypted or not. You could just modify the privileges bits until you get what you want to work. After you mod those, you simply redo the SHA1 yourself and replace the sha code as well.
Seems r4ge has an answer for you:
Quote:
r4ge wrote:
There`s no problem to generate a valid uncrypted license file, yet this gives us nothing since to encode it correctly we must possess the privkey.

More from r4ge:
Quote:
Bute forcing for 0 as first byte and the last 20 bytes matching the rest of plaintext ash sha1 hash isn`t the way, is it ?
Well, it's one way, but it would take 2^168 operations!
Quote:
if the algo used is rsa then e should be < 65536
brute forcing wouldn`t take 10^xx years ...
Assume the public exponent is 3. How would you attack it then?

What if the private exponent were smallish instead--say, less than 2^512?

Is there a way to do it if the exponents are chosen at random?

What attacks don't target the crypto, but instead some other aspect of running the code? The only restriction here is that we can't distribute a modified version of the exe...
Kythen
January 21st, 2003, 20:06
Jryy, urerf zl purrfl nafjre sbe abj. Vg znl abg or vqrny naq
V erfreir gur evtug gb guvax hc n orggre bar, ohg vg vf jung
V jbhyq cebonoyl qb vs V jrer nggnpxvat guvf ncc. Jevgr n yvggyr
ybnqre rkr gung cngpurf gur choyvp xrl vafvqr gur ncc jvgu lbhe
bja choyvp xrl. Gura lbh pna znxr inyvq yvprafr svyrf jvgu
lbhe bja cevingr xrl. Nyy lbh unir gb qb vf qvfgevohgr gur
ybnqre naq yvprafr svyr(f), ab zbqvsvrq rkr.
mike
January 21st, 2003, 21:11
Kythen-now what if the key was checksummed in the app?
nikolatesla20
January 21st, 2003, 22:04
Well, then you just patch the checksum check as well :P with the loader.

-nt20
mike
January 22nd, 2003, 03:30
Either that, or patch the privs bits at runtime. I think they call them "trainers" in video games.
nikolatesla20
January 22nd, 2003, 09:23
Just wanted to say mike, I really appreciate these crypto thought posts - it helps to see how to think in alternative methods. (Which I prefer to do most of the time)

Keep up the good work!



-nt20
r4g3
January 22nd, 2003, 12:13
perngr yvprafr svyr gb or 256 0k0.
cbjre (yvp, nalguvat) zbq a = 0k0
svefg olgr = 0k0 ?? lhc
abj fun1 (); ....
cnefvat 235 0k0 nf cnenz, shapgvba rkvgf nf vs ab fgevat jnf fhccyvrq, gurersber unfufgevat = 0k0
fgepzc (yvpunfu, arjunfu) rdhnyf fgepzc ( cge_gb_ahyy_fgevat1, cge_gb_ahyy_fgevat2 )
Fb guvf yvprafr purzr vf fvzcyl n ovg ohttl ;]
Jryy bs pbhefr guvf qrcraqf ba fun1 () vzcyrzragngvba, ohg fubhyq jbex jvgu nyy p cebtenzf (naq gur erfg jvpu hfr 0k0 nf fgevat grezvangbe).
Be vg vfa`g fb ? V qba`g unir n pyhr, ohg znlor fun nytb abeznyl cebqhprf 0k0.. bhgchg sbe 0k0.. vachg

uz, ohg guvf znxrf cevivyrtrf gb or 0k0 gbb ...

.. v pnzr gb guvf orpnhfr bs "Svefg, e4tr, gur zbfg fvtavsvpnag olgr (gur ovtahz yvoenel vf ovt-raqvna) vf 0k00, abg 0k30." Ng svefg v gubhtug "bu jryy. znlor gur nhgbe unf fbzrguvat gb qb jvgu mreb[qnl] .. be vg`f uvf snibhevgr ahzre .. be nalguvat .." ohg nsgre guvf uvag: "jgs ?! jul guvf cnegvphyne inyhr ?" Fb guvf vf gur bayl fbyyhgvba gung pnzr hc gb zl zvaq gb znxr hfr bs 0k0 ...
urur :C
mike
January 22nd, 2003, 14:35
r4ge- another good idea! Check the implementations of the crypto components to make sure they don't do stupid things like hash strings with a null terminator instead of with a length. You can look for errors in the bignum code, too.

Assuming it's implemented OK, you should need to tell it your buffer size. You want a buffer that's 227 bytes of zeros (following your idea), followed by the privs you want, for a total of 235 bytes.

How big a number is the result? Does that help at all?
r4g3
January 22nd, 2003, 15:44
Quote:
Originally posted by mike
Check the implementations of the crypto components to make sure they don't do stupid things like hash strings with a null terminator instead of with a length. You can look for errors in the bignum code, too.


what/wich/(witch implementation ? you mean like Crypto++ ? don`t really get it. nothing mentioned in your initial post. thought this was a 'totaly theoretical' crackme
mike
January 22nd, 2003, 17:52
No, I just meant that you tried hashing some data and because your hash function was expecting a null-terminated string, it returned without processing the data. If there was a similar bug in the software I'm asking you to think about, you could crack the system that way. This one doesn't have a particular answer; I just want you to think of lots of ways to attack it. The loader was a good one. Checking to see if low-exponent attacks are possible is a good idea (the zeros in the user info fit in here). Note that you can choose part of the stuff being signed yourself. Are there any properties involving multiplication you can come up with? How about stalking the author online--can you break into his computer and get the key? It's illegal, of course. Do you want to take that risk? Et cetera.