| View previous topic :: View next topic |
| Author |
Message |
DeWild1
Joined: 30 Apr 2006
Posts: 176
Location: Shigle Springs
|
 Posted: Thu Feb 21, 2008 6:19 pm Post subject: |
 |
|
SKAN, I am a simpleton so please forgive my question if it is stupid. 
ASM is a low level language and with my limited understanding, I doubt it could be translated into AHK.
Your public (compiled) version from your web site does a message before attempting to debug and after attempting to debug.
If possible, could you make a customized version that simply kills our program.
A simpleltin like me could just use
| Code: | fileinstall, yourprogram.exe, %A_Temp%\yourprogram.exe
PID := DllCall("GetCurrentProcessId")
filedelete, %A_Temp%\mypid.txt
fileappend, %PID%, %A_Temp%\mypid.txt
run, %A_Temp%\yourprogram.exe
|
Your program could just read what our PID is so if it detects a debugger, it would know what to kill.
Also, will your method of checking the memory work for all debuggers?
Thank you for sharing your knowledge and tallent.
_________________
CPULOCK.com
virusSWAT.com
GuaranteedPCFIX.com
911PCFIX.com |
|
| Back to top |
|
 |
SKAN
Joined: 26 Dec 2005
Posts: 6084
|
| Posted: Thu Feb 21, 2008 6:29 pm Post subject: |
|
|
| DeWild1 wrote: | | ASM is a low level language and with my limited understanding, I doubt it could be translated into AHK. |
There is a way through which assembly code can be executed from AHK.
I know nothing about ASM. If some ASM coder from our forum can give us a Dll Function that can monitor AHK process space, then we can absorb the function into our text based script as demonstrated by Laszlo
Hope you get the picture.
JGR is not around. Maybe Zippo() can give it a try. If nobody does, maybe we can request Adam ( kakeeware.com ).
 |
|
| Back to top |
|
|
DeWild1
Joined: 30 Apr 2006
Posts: 176
Location: Shigle Springs
|
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4033
Location: Pittsburgh
|
| Posted: Thu Feb 21, 2008 7:12 pm Post subject: |
|
|
How much security do you want? The debugger detector (assembler code posted above) only works against simple user mode debuggers running in unmodified Windows. An attacker can hack the OS, so system calls return anything. Also, there are HW based attacks: logic analyzers connected to memory lines. A few thousand dollar investment and a little patience reveals the content of any memory location. RAM chips retain their contents for a short time after power down, so they can be moved to another computer for inspection, and so on.
If you really want to protect your code, you need some professional tools, which obfuscate code and data. The resulting program will be larger, but figuring out what the program does becomes very hard. Inserting dummy Windows system calls makes it difficult to figure out, which ones are really used, which ones are fake. This is very expensive and needs expertise, so for higher security you have to pay and work a lot. |
|
| Back to top |
|
|
Oberon
Joined: 18 Feb 2008
Posts: 458
|
| Posted: Thu Feb 21, 2008 7:26 pm Post subject: |
|
|
| It should be mentioned that the said security though obscurity techniques are not fail safe and must be discouraged wherever possible. If your implementation is robust and you distribute your program to trusted users this should not be a concern. It's common to hear news of people cracking blueray DRM and hacking Windows kernels now so your code will never, ever be fully secure from prying eyes. |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4033
Location: Pittsburgh
|
| Posted: Thu Feb 21, 2008 7:42 pm Post subject: |
|
|
| That’s true. Of course, code and data obfuscation is not done though obscurity, but through cryptographic techniques. The algorithms are public, but depend on secret keys. |
|
| Back to top |
|
|
SKAN
Joined: 26 Dec 2005
Posts: 6084
|
| Posted: Thu Feb 21, 2008 7:48 pm Post subject: |
|
|
Just an Idea.
1) Learn how to compile AutoHotkey Source. See:
2) Write a parser to Rename all functions and commands with generated random unique 10 digit numbers ( should keep a track in Commands.txt ) and then compile AutoHotkey source.
3) Also make Chr(160) the default seperator instead of a Comma.
3) Write a script parser that can toggle a script between AHK and Obfuscated AHK
4) Write scripts / test in offcial copy of AHK - obfuscate it and then compile it with the newer copy of AutohotkeySC.bin
Not sure whether this would work, though.
 |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4033
Location: Pittsburgh
|
| Posted: Thu Feb 21, 2008 7:53 pm Post subject: |
|
|
| It could work, but too easy to break. |
|
| Back to top |
|
|
DeWild1
Joined: 30 Apr 2006
Posts: 176
Location: Shigle Springs
|
| Posted: Thu Feb 21, 2008 8:03 pm Post subject: |
|
|
Laszlo,
Personally, I think that if anyone has the time and money to do hardware level stuff or the knowhow to hack the OS, they could recreate anything we make, and most likely better...  Or just spend half that amount and pay me for the code..
A user mode debugger would stop most small to medium sized companies who can afford a semi hi level programming team. That is all I am worried about.
There are many steps people can take to try fool and complicate, but in AHK, if they can pull our unencrypted scripts out of memory, it is just like reading a book. 
I would be happy with a way to encrypt the script in memory, and the other steps I do, and with hard passwords that have things like §Nß>ß in it, and with some way to self terminate if a user mode debugger was detected, I would be a happy man! 
_________________
CPULOCK.com
virusSWAT.com
GuaranteedPCFIX.com
911PCFIX.com |
|
| Back to top |
|
|
DeWild1
Joined: 30 Apr 2006
Posts: 176
Location: Shigle Springs
|
| Posted: Thu Feb 21, 2008 8:47 pm Post subject: |
|
|
| Laszlo wrote: | | That’s true. Of course, code and data obfuscation is not done though obscurity, but through cryptographic techniques. The algorithms are public, but depend on secret keys. |
I use your TEA encryption for my INI's and other text, thank you.
You are amazing with numbers. It is the only part of programming that is fun for me. (trying to understand that complicated stuff took me a day, but it came easier to me than normal AHK stuff. My mind loves math.)
If we could apply your cryptographic techniques to the scripts in memory, and have the algorithms - private key in the "hard" code made through our own custom Autohotkey.exe, would that work?
Edit: I am referring to SKAN's post above,
| Quote: | Just an Idea.
1) Learn how to compile AutoHotkey Source. See:
Compile AutoHotkey using Visual C++ 2005 Express Edition posted by corrupt |
_________________
CPULOCK.com
virusSWAT.com
GuaranteedPCFIX.com
911PCFIX.com
Last edited by DeWild1 on Thu Feb 21, 2008 11:35 pm; edited 1 time in total |
|
| Back to top |
|
|
engunneer
Joined: 30 Aug 2005
Posts: 6804
Location: Pacific Northwest, US
|
|
| Back to top |
|
|
ManaUser
Joined: 24 May 2007
Posts: 904
|
| Posted: Thu Feb 21, 2008 9:45 pm Post subject: |
|
|
Very interesting. I had no idea memory did that. |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4033
Location: Pittsburgh
|
| Posted: Thu Feb 21, 2008 9:55 pm Post subject: |
|
|
| Data retention in RAM is known for 30 years. Felten & al. provided data about current laptops and implementation problems of encryption software. Still, the attack is not very practical: you have to grab a PC immediately after it was shut down, without the owner noticing it. |
|
| Back to top |
|
|
ManaUser
Joined: 24 May 2007
Posts: 904
|
| Posted: Thu Feb 21, 2008 11:52 pm Post subject: |
|
|
| Laszlo wrote: | | Data retention in RAM is known for 30 years. Felten & al. provided data about current laptops and implementation problems of encryption software. Still, the attack is not very practical: you have to grab a PC immediately after it was shut down, without the owner noticing it. |
Yes, that would be unlikely. It sounds like the situation they had in mind was where the computer was left unattended while running or hibernating. Of course everyone should (not does) know that's a security risk anyway.
But the implications for trying to protect AutoHotkey process data a obvious as well. You can use all the tricks in the book to outsmart debuggers etc, but if they can actually power down and switch OSes while the code is in memory there's nothing you can do about it. |
|
| Back to top |
|
|
Clash
Joined: 27 Jun 2006
Posts: 182
|
| Posted: Fri Feb 22, 2008 12:14 am Post subject: |
|
|
Umm i think i've kinda been ignored here..
| Clash wrote: | Hi SKAN,
The person that decompiled the script said something about debuggers. I'm not sure on how to use your script though, do i just run it alongside my script?
Thanks, Peter |
_________________
  |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
Unless otherwise noted, all code is untested.