Index
> Main > AntiReverse TeqniqueGoto page 1, 2, 3 Next |
| Author |
|
|
cod3b453 30 Jun 2011, 16:55
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.
|
|||
30 Jun 2011, 16:55 |
|
|
Enko 30 Jun 2011, 17:46
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 |
|||
|
30 Jun 2011, 17:46 |
|
|
JoeCoder1 30 Jun 2011, 18:00
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.
|
|||
|
30 Jun 2011, 18:00 |
|
|
Enko 30 Jun 2011, 18:04
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? |
|||
|
30 Jun 2011, 18:04 |
|
|
JoeCoder1 30 Jun 2011, 18:44
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
|
|||
|
30 Jun 2011, 18:44 |
|
|
r22 30 Jun 2011, 18:48
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. |
|||
|
30 Jun 2011, 18:48 |
|
|
cod3b453 30 Jun 2011, 19:00
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 |
|||
|
30 Jun 2011, 19:00 |
|
|
Enko 30 Jun 2011, 19:13
Thank you all for the explanation. With this, I have now a much great idea how to aim this
Thanks a lot agian |
|||
|
30 Jun 2011, 19:13 |
|
|
garystampa 30 Jun 2011, 22:17
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. |
|||
|
30 Jun 2011, 22:17 |
|
|
Enko 30 Jun 2011, 22:52
garystampa wrote:
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. |
|||
|
30 Jun 2011, 22:52 |
|
|
garystampa 01 Jul 2011, 00:16
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. |
|||
|
01 Jul 2011, 00:16 |
|
|
Enko 01 Jul 2011, 00:43
garystampa wrote: The smartcard sounds like it's just data storage? 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) |
|||
|
01 Jul 2011, 00:43 |
|
|
typedef 01 Jul 2011, 02:58
r22 wrote:
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   |
|||
|
01 Jul 2011, 02:58 |
|
|
typedef 01 Jul 2011, 03:03
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. +1
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 |
|||
|
01 Jul 2011, 03:03 |
|
|
Artlav 01 Jul 2011, 04:09
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. http://siliconexposed.blogspot.com/2011/03/microchip-pic12f683-teardown.html There is no such thing as running and secret, you can only pick one. |
|||
|
01 Jul 2011, 04:09 |
|
|
garystampa 01 Jul 2011, 20:49
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.
|
|||
|
01 Jul 2011, 20:49 |
|
|
f0dder 04 Jul 2011, 15:18
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.  _________________  - carpe noctem |
|||
|
04 Jul 2011, 15:18 |
|
|
typedef 05 Jul 2011, 22:30
f0dder wrote:
Man, you guys are smart.  That is all true indeed. |
|||
|
05 Jul 2011, 22:30 |
|
|
Enko 18 Jul 2011, 20:38
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:
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 |
|||
|
18 Jul 2011, 20:38 |
|
| Goto page 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|