flat assembler
Message board for the users of flat assembler.

Index > Main > AntiReverse Teqnique

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



Joined: 20 Feb 2006
Posts: 4330
Location: Now
edfed 19 Jul 2011, 01:09
a good antireverse technique is open source.

when the source of a program is open, there is no need for any reverse. Smile
Post 19 Jul 2011, 01:09
View user's profile Send private message Visit poster's website Reply with quote
ctl3d32



Joined: 30 Dec 2009
Posts: 206
Location: Brazil
ctl3d32 19 Jul 2011, 03:11
All this talk remembers me the uncrackable or unhackable PS3. Smile

No matter what you do. Someone will keygen or crack your protection. Anyway, you just have to ponder the amount of your time you wanna spend on something that, in the end, will be useless, i think...

I had an idea now that will stop many crackers: Create a driver and let it check the serial routine. Since you can't edit it as simple as an executable (because of driver signature, i think), it will be a pain in the ass.


Last edited by ctl3d32 on 19 Jul 2011, 03:13; edited 1 time in total
Post 19 Jul 2011, 03:11
View user's profile Send private message Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 19 Jul 2011, 03:13
Code:

;
;
; NOTE:  Assume this is a windows valid executable code but without the PE structure
;

format binary as ".myExecutableCode"

;Header 16 bytes (4 DWORDS)

dd code_pointer ;code section pointer 
dd data_pointer ;data section pointer
dd Other
dd Other

code_:

;end code

data_:

;end data

    


Now in file, encrypt.asm

Code:

;This is just a simple encryption macro

macro encrypt data,size,key
{

;use LODSD, but first check for even bytes else pad with zeroes
;Using LODSD will make sure you encrypt 4 bytes each cycle, which will match your key

; Maybe for extra mmmphhh!, you can also add an RGN (Randomly Generated Number).
}
    


After encrypting , embed the encrypted file as a binary resource file, then when needed, build it at run time (using PE structures, then call it)

Code:
resource = LoadResource( myExecutableEncryptedBinary)
;call decrypt macro

decrypt,resource,size,key

;call a macro to build the PE

buildPE,resource,output_buffer

mem = VirtualAlloc( sizeof(output_buffer) )
WriteProcessMemmory ( mem, output_buffer)
VirtualProtect( mem, PAGE_EXECUTE)
; then, jump to the dynamically built exe

    


This process is a complex one because you have to be careful with the way you handle addresses.


That was just an example. But someone can still crack it, no doubt. Very Happy

More info:
MSDN Library wrote:
To execute dynamically generated code, use VirtualAlloc to allocate memory and the VirtualProtect function to grant PAGE_EXECUTE access.

http://msdn.microsoft.com/en-us/library/aa366887%28v=VS.85%29.aspx
Post 19 Jul 2011, 03:13
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 19 Jul 2011, 17:00
ctl3d32 wrote:
All this talk remembers me the uncrackable or unhackable PS3. Smile

No matter what you do. Someone will keygen or crack your protection. Anyway, you just have to ponder the amount of your time you wanna spend on something that, in the end, will be useless, i think...
But how long did it take until PS3 was hacked? How many legitimate games have been sold during that period that would have been pirated instead? Keep in mind that the console companies generally don't make their money on the console unit but on the games.

ctl3d32 wrote:
I had an idea now that will stop many crackers: Create a driver and let it check the serial routine. Since you can't edit it as simple as an executable (because of driver signature, i think), it will be a pain in the ass.
Driver-based protections can be a bit harder to crack, but it's still being done. Yes, x64 is bitchy about drivers being signed, but there's workarounds. And if enough software was released doing checks in kernel-mode, the workarounds would be mainstreamed. And if the application doesn't need kernel-mode, the stuff would just be yanked out of KM, it's not like reverser don't know how to cut up & stitch stuff back up.

Personally, if I saw a product doing serial checks in kernel mode, I'd choose another product to spend my money on, as it'd be a good sign of the developers having lost all common sense.

_________________
Image - carpe noctem
Post 19 Jul 2011, 17:00
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4330
Location: Now
edfed 19 Jul 2011, 17:05
i suppose that several debuggers uses something like system irqs and interrupts to manage the child code and memory, then, maybe by checking ints and irqs, it can be possible to desactivate the execution of the decrypter, and then, if the reverser try to disassemble it, and execute it via a debugger, it will not work.

but as i said, i don't see any reason to don't share the source code.

the code is nothing, all that is important is data (especially personnal datas, that need to be protected), and here, data protection is another topic.
Post 19 Jul 2011, 17:05
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20300
Location: In your JS exploiting you and your system
revolution 19 Jul 2011, 17:13
I have mentioned in other threads here previously but it is worth repeating here. I use a number of software products that come with hardware dongles. Since there was no suitable replacements for these specialised programs I had no choice but to use them. But the major headache with these things is the dongles. The dongles usually require kernel mode drivers. The dongles can go faulty. The dongles can get lost. The dongles cannot plug in to new systems with updated I/O ports. Often only one dongle can be used at a time limiting the computer to only one program at a time and requiring the hassle of swapping dongles to use other programs.

Anyhow the upshot of all this is that the dongles make it troublesome to use the software and makes me want to change to another product that doesn't require dongles.

Of course, such things like dongles only last for a day or so here before the software is patched to run without any requirement for dongles ever again. Why do the manufacturers still persist in wasting time with all the dongle code and the testing it entails? And the worst part is it just makes the software more expensive to make, and users have to pay extra for the privilege of having a restrictive dongle.
Post 19 Jul 2011, 17:13
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 19 Jul 2011, 17:14
edfed wrote:
i suppose that several debuggers uses something like system irqs and interrupts to manage the child code and memory, then, maybe by checking ints and irqs, it can be possible to desactivate the execution of the decrypter, and then, if the reverser try to disassemble it, and execute it via a debugger, it will not work.
"Anything you try will be in vain" Smile

Reversers don't tend to depend on just a debugger, though - especially not with powerful disassemblers like IDA being available. And with QEMU and Bochs source code available, you can be sure that some groups have really interesting private tools.

edfed wrote:
but as i said, i don't see any reason to don't share the source code.
Makes a lot of sense for companies that want to make money by selling programs rather than selling support...

edfed wrote:
the code is nothing, all that is important is data (especially personnal datas, that need to be protected), and here, data protection is another topic.
Depends a lot on the product - if you have a specially optimized algorithm that gives you a 25% performance gain over your nearest competitor, then the code definitely is worth something.

_________________
Image - carpe noctem
Post 19 Jul 2011, 17:14
View user's profile Send private message Visit poster's website Reply with quote
ctl3d32



Joined: 30 Dec 2009
Posts: 206
Location: Brazil
ctl3d32 19 Jul 2011, 18:36
f0dder wrote:
But how long did it take until PS3 was hacked? How many legitimate games have been sold during that period that would have been pirated instead? Keep in mind that the console companies generally don't make their money on the console unit but on the games.


It took 1 year since Sony pissed of customers by removing OtherOS (many bought a PS3 because of that).
Post 19 Jul 2011, 18:36
View user's profile Send private message Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 676
Location: Mar del Plata
Enko 19 Jul 2011, 19:28
typedef:

1)what is the advantage of your example, compared to have part of your own source encrypted?
I mean, almost the same thing, but building new pe is not required.

2)is there some macro in fasm to build a pe from a binary without header?

3)Why don't have the resourcde section executable:
Code:
section '.rsrc' resource data readable writeable executable
    

decrypt the resource and jump there. (this way is the same as having a part of the executable encrypted)
(I know, it looks spooky)

4)why not have the full executable encrypted, put it as resource, decrypt, vritual alloc and then jmp there?
The same as your example, but the encrypted executable have pe.

Thanks a lot Smile
Post 19 Jul 2011, 19:28
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22 19 Jul 2011, 19:40
I think we've covered this, but encryption doesn't help because the code will need to be DEcrypted to run. You can just read the process memory/dump of the decrypted code.

This is one of the main reasons the big players are all pushing for CLOUD COMPUTING. They will open up the APIs and the interfaces as open source, but all their proprietary search algorithms and web service functions are locked away in their secured data-centers where crackers can't get to them. Client - (Remote)Server is the most effective anti-reversing technique.
Post 19 Jul 2011, 19:40
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 676
Location: Mar del Plata
Enko 19 Jul 2011, 19:56
Quote:

I think we've covered this, but encryption doesn't help because the code will need to be DEcrypted to run

It's not to make it imposible but pain in the ass to reverse.

There will be always exeprt crackers who will reverse your code, but not the 100% of crackers are expert crackers. It's about limit the posibilities.
Post 19 Jul 2011, 19:56
View user's profile Send private message Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 19 Jul 2011, 22:29
Why can't we just write the code and give it up ?
Post 19 Jul 2011, 22:29
View user's profile Send private message Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 676
Location: Mar del Plata
Enko 19 Jul 2011, 23:19
typedef wrote:
Why can't we just write the code and give it up ?

becouse it wouldn't be fun for the reversers.
Post 19 Jul 2011, 23:19
View user's profile Send private message Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 20 Jul 2011, 01:05
?

You just shit an o somewhere in your sentence that was not needed.
Just wanted to let you know that.

Code:
lea rax,[fasm_users]
inc [rax+typedef_index_id*8]
    
Post 20 Jul 2011, 01:05
View user's profile Send private message Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 676
Location: Mar del Plata
Enko 20 Jul 2011, 02:33
It was kind of healthy joke.
What I wanted to say is, if someday, I need to protect somehow my code, at least, I'll try to do my best, so the "lame" crackers won't stand a chance.


pd: I have about one mistake per sentence in my spelling or more. Just get over the idea. Laughing
Post 20 Jul 2011, 02:33
View user's profile Send private message Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 20 Jul 2011, 03:23
^^ You just shit a d Very Happy
Post 20 Jul 2011, 03:23
View user's profile Send private message Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 796
Location: Massachusetts, USA
bitshifter 20 Jul 2011, 03:58
You can keep noobs from running your app in debugger,
but you will never stop crackers from hex viewing the binary.
So you want anti-debug measures like microsoft does?
Post 20 Jul 2011, 03:58
View user's profile Send private message Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 20 Jul 2011, 05:56
bitshifter wrote:

So you want anti-debug measures like microsoft does?


10% of code is product ( 2% is (Open, Save/As, Print/Preview) 3% is all that other fancy stuff that nobody uses. ) the other 5% is (Word format viewer/manipulator etc)

90% of code is security features (IsDebuggerPresent(), IsCopyGenuine( (MS.Products.Office[WORD]) ) )

plus 100% of resources.

Very Happy

Laughing
Post 20 Jul 2011, 05:56
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4330
Location: Now
edfed 20 Jul 2011, 12:19
not true, ms software are not so bloated (when compatible with 98 of course).

to compare with third party proprietary softwares for windows that are frequentlly more than 1000% bigger than the same in free or open source.

compare acrobat reader with any free pdf viewer.
Post 20 Jul 2011, 12:19
View user's profile Send private message Visit poster's website Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 676
Location: Mar del Plata
Enko 20 Jul 2011, 13:47
efded, acrbate reader is free. So I think theres no anti reverse stuff.

why adobe pdf is so heavy... I don't know. In my pc I can run only adobe 6. The last version will put the pc very low. But the strange thing, chrome has adobe reader embeded, one of the last versions, so I open the pdf with chrome, and it works preaty well. Still foxtit, sumantra and others are lighter.
Post 20 Jul 2011, 13:47
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  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-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.