[quote=92800:@Kem Tekinay]You roll up the windows and lock the doors to stop the joyrider. You add a steering wheel lock to discourage them further, knowing full will that the professional will still get your car. That’s all we are talking about here. We all know the hardcore guys are not going to be stopped.

Right, but recognize that the cost of going “hard core” to recover strings isn’t very high. Your steering wheel lock is no use when the thief has a real cheap helicopter than can jack your car from the air. BTW… did you ever notice that steering wheel locks are only on cars that look like the owner would be broke if he had to make the payment and rent a replacement until insurance paid him off?

[quote=92801:@jim mckay]I also wanted to make it fast, so that my app doesn’t have to suffer performance loss trying to do some very basic obfuscation…

Other costs include unforeseen bugs in (de)obfuscation, etc. Real security is a collection of complicated trade-offs, not just an enormous lock.

Good work Jim. I think Matthews work highlights an issue that appears to have been overlooked or ignored for a long time and it is causing people like yourself to address the issue. Good all round I would say.

I think we just said the same thing.

I wrote wrote a program called “Obfuscate” years ago to do what you are asking and is now on Bob Keeney’s website.


It’s free.

[quote=92811:@Kem Tekinay]I think we just said the same thing.

Not quite. I said the helicopter was cheaper than your steering wheel lock. #WastedEffort

Do absolutely nothing because it would be a #WaistedEffort ?

Aren’t we a bit negative here ?

I like that too. Again, it needs to be an IDE script.

Did you split up the array to be tricky, or because Array was not available at the time?

[quote=92818:@Kem Tekinay]Did you split up the array to be tricky, or because Array was not available at the time?

I was wondering that too.
I wanted the code to be compact so the string could be used from inside the same function where it was created.

[quote=92818:@Kem Tekinay]I like that too. Again, it needs to be an IDE script.

Did you split up the array to be tricky, or because Array was not available at the time?[/quote]
The goal of the program “Obfuscate” is to make it more difficult snoop the data with a hex editor. To that end you base64 encode the data so it is not readily apparent and then randomize the order to make them work even harder to get the data. The other advantage to the Obfuscate generated code is that it is “code” and not a static array.

I was wondering how a static array gets stored in the compiled app. Do you think that the way I’ve done it would make it easier to spot?

Most certainly.

[quote=92817:@Michel Bujardet]Do absolutely nothing because it would be a #WaistedEffort ?

First off, I know a lot about #WaistedEffort. This has nothing to do with my waist.

There is an economic concept called “diminishing returns”. It says that work/effort/investment to some point is productive and past that point is not productive. You typically have to look at the whole context to figure what that point is. So like, let’s say you are thirsty and I give you a bottle of water. Productive. If instead I bring you a water tanker… Not productive.

With the ease of using a low level debugger to pause execution and sniff the stack (or registers, or memory), the point of diminishing returns for obfuscating strings in the binary is exceedingly low. If, for example, you can divine the name of a registration function, you can get a standard Linux command line tool to spit out any calls to it along with parameters passed without any additional garbage data to sift through.

Seriously… HexEncoding sensitive strings is right up to the line of diminishing returns on this.

Brendan, have you tested this or are you speculating? If you’ve tested, fine, but if not, I’ll test it now.

[quote=92828:@Kem Tekinay]Brendan, have you tested this or are you speculating? If you’ve tested, fine, but if not, I’ll test it now.

Please do! I’m very curious.

I just did. No difference.

Just so you can check my logic, here is the code I included in my test project:

  dim arr1() as string = Array( "[!]1[!]", "2", "3" )
  dim arr2( 2 ) as string
  arr2( 0 ) = "[?]5[?]"
  arr2( 1 ) = "6"
  arr2( 2 ) = "7"
  dim arr3() as string
  arr3.Append "[&]8[&]"
  arr3.Append "9"
  arr3.Append "0"

This is what I see in a hex editor.

No matter what you do, there is going to be a single point of failure where you convert the data to a string and no obfuscation solution will help you at that point of attack. So set your expectations accordingly. The goal is to make it a PITA to reverse engineer what you are trying to hide.

One enhancement I thought of adding to Obfuscate was to inject random inert code into the obfuscation code to bury encoded string in a sea of assembly language. Never got around to that. Maybe you want to suggest it to Bob as an enhancement.

Understood. But keeping with your original intent, you can compact the code a bit with Array with no impact on the result in the executable.

I love this conversation, btw.

Among the elementary cryptographic methods, I like the book reference one. Instead of trying to conceal the information locally, use references to a book pages and word order.

What about using as book a big data block such as an image, where the method goes to pick data according to stored pointers ? Sort of a mix between steganography and book reference.

It would become real difficult to figure anything from a hex editor.

Putting it in an array or a string does not really matter. Building it into actual code makes each point of data like an island unto itself.
You could also apply salting techniques to the string you are trying to obfuscate. Another idea would have your code generator break the thing you are trying to hide in to smaller pieces so you can embed different pieces of code across your program and no single spot in the code has the entire string you are trying to hide.

If you want to write your own solution, take my suggestions and implement them and you will have more obfuscation. But again, there is a point of diminishing returns.