Recent

Author Topic: New security question  (Read 13190 times)

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: New security question
« Reply #15 on: February 22, 2017, 02:40:52 pm »
Well,
- you don't need a super computer to divide a dictionary attack(1 plate)  and a brute force(the other 7)  over a single rack of I7's or something. That's at most a fancy gaming machine. (If I look what my stepson has..., or my own RPi cluster) And the setup I referred to if you want to know. There are graphics cards mis-used for computing here. :o
- I always advocate that OP's kind of schemes are absolutely pointless and not based on computer science.
- I, curious as I am, always expect the worst from humans. That's usually the case. I am a sad old man. But often right. 8-)

Therefor I give discouraging, but correct, answers on such questions.

As an aside:
In any case: the Dutch government is rich enough to buy said hardware in bulk, but at the same time we don't pay enough taxes to have the knowledgeable staff to operate it.
Even if it's 52%.
« Last Edit: February 22, 2017, 02:48:17 pm by Thaddy »
Specialize a type, not a var.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: New security question
« Reply #16 on: February 22, 2017, 02:56:59 pm »
For OP:
Try GetMem's suggestion,but maybe use UPX instead of zip. Don't expect too much of it in terms of real security, As I hopefully explained.
Specialize a type, not a var.

balazsszekely

  • Guest
Re: New security question
« Reply #17 on: February 22, 2017, 03:00:05 pm »
@Jacmoe
For Gods sake read the sentence after the bold text:
Quote
I ask this because if an attacker does memory dumps, he would have the least chance of finding some key in memory, but he would never know when and where it would serve, and would never unravel all the encryption levels of each information without the execution of the program paused at surgically accurate times.
My method prevents memory dump. To be more precise you can only dump it if you know the password as I stated before in one of my previous post.

@Thaddy
Your answer as far as I'm concern is useless and obviously you post it just for the sake of posting. Do this: zip a file with 20 a char password then brute force it, with whatever setup you have at home. You won't be able to crack it.

I detaching myself from this thread...

lainz

  • Hero Member
  • *****
  • Posts: 4460
    • https://lainz.github.io/
Re: New security question
« Reply #18 on: February 22, 2017, 03:08:59 pm »
Quote
Do this: zip a file with 20 a char password then brute force it, with whatever setup you have at home. You won't be able to crack it.

Quote
To brute force the entire keyspace it will take about
857 quadrillion years

857386888177072000 years 34 days 6 hours 11 minutes and 32 seconds
(2.0725274851017787e+28 password combinations)

http://calc.opensecurityresearch.com/

20 char
zip
ualpha (taking only into consideration A..Z)

Quote
This list was generated on an 3.4GHz Intel Core i7-2600K
« Last Edit: February 22, 2017, 03:10:46 pm by lainz »

jacmoe

  • Full Member
  • ***
  • Posts: 249
    • Jacmoe's Cyber SoapBox
Re: New security question
« Reply #19 on: February 22, 2017, 03:10:39 pm »
@Jacmoe
For Gods sake read the sentence after the bold text
[..]
I detaching myself from this thread...
Please don't detach!
If anyone should detach it would be me, and most probably Thaddy.

OP never asked how to do simple, yet effective security.
He has been on this since before 2012, has developed a component (library?), which seems to focus on practical levels of security, and now wants to continue to improve the security.
I don't think it's possible to ask a better question: it is extremely well prepared, and it is specific.

So now that I am detaching, could you maybe reattach, because I don't know much about security.
more signal - less noise

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: New security question
« Reply #20 on: February 22, 2017, 03:13:24 pm »
NOTIFICATION (it is not an apology)  >:D >:D >:D

It was not my intention to prove GetMem wrong
It is my intention to answer security related questions in a proper manner
It is part of my line of work (FGS)
I described only repeatable, verifiable hardware and software that is in actual use.
I described only the reality.

Sad that GetMem, whom I respect very much, felt he had to disconnect from this  thread.

For OP: sorry about the confusion.
I hope that you understand that there is no such thing as unhackable, but you can prevent normal users from using your software without your permission to some extend.
« Last Edit: February 22, 2017, 03:15:36 pm by Thaddy »
Specialize a type, not a var.

jacmoe

  • Full Member
  • ***
  • Posts: 249
    • Jacmoe's Cyber SoapBox
Re: New security question
« Reply #21 on: February 22, 2017, 03:23:37 pm »
For OP: sorry about the confusion.
I hope that you understand that there is no such thing as unhackable, but you can prevent normal users from using your software without your permission to some extend.
I sincerely hope that too, considering that he is continuing a 5 year conversation about security - did you read the other topic he linked to? and considering that he has written a security component called LockSmith.
more signal - less noise

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: New security question
« Reply #22 on: February 22, 2017, 03:36:49 pm »
Thermic lance? Beats any locksmith. https://nl.wikipedia.org/wiki/Aage_Meinesz I knew him. He also had a purple Rolls Royce.
« Last Edit: February 22, 2017, 03:39:26 pm by Thaddy »
Specialize a type, not a var.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: New security question
« Reply #23 on: February 22, 2017, 05:40:43 pm »
considering that he has written a security component called LockSmith.
I did. and I did respond. And I have real experience, (closer to 50 than 5) And a proper education.
Sorry, sometimes I can be a "know it all". But on this matter that's approximately the case.

You want something like "locksmith"? Easy. That's the problem.
Specialize a type, not a var.

ezlage

  • Guest
Re: New security question
« Reply #24 on: February 22, 2017, 07:35:08 pm »
I dont know all the details, but some platforms (most modern ones) have hardware breakpoints.

I know they exist to monitor memory. (data breakpoints) They can detect memory reads. So I guess they can also detect if the machine code at a certain location is read. (Never tried, but you can test that with gdb, even in the IDE, just pretend some asm statement in your code is a byte variable, and set a read-data-breakpoint)

Your app may also be in a virtual machine, with the entire machine being debugged. Including some code being emulated, so that access to cpu registers (or where ever hardware breakpoints are ) may not return the true value. Similar to the concept of blue pill https://en.wikipedia.org/wiki/Blue_Pill_(software) There is also a link on how to try detecting such scenarios.

Martin_fr, Thanks for the info. It is important for me to know this so I do not overestimate my attempts to increase security.

Every proper debugger will have breakpoints (at the asm level) and every binary can be debugged. The binary itself will not be changed. So there really is no way to stop your program from being debugged.
That's why it is a fundamental mistake to include security information in the executable itself.

Thaddy, I understand perfectly. But my case is this:
I am developing a program called Semper, which will be a personal and financial manager.

People avoid using web-based financial managers for fear of having their data accessible to other individuals. For this reason, I am developing the Semper in portable form (usbstick, initially pendrive, in the future it may be a hardware encryption dongle or something like that).

So as the application will be portable and offline, security needs to be enforced, and a minimum of security information needs to be in the executable. Of course, getting the binary security information will not give you access to the data because the security features will have passwords or data entered by the user as well.

Example of the thing you don't want to exist: http://man7.org/linux/man-pages/man2/ptrace.2.html.

To accomplish what you want to do you need dedicated hardware with a memory space the processor can't access.

guest, you're right. As I said in reply to Thaddy, this solution will be adopted in the future. At the moment I can not get a project or develop something like this because of lack of financial resources.

I think he knows that his software can be debugged, and that there is no absolute protection.

That is why he checks for modifications: Normal breakpoints change the code in memory. (the breakpoint is a substitute machine instruction)
Of course a hacker can circumcise his checks....

So he tries to make it as hard as possible.... In the end, some hacker will still succeed (IMHO). I do not know of any software that has not been hacked.

But anyway, I think he knows that. So his decisions.

And that is where hardware breakpoints are different. they do not modify the code in memory. So they make it one step easier for the attacker.
Together with a virtual machine, that can hide the hardware breakpoints from detection (emulation / blue pill), it will be very hard for his software to detect that it is being debugged.

Martin_fr, the situation is exactly as you said.
I understand that there is no absolute security, but I must seek as much as possible.
Any difficulty for the cracker can give me time to raise funds and adopt hardware encryption dongles, or make the stolen information understandable only when it is no longer relevant to the owner.

Just my 2 cents, but in addition to what everyone have said, you assume your anti-debug via checksum will prevent anyone to use soft breakpoints, the question is more about IMHO ; how long will it take to patch the function that check your checksum?
Also don't forget about dead-listing, with tools like IDA or radare2 https://rada.re/r/

MementoMojito, your help will be very useful. I will be able to understand a little more about the modus operandi of an eventual interested in violating the security of my application.

Quote
MementoMojito
Are you talking about 7z? :)

I did this many times before and it works like this:
You have an executable that you want to protect, let's call it project1:
1. Zip project1 with a relatively large password(you don't have to go to extremes). I mean create a hash from the password, then the hash will be the password for zip
2. Create a second executable(project2), add the zip as resource
3. Send the password to your client and make project2 publicly available to everyone

With a large enough password, nobody will be enable to unzipp project1, bruteforce is simply to slow for passwords larger then 7-8 characters(no supercomputers here). So even if you're revers engineering project2 you cannot extract any usable information from project1 since it remains zipped all the time.
When project2 starts, user enters the password. Project2, after a hash, will try to unzip project1 in memory, if the process is successful project2 launch project1 directly form memory. It similar to self extracting executable but project1 never "touches" the HDD/SDD. Without a valid password no memory dump is possible.

GetMem, I'm interested in your method. How do you run an application directly from memory without it being saved to disk?
I would be vulnerable in any way, since a DUMP after running would reveal all the instructions, but I see possibility to take advantage of this method.

For OP:
Try GetMem's suggestion,but maybe use UPX instead of zip. Don't expect too much of it in terms of real security, As I hopefully explained.

Thaddy, I will evaluate the UPX, as you suggested. Thanks again.
I agree with you about the vulnerability coming from the user, so in addition to the user entries that make up part of the security, I want to have others at the application level. So if someone fools the user, they still have many other levels of security to overcome.

Quote
Do this: zip a file with 20 a char password then brute force it, with whatever setup you have at home. You won't be able to crack it.

Quote
To brute force the entire keyspace it will take about
857 quadrillion years

857386888177072000 years 34 days 6 hours 11 minutes and 32 seconds
(2.0725274851017787e+28 password combinations)

http://calc.opensecurityresearch.com/

20 char
zip
ualpha (taking only into consideration A..Z)

Quote
This list was generated on an 3.4GHz Intel Core i7-2600K

lainz, great tool. It will be useful too. Thank you!

@Jacmoe
For Gods sake read the sentence after the bold text
[..]
I detaching myself from this thread...
Please don't detach!
If anyone should detach it would be me, and most probably Thaddy.

OP never asked how to do simple, yet effective security.
He has been on this since before 2012, has developed a component (library?), which seems to focus on practical levels of security, and now wants to continue to improve the security.
I don't think it's possible to ask a better question: it is extremely well prepared, and it is specific.

So now that I am detaching, could you maybe reattach, because I don't know much about security.

Jacmoe, I really like to learn. So, since I came across the problem of (no) absolute security, I did not want to give up my project (Semper). However, I would not feel well making it available to people knowing that it would not be difficult to compromise their privacy.

I have been working on the Semper project for a very limited time, but since 2010. The security part was getting so complex that I decided to break it down into another project (2012), which is a component that I can use in other products as well.

NOTIFICATION (it is not an apology)  >:D >:D >:D

It was not my intention to prove GetMem wrong
It is my intention to answer security related questions in a proper manner
It is part of my line of work (FGS)
I described only repeatable, verifiable hardware and software that is in actual use.
I described only the reality.

Sad that GetMem, whom I respect very much, felt he had to disconnect from this  thread.

For OP: sorry about the confusion.
I hope that you understand that there is no such thing as unhackable, but you can prevent normal users from using your software without your permission to some extend.

Do not worry, Thaddy. You are always willing to help me both in this post and in other older ones. The other members are also present in my posts, so I thank you all! I hope to be able to one day repay all the help.
« Last Edit: February 22, 2017, 07:43:03 pm by ezlage »

ezlage

  • Guest
Re: New security question
« Reply #25 on: February 22, 2017, 07:45:35 pm »
Friends, sorry by my poor english.

Here in Brazil I have no one to teach me english, so I try to do my best.

MementoMojito

  • Jr. Member
  • **
  • Posts: 63
Re: New security question
« Reply #26 on: February 22, 2017, 09:36:37 pm »
@ezlage:
My point regarding the way you want to detect soft breakpoints is that you will have to obfuscate really badly the function that will watch portions of your code via a checksum (or by searching for INT3 bytes). As soon as the call to this function will be nop'd it will be useless.
And same goes for hardware breakpoints, you can try to detect them but what will protect the guard function itself at runtime?

Also you should keep in mind that a lot of anti-debug/anti-anti-debug tricks are platform specific. For example the ptrace() trick on Linux or IsDebuggerPresent() on Windows, the list is endless. Same would go for breakpoints detection.
So depending if you want your project to be platform specific or not.

Now I am sure GetMem will answer, but yes what he does is basically an encrypted packer. So it will protect static and dynamic reversing as long as the attacker doesn't have the password to unpack it.
UPX is also a packer but it doesn't support encryption AFAIK, however nothing prevent you to use UPX and encrypt the packed binary with AES256 or so.
Not sure how an exe packed with UPX would work when being ran from memory tho.


hrayon

  • Full Member
  • ***
  • Posts: 118
Re: New security question
« Reply #27 on: February 22, 2017, 09:48:52 pm »
Hi ezlage, how about accepting that breakpoints will exist?
You can complicate the debugger (person who is debugging) spreading codes so simple within your code:
Code: Pascal  [Select][+][-]
  1. ...
  2. l_TDateTime_start := now();
  3. //Put some of your code here that naturally spends a few milliseconds
  4. l_TDateTime_end := now();
  5. if ((24.0*3600.0*(l_TDateTime_end - l_TDateTime_start)) < 1.0) then //Converted to seconds only for didactic purposes
  6. begin
  7.   //Your plan to dominate the world - your safe code
  8. end
  9. else //Probably debugging!!
  10. begin
  11.   //Go to "disneyland" part of your code, and there, after some random rounds, exit.
  12. end
  13. ...
  14.  

In another place, do again, but go to another touristic places if you detect a possible debugger...  :D

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: New security question
« Reply #28 on: February 23, 2017, 01:48:00 am »
I am developing the Semper in portable form (usbstick, initially pendrive, in the future it may be a hardware encryption dongle or something like that).
This thread might be interesting for you:
http://forum.lazarus.freepascal.org/index.php/topic,13000.msg67843.html#msg67843
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

d.ioannidis

  • Full Member
  • ***
  • Posts: 221
    • Nephelae
Re: New security question
« Reply #29 on: February 23, 2017, 11:12:31 am »
Hi,

  how about this Anti-forensic, safe storage of private keys article ...

regards,

 

TinyPortal © 2005-2018