프밍

Settimer

타이머 ( Settimer ) 명령은 지정한 시간으로 특정 작업을 실행하도록 설정할 수 있는 매우 유용한 기능입니다.

SetTimer를 사용하면 주어진 간격마다 특정 라벨(함수)이나 서브루틴을 자동으로 실행할 수 있습니다.

잠깐, Settimer 를 통해 다중 쓰레드를 생각하고 있다면,

오토핫키는 다중 쓰레드를 지원하지 않습니다

"쓰레드" 란.. 무엇인가요?

AutoHotkey에서 "쓰레드"는 특정 작업을 동시에 처리하기 위한 메커니즘입니다. 

 AutoHotkey는 일반적으로 멀티쓰레딩을 직접 지원하지 않기 때문에,

특정 작업을 동시에 실행하기 위해 사용되는 주요 방법은 "타이머"나 "별도의 스크립트"입니다.

https://autohotkeykr.sourceforge.net/docs/misc/Threads.htm

오토핫키는 아쉽게도... 멀티 쓰레드를 흉내만 낼수 있고

직접적인 멀티 쓰레드를 지원하지 않습다

공식 HELP 파일을 보면 settimer의 기본 문법입니다.

SetTimer [, Label, Period|On|Off|Delete, Priority]

Label

핫키의 이름이나, 서브루틴의 이름이 될 수 있습니다. 

모든 다른 명령어의 매개변수처럼 라벨은 변수의 참조가 될 수 있습니다.

On

이전 기간(period) 동안 비활성화되어 있던 타이머를 재활성화합니다. 타이머가 존재하지 않으면, 새로 만듭니다

Delete

기존의 타이머를 끄고 삭제합니다. 타이머가 함수 객체와 연관이 있다면, 객체는 해제됩니다.

Period

해당 매개변수는, 밀리 초의 개수로 사용하며, 타이머를 갱신하거나, 생성합니다. 
시간은 마지막의 라벨 서브루틴이 시작한 이후로 경과하는 시간입니다.  이 시간이 지나면 다시 시간초를 갱신하여 

라벨을 실행할 준비를 합니다. 

예시

#Persistent
#SingleInstance,Force
settimer,null_a,3000

return

null_a:
msgbox,3초마다 실행됩니다
return

셋타이머 한번 실행후, 중지

SetTimer, ShowMessage, 2000

ShowMessage:
    MsgBox, 타이머가 호출되었습니다!
    SetTimer, ShowMessage, Off
return

Esc::ExitApp

2개의 settimer 를 사용할 경우

; 첫 번째 타이머 설정: 3000ms(3초)마다 `FirstTimer` 레이블을 호출
SetTimer, FirstTimer, 3000

; 두 번째 타이머 설정: 5000ms(5초)마다 `SecondTimer` 레이블을 호출
SetTimer, SecondTimer, 5000

; 첫 번째 타이머가 호출될 때 실행되는 레이블
FirstTimer:
    MsgBox, 첫 번째 타이머가 3초마다 호출됩니다!
return

; 두 번째 타이머가 호출될 때 실행되는 레이블
SecondTimer:
    MsgBox, 두 번째 타이머가 5초마다 호출됩니다!
return

; 스크립트 종료를 방지하기 위한 기본 핫키
Esc::ExitApp

따사로운 숲 속 자연의 소리와 소근소근 속삭이는 새 소리 입니다.

자연 숲속 바람의 소리입니다. 

잔잔한 소리 입니다.

스크립트 언어 즉 비주류 스크립트 언어인 오토핫키가 직면하고 있는 최대의 단점인 부분이기도 합니다.
스크립트 파일을 컴파일을하고 좀비 PC나, 기타 멀웨어 파일을 합쳐서 배포하지 않는 이상....

여러 백신 회사의 프로그램들에게 바이러스 오진 (양성반응) 을 보이곤합니다

어찌보면 당연한 이야기일 수 도 있습니다

많은 사람들이 오토핫키를 접하는 것의 대부분이 게임 매크로 많이들 접했을 것이라고 생각합니다

이에 매크로 사용자들은 금전적인 이득을 취하고 다른 유저들을 방해하고 다양한 업체에서 오토핫키라는 구조를

백신회사에 보고하게 되면서, 오토핫키라는 파일이 컴파일을 진행했을시, 윈도우 디펜더 ( Window defender ) 에 걸리거나

백신 프로그램에 걸리는 경우가 많습니다. 

특히, 오토핫키 소스 개발자가 스크립트를 보호하기 위해 VM Protect 와 같은 패킹 프로그램을 사용하게되면 이 역시

마이크로소프트 윈도우 디펜더에게 걸리게 됩니다. 

https://www.autohotkey.com/boards/viewtopic.php?f=17&t=62266

< 안티 바이러스 백신 회사의 거짓 보고서 관련 해외 커뮤니티 포럼 자료 >

이 문제는, 해외 오토핫키 커뮤니티 포럼에서도 많이 다루고 있는, 그리고 지금도 다뤄지고 있는 문제입니다.

어찌보면 당연한 결과라고 생각이 들긴합니다. 오토핫키라는 스크립트 언어가 접근하기도 쉽고

진입장벽도 낮고 어린아이들도 조금만 배우면 만들 수 있는 스크립트 언어 이니까요

이 말은 즉, 악용을 하는 방법이 더 많다는 것이겠지요  

백신 혹은 마이크로소프트의 윈도우 디펜더의 오인 감지로 인해
컴파일을 배포하는 제작자가 피해를 볼 수있는 것이 무엇일까요?

1. 분석이나 검증을 위한 자료를 백신회사에게 뿌려야하고, 만약 검증과 분석이 없다면, 온라인 서명을 구매해야합니다.
2. 구매자 혹은 사용자들은 백신에 바이러스가 뜨는 것만으로 제작자에 대한 불신과 신뢰를 깎일 수 있다.

3. 잘못된 식별로 인해, 오토핫키 스크립트 언어를 사용하는 모든 업체와 제작자에게 해를 끼치는 하나의 형태로 변형된다.

어쩔 수 없습니다.하하 절이 싫으면 중이 떠나는 법이라고, 저는 지금까지 괜찮았으나, 하드한 작업을 진행하고, 다른 사용자들에게 배포할때 여간 귀찮은게 아니더군요.. 그래서 요즘 고민하고 있습니다.

다른 언어로 갈아 타야할까 ㅎㅎ 이런생각요

이를 해결하기 위한 방법은 간단 ( ? ) 합니다.

마이크로소프트 윈도우 디펜더

https://peuming.tistory.com/25

예외설정을 해주면됩니다. 간단합니다.

AhnLab V3 Lite 

예외설정을 해주면됩니다. 간단합니다.

예외설정이 없는 백신 프로그램은

그냥 제거해주시면됩니다.

스크립트를 보호하기위해 VM 패킹을 한다지만,

패킹을 하면 바이러스 오진이 뜰 가능성이 높고,

바이러스 오진을 해결하기 위해 인증서를 외부에서 구매해야하고..

( 만든 프로그램의 검증과 분석요청이 빡셉니다.)

만약 패킹을 하지않았을 경우 스크립트파일이 바로 뜯기니..

참 아이러니하네요

오토핫키가 간단하고 접근하기 쉬운 스크립트 언어이긴하나,

그만큼 오픈소스인 만큼,... 뜯기가 쉽습니다.

패킹을해도 디버깅 고수들은 그냥 뚫지요 하하