> There is a similar scheme for some old DOS software that decompressed itself
> upon execution. As I remeber, it worked pretty well.
still no good :(
the hackers have everything working for them.. i hada little
chat to BadToast on IRC the other day.. very proud little
chap.. check out the utilities they use.. the killer is the
following:
debuffer
it is a m68k dissasembler that links directly to the PalmOS
emulator.
they can set a break point (trap 8) from memory.. and then
decompile the NEXT n bytes in memory.
this proves pointless (as i have just found out) for encrypting
the routines... :( they set a break point just before you
call the routine, and the palmOS decrypted it for them.
the only protection here is to CRC check the file (which i am
trying to do), which will not allow them to patch a break
point into the code, and use the CRC value or something like
that to decrypt my data.
very very very complex stuff..
i admire the hackers.. if i was not developing, i would
probably do the same.. (as it is fun - when you get into it).
as for that compiler optimization?
well.. gcc optimized my use of a MACRO.. i was expected it
to inline the code, and it did not.. it created something
else, which optimized it..(for size).. and hence the patch
affected BOTH areas of code.
solution: declare a function (instead of a marco) as
inline..
cheers.
az.
--
Aaron Ardiri
Lecturer http://www.hig.se/~ardiri/
University-College i G�vle mailto:[EMAIL PROTECTED]
SE 801 76 G�vle SWEDEN
Tel: +46 26 64 87 38 Fax: +46 26 64 87 88
Mob: +46 70 352 8192 A/H: +46 26 10 16 11
