flat assembler
Message board for the users of flat assembler.
Index
> Main > AntiReverse Teqnique Goto page Previous 1, 2, 3 Next |
Author |
|
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. |
|||
19 Jul 2011, 01:09 |
|
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. 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 |
|||
19 Jul 2011, 03:13 |
|
f0dder 19 Jul 2011, 17:00
ctl3d32 wrote: All this talk remembers me the uncrackable or unhackable PS3. 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. 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. _________________ - carpe noctem |
|||
19 Jul 2011, 17:00 |
|
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. |
|||
19 Jul 2011, 17:05 |
|
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. |
|||
19 Jul 2011, 17:13 |
|
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. 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. 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. _________________ - carpe noctem |
|||
19 Jul 2011, 17:14 |
|
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). |
|||
19 Jul 2011, 18:36 |
|
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 |
|||
19 Jul 2011, 19:28 |
|
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. |
|||
19 Jul 2011, 19:40 |
|
Enko 19 Jul 2011, 19:56
Quote:
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. |
|||
19 Jul 2011, 19:56 |
|
typedef 19 Jul 2011, 22:29
Why can't we just write the code and give it up ?
|
|||
19 Jul 2011, 22:29 |
|
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. |
|||
19 Jul 2011, 23:19 |
|
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] |
|||
20 Jul 2011, 01:05 |
|
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. |
|||
20 Jul 2011, 02:33 |
|
typedef 20 Jul 2011, 03:23
^^ You just shit a d
|
|||
20 Jul 2011, 03:23 |
|
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? |
|||
20 Jul 2011, 03:58 |
|
typedef 20 Jul 2011, 05:56
bitshifter wrote:
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. |
|||
20 Jul 2011, 05:56 |
|
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. |
|||
20 Jul 2011, 12:19 |
|
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. |
|||
20 Jul 2011, 13:47 |
|
Goto page Previous 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.