flat assembler
Message board for the users of flat assembler.

Index > Main > AntiReverse Teqnique

Goto page 1, 2, 3  Next
Author
Thread Post new topic Reply to topic
Enko



Joined: 03 Apr 2007
Posts: 678
Location: Mar del Plata
Enko
Hy, I was trying to learn some tricks to protect some part of the code. Like a crackme do.

Reversing a crackme I got an Idea (I didn't get the crackme xD I thinks its was a f0dder ones, the first.)

The idea:
(USER xor SERIAL == MAGIC KEY) (user and serial 8 char length)
The serial test routin will be separated in two parts.

The fist one will check half of the serial to check if that half is valid.

The second will be part of code encrypted with the MAGIC KEY using xors.

So, if the first have of the serial is valid, it will start to decrypt the second routing with the suposly valid MAGIC KEY
If USER xor SERIAL generates a valid magic key, it will generate a valid testing routin, jump there, test, validate, etc....

1/2 of magic key would be visible to the reverser. If they use it, but they wont know the other half, so the decrypted code probably crashes.



The thing is:
Can it be done? I tested some things yesterday and if the section is "readeable, writeable" you can modify it, and then jump there.


And the second question:
If someone want to crackit, it should be done by bruteforce? (8 length magick key, 4 characters known)
Or is there some other way?
Post 30 Jun 2011, 13:36
View user's profile Send private message Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
I don't really understand what you're proposing here but while you can modify code at run time, it only really affects the static analysis of an application. All you usually need to do to get around this is step through the code at run time and it will reveal its actual code, assuming the key is known. Given that you're proposing an XOR, if the key is incomplete/missing, it's still possible to derive the missing key from other code or to guess certain parts which is much faster than brute force.
Post 30 Jun 2011, 16:55
View user's profile Send private message Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 678
Location: Mar del Plata
Enko
Quote:
it's still possible to derive the missing key from other code or to guess certain parts which is much faster than brute force.


So it a poor technique?

What I'm currios, is where I can read some good stuff about protecting the code using assembly.

thanks for your time
Post 30 Jun 2011, 17:46
View user's profile Send private message Reply with quote
JoeCoder1



Joined: 13 Jun 2011
Posts: 62
JoeCoder1
Depends what platform you work on. Part of my job is reversing stuff and we do it by hand. There hasn't been anything we haven't been able to reverse. The only thing we tend to do when designing software we sell is to go with large monolithic modules instead of many executables but I don't know that it has much of an effect either. We have other ways of stopping normal users from tracing the code but anybody who knows what he's doing and has the required authority can do what we do. There isn't any way to stop reversing. On other platforms and OS I don't know. I think on PC's you have basically two groups of people, one is the very talented cracker and he will figure it out so don't waste time trying to stop him. Then you have the people who use freeware tools and debuggers and that should be easy enough to throw mud in their eyes by stripping symbols. No symbols = no help from the debugger. Throwing some data inline and then branching over it is a good way to mess up a poorly written disassembler which will then start processing the data as instructions. I have no idea how good the x86 disassemblers are.
Post 30 Jun 2011, 18:00
View user's profile Send private message Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 678
Location: Mar del Plata
Enko
I'm not intending make code imposible to reverse, just learn to make it a little bit harder to view. Plataform win32.

by stripping symbols what do you mean?
Post 30 Jun 2011, 18:04
View user's profile Send private message Reply with quote
JoeCoder1



Joined: 13 Jun 2011
Posts: 62
JoeCoder1
Depending how you build something you can leave debugging information in the executable or not on many platforms. It's not true on the platform I work on (debugging info is always a separate file) but on Linux and UNIX they can actually stay inside the executable. If it's true on windows there should be a way to strip the debugging symbols like on Linux. On Linux you can do strip -s executable and you will get a smaller executable that the debugger won't deal with easily. Some Windows guys can tell you details, it's not something i know anything about. I barely know about Linux/UNIX :p
Post 30 Jun 2011, 18:44
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
METHOD 1: Spaghetti Bloat.
Add so much useless code and inline decryption that even when a reverser gets all of the running code it's megabytes in length and painfully time consuming to figure out.

METHOD 2: Client - Server
Client - Server is the only reliable way to keep your code/algorithms a secret. Client app runs on the user's (internet) machine and sends commands to the remote server. Now the only thing that can be reversed is the message sending and the result receiving code, how the result is formed is ~""uncrackable"".

METHOD 3: One-time-use "timebomb"
Create a program, encrypt the code using a time-stamp in the distant future hashed with a custom hashing algorithm as a key. When the program starts it will get the current time-stamp, run it through the custom hashing algorithm and try to decrypt and run the rest of the code with the generated key. The program will only run at the one specific point in the future and without knowing that time it will be impossible to reverse. You can make your custom hashing algorithm consume a lot of time/resources so brute-force becomes difficult.
Post 30 Jun 2011, 18:48
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
Encrypting code is a valid technique, as well as obfuscation and self-modifying code; all make it harder to derive the actual code and its behavior but ultimately if the CPU can run the correct code, there is a way to find it.

In your example, if your unencrypted code calls into the encrypted code, that information can be used to determine/guess the correct value, which you can reverse by XOR to find the magic key. e.g. "stdcall hidden,x,y,z" I could assume "push ebp" will be the first byte. (the XOR function would also be visible code)

Another issue is the key checking function, which could be reversed to generate valid key lists/subsets. In cryptographic routines, the aim is to make the key only breakable by brute force; this then means the encrypted data could be anything. An obvious extension is to use more complex algorithms (such as the RC4 stream cipher) or modes (such as cipher block chaining or counter mode). Although the above attack would still apply, you wouldn't be able to determine or guess other bytes [until you have a substantial amount of the cipher text broken] because the keyspace is both larger and dynamic.

If all your code was encrypted except for the decryption routine, the only remaining attack is on the key when entering the decryption routine. If this is a run time session value e.g. received remotely via ssh or similar with its own protection mechanism (username/password) only those with access to the key could decrypt that code and this code may also be unencrypted. (arguably, you could just store the whole application remotely with this type of access)

Hope that helps
Post 30 Jun 2011, 19:00
View user's profile Send private message Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 678
Location: Mar del Plata
Enko
Thank you all for the explanation. With this, I have now a much great idea how to aim this

Thanks a lot agian
Post 30 Jun 2011, 19:13
View user's profile Send private message Reply with quote
garystampa



Joined: 25 May 2011
Posts: 52
Location: Central FLorida
garystampa
Code protection is like a padlock. It keeps honest people honest and it only deters thieves. If somebody wants your code, they can get it.

The only way I know of is how we do it - build a piece of hardware, burn some code into it and blow the fuse. Hand high-level data to it, let it crunch it and hand back results only. Your algorithm is safe inside the firmware.
Post 30 Jun 2011, 22:17
View user's profile Send private message Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 678
Location: Mar del Plata
Enko
garystampa wrote:

The only way I know of is how we do it - build a piece of hardware, burn some code into it and blow the fuse. Hand high-level data to it, let it crunch it and hand back results only. Your algorithm is safe inside the firmware.

At my work, this method I see it every day. The "boxes" for flashing/repairing/unlocking" mobile phones come with this protection.
almoste all of them use a smardcard reader interface with a smardcard inside. 3 intents to access the smardcard wrong way, and it blocks itself forever. The only way to crackit is to use a smartcard emulator getting the original java aplet code. almoste imposible.
Post 30 Jun 2011, 22:52
View user's profile Send private message Reply with quote
garystampa



Joined: 25 May 2011
Posts: 52
Location: Central FLorida
garystampa
The smartcard sounds like it's just data storage?

I'm suggesting you actually have code that performs your "secret" functions inside the hardware device.
Post 01 Jul 2011, 00:16
View user's profile Send private message Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 678
Location: Mar del Plata
Enko
garystampa wrote:
The smartcard sounds like it's just data storage?

I'm suggesting you actually have code that performs your "secret" functions inside the hardware device.


the "dongle" in this case its not a storage, but have a java aplet inside that comunicats with the software. So the "secret" functions are inside the hardware device. Inside the smardcard. (The mobile gsm sim/usim card is a smart card, its not only for storing some data, they actually can have some aplication inside. I think a java aplet as I readed somewhere)

But this is off topic xD. I just sad an axample of what you sad.

By the way, I don't develop this tools, I just by them and use them for my work. (setool, rockerdongle, mss, z3x, nspro, vygis, jaf pkey etc...)

And there is an old one, that does not have a smardcard, but a samsung volatil chip somehow called dallas. suposedly you can't read what is inside becouse the chip will erase itself)
Post 01 Jul 2011, 00:43
View user's profile Send private message Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2913
Location: 0x77760000
typedef
r22 wrote:

METHOD 2: Client - Server
Client - Server is the only reliable way to keep your code/algorithms a secret. Client app runs on the user's (internet) machine and sends commands to the remote server. Now the only thing that can be reversed is the message sending and the result receiving code, how the result is formed is ~""uncrackable"".


That is kind of useless, my friend.

That has been tried before but did not succeed


One can emulate the server and see what the app sends in return.
just saying
Very Happy Rolling Eyes
Post 01 Jul 2011, 02:58
View user's profile Send private message Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2913
Location: 0x77760000
typedef
garystampa wrote:
Code protection is like a padlock. It keeps honest people honest and it only deters thieves. If somebody wants your code, they can get it.

The only way I know of is how we do it - build a piece of hardware, burn some code into it and blow the fuse. Hand high-level data to it, let it crunch it and hand back results only. Your algorithm is safe inside the firmware.


+1

Very Happy

However; | http://en.wikipedia.org/wiki/PlayStation_Portable_homebrew#History_of_homebrew

Even going this far: http://www.symantec.com/security_response/writeup.jsp?docid=2005-100615-2317-99
Post 01 Jul 2011, 03:03
View user's profile Send private message Reply with quote
Artlav



Joined: 23 Dec 2004
Posts: 188
Location: Moscow, Russia
Artlav
garystampa wrote:
The only way I know of is how we do it - build a piece of hardware, burn some code into it and blow the fuse. Hand high-level data to it, let it crunch it and hand back results only. Your algorithm is safe inside the firmware.
Not exactly:
http://siliconexposed.blogspot.com/2011/03/microchip-pic12f683-teardown.html

There is no such thing as running and secret, you can only pick one.
Post 01 Jul 2011, 04:09
View user's profile Send private message Visit poster's website Reply with quote
garystampa



Joined: 25 May 2011
Posts: 52
Location: Central FLorida
garystampa
Well at some point you have to throw in the towel. But you can certainly eliminate 99.99% with algorithm that runs in external hardware.
Post 01 Jul 2011, 20:49
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
garystampa wrote:
Code protection is like a padlock. It keeps honest people honest and it only deters thieves. If somebody wants your code, they can get it.

The only way I know of is how we do it - build a piece of hardware, burn some code into it and blow the fuse. Hand high-level data to it, let it crunch it and hand back results only. Your algorithm is safe inside the firmware.
...and then you get the ULTRA-determined people who will figure out what's going on hardware-side and emulate it... and then even your legitimate customers will start using those workarounds because the protection is too much of a nuisance and slows down the program too much Smile

_________________
Image - carpe noctem
Post 04 Jul 2011, 15:18
View user's profile Send private message Visit poster's website Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2913
Location: 0x77760000
typedef
f0dder wrote:
garystampa wrote:
Code protection is like a padlock. It keeps honest people honest and it only deters thieves. If somebody wants your code, they can get it.

The only way I know of is how we do it - build a piece of hardware, burn some code into it and blow the fuse. Hand high-level data to it, let it crunch it and hand back results only. Your algorithm is safe inside the firmware.
...and then you get the ULTRA-determined people who will figure out what's going on hardware-side and emulate it... and then even your legitimate customers will start using those workarounds because the protection is too much of a nuisance and slows down the program too much Smile


Man, you guys are smart. Laughing That is all true indeed. Laughing
Post 05 Jul 2011, 22:30
View user's profile Send private message Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 678
Location: Mar del Plata
Enko
http://www.inner-smile.com/nocrack.phtml
Check some crackers replies to, they have some very good tricks.

Like this one:
http://www.inner-smile.com/nocrk-lett2.htm#carp
Quote:

Debugger detection.
Use the very well documented tricks to detect debuggers, and specifically SoftICE. Modify your protection so it is less restrictive if a debugger is found. This may have the humourous effect that a cracker believes he has figured out how your protection works, only for his crack to fail on all users machines which dont have a debugger running.

Code:
Avoid nagscreens or "Gotcha!" messages
Play with asymetric encryption
Never use meaningful file names such as License.Dat.
Add long delays. to alert
Add short delays. Pause a second or two.
Use checksums in DLL's and in the EXE
Patch your own software!Change your code to call different validation routines each time.
Store serial numbers in unlikely places
Store serial numbers in several places.
Don't use literal strings
Flood the cracker
Have fun with Spaghetti-Code
Use strong encryption
Use a serial which is several KB long
Caution with the Runtime libary! 
Don't rely on "EXE-packers"
Nag screens.(insert code there too)
The rcr/rcl trick (modify carry too)
Stick conditional jumps in. Everywhere.
Use portions of the code as magic number tables.
Play with the cracker's mind.
Don't loose too much time on writing anything that will kill disassemblers or debuggers.
encrypt the name/serial and check if it matches YOUR way of registering the program.
ENCRYPT all the text in the program
Modify your protection so it is less restrictive if a debugger is found
    
Post 18 Jul 2011, 20:38
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2, 3  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.