Home » Developing U++ » U++ Developers corner » Moving on with supporting old things...
|
|
|
|
|
|
|
|
| Re: Moving on with supporting old things... [message #45965 is a reply to message #45954] |
Mon, 01 February 2016 06:35   |
Novo
Messages: 1371
Registered: December 2006
|
Ultimate Contributor |
|
|
mirek wrote on Sun, 31 January 2016 05:20
In related news, I plan to fully embrace C++11 and drop support for pre-C++11 (I mean, I want to start using C++11 constructs all over the place and stop worrying with old C++ variants).
Mirek
IMHO, it is safe to start using C++14. Even MSVC 2015 upd. 1 supports everything (except of expression SFINAE). 
Regards,
Novo
[Updated on: Mon, 01 February 2016 14:49] Report message to a moderator |
|
|
|
|
|
| Re: Moving on with supporting old things... [message #45970 is a reply to message #45968] |
Mon, 01 February 2016 16:09 |
 |
mirek
Messages: 14014
Registered: November 2005
|
Ultimate Member |
|
|
Tom1 wrote on Mon, 01 February 2016 13:05Hi Mirek,
Is this the death of Bazaar::Protect package, which only works on MSC9, or is there a workaround?
Best regards,
Tom
I keep this in mind, but I have no time and energy to fix it  I have to apologize, but I do not want to hold changes just because Protect...
Why do not you try? It should be quite simple, all you need is to find or implement "length of x86 instruction" algorithm and then replace increments by 1 in 'code scrambler' by increments by length...
Mirek
[Updated on: Mon, 01 February 2016 18:30] Report message to a moderator |
|
|
|
| Re: Moving on with supporting old things... [message #45982 is a reply to message #45970] |
Mon, 08 February 2016 10:16 |
Tom1
Messages: 1224
Registered: March 2007
|
Senior Contributor |
|
|
Hi,
Thanks for looking into this. I need to think this through carefully, since there is a continuously increasing need for going 64-bit anyway and this would not solve that part. So, for now, I'll stick with MSC9 and current U++, and return to this if the other solutions are even more difficult.
Best regards,
Tom
|
|
|
|
| Re: Moving on with supporting old things... [message #46015 is a reply to message #45982] |
Thu, 18 February 2016 15:56 |
mdelfede
Messages: 1308
Registered: September 2007
|
Ultimate Contributor |
|
|
Hi,
sorry for my lack of time to fix protect.... we'd need indeed some other way to implement it, in particular because of
lacking of inline assembler in 64 bit code.
The "scramble just the opcode" way would be a nice workaround, but only for 32 bit windows.
I think that it would be possible to implement a pure C solution, with help of a couple of external assembly routines, but it needs much work and some time which I don't have right now.
I'm just dropping here my idea: we could put a call in front of to-protect code :
.....
DecodeMe(0xaa, 0x23, 0x55, 0x44......some-unique-byte-pattern);
.... some code to encrypt
DecodeEnd(0xaa, 0x23, 0x55, 0x44......some-unique-byte-pattern);
DecodeMe function should be written in pure assembly, and should use return address to locate the code to change.
The DecodeEnd should be a dummy function in order to have an "end pattern" to know where code ends.
In assembly such calls should contain be a sequence of PUSH number PUSH number....., so quite easy to locate, both from external encoder and to internal decoder code.
DecodeMe() function should of course decode just the op-codes as Mirek suggestion.
If I'll find some spare time I'll try to implement it.
Ciao
Massimo
[Updated on: Thu, 18 February 2016 15:56] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Tue Sep 10 13:34:20 CEST 2024
Total time taken to generate the page: 0.02678 seconds
|
Members
Pages
Help
Register
Login
Home
