1P by GN⁺ 14시간전 | ★ favorite | 댓글 1개
  • 1990년대 회계용 RPG II 컴파일러가 요구하던 패러럴 포트 동글을 분석해 동작을 복원한 사례
  • 원본 소프트웨어는 Windows 98 환경의 DOS 콘솔에서 실행되며, 동글이 없으면 작동하지 않음
  • 디스크 이미지를 에뮬레이터로 옮겨 분석한 결과, RPGC.EXE와 SEU.EXE 등 실행 파일 내부에 동일한 복제 방지 루틴이 삽입되어 있음
  • 어셈블리 분석을 통해 루틴이 항상 일정한 상수값(7606h) 을 반환함을 확인하고, 4바이트 패치로 동글 검증을 우회
  • 이로써 Software West사의 RPG II 컴파일러가 동글 없이도 실행 가능해졌으며, 고전 소프트웨어 보존 측면에서 의미 있는 성과

고대 회계 소프트웨어와 동글의 발견

  • 40년간 사용된 회계용 RPG 기반 소프트웨어가 Windows 98 PC에서 여전히 운용 중이었음
    • RPG는 IBM System/3, System/32, AS/400 등 중형 컴퓨터용 언어로, 이후 MS-DOS로 이식됨
  • 해당 프로그램은 실행 시 병렬 포트에 하드웨어 복제 방지 동글을 요구
    • 동글에는 “Stamford, CT”와 “Software Security Inc.” 로고가 희미하게 남아 있었음
    • “RUNTIME”이라는 단어가 표시되어 있었으며, 이후 분석에서 의미가 드러남

디스크 이미지 분석과 RPG 컴파일러 구조

  • Windows 98 시스템의 디스크 이미지를 추출해 에뮬레이터에서 실행
    • RPG II 컴파일러(Software West Inc. 제작) 두 버전과 회계 소프트웨어의 전체 RPG 소스 코드를 발견
    • 여러 RPG 모듈과 DOS 배치 파일로 구성된 메뉴 시스템 형태
  • 컴파일러 자체가 동글 검증을 수행하며, 생성된 실행 파일에도 동일한 보호 루틴을 삽입함

병렬 포트 통신 루틴의 역공학

  • Reko 디스어셈블러를 이용해 SEU.EXE를 분석
    • 초기에는 in/out 명령이 보이지 않았으나, 다른 세그먼트(0800h)에서 발견
    • 해당 루틴은 병렬 포트 주소를 BIOS 데이터 영역에서 읽고, LPT1 포트를 통해 데이터를 송수신
    • 결과값을 BX 레지스터에 저장하며, 입력값은 없고 항상 동일한 결과를 반환

상수값 추론과 패치

  • 루틴의 마지막에서 BH 값이 76h로 고정되어 있음을 확인
    • BL 값만 미지수로 남았고, 0~255 범위를 브루트포스로 탐색
    • 올바른 조합은 BL=06h, 즉 BX=7606h로 확인
  • 루틴의 첫 4바이트를 MOV BX,7606hRETF로 교체해 동글 검증을 우회
    • 이후 프로그램은 즉시 실행되며, 동일한 루틴을 가진 다른 실행 파일에도 동일한 수정 적용 가능

결과와 의의

  • 모든 RPG II 컴파일러 구성요소에서 동일한 복제 방지 코드가 발견되어 일괄 수정 가능
  • 동글이 단순히 상수값을 반환하는 구조로, 4바이트 패치만으로 무력화 가능
  • 수정된 컴파일러는 동글 없이도 정상 작동하며, 향후 개인 정보 제거 후 역사적 소프트웨어 아카이브로 공개 예정
  • Software West Inc. 관련 자료가 온라인에 거의 남아 있지 않아, 제작자와의 추가 접촉을 희망함
Hacker News 의견들
  • 초창기 소프트웨어 보호는 정말 단순했음
    예전에 Windows 3.11 업그레이드 디스크를 가지고 있었는데, 설치 프로그램이 이전 버전이 설치되어 있지 않으면 실패했음
    해결책은 단순히 빈 텍스트 파일을 만들어 이름을 win.com으로 저장하는 것이었음. 설치 프로그램이 디스크 전체를 스캔해서 그 파일만 찾았기 때문임
    사실 업그레이드 디스크에는 전체 설치본이 포함되어 있었음. 그 시절엔 정말 단순했음

    • 어릴 때 아버지가 Windows 3.1 업그레이드 버전을 사셨는데, “3.0 이하 버전에서 업그레이드 가능”이라 되어 있었지만 실제로는 3.x만 인식했음
      결국 친구에게서 3.x 버전을 받아 설치했는데, 광고 내용과 달랐기에 도덕적으로 괜찮다고 느꼈음
      관련 제품 사진은 eBay 링크에서 볼 수 있음
  • 나는 토목공학용 소프트웨어를 개발하고 있음 (mes100.com)
    지금도 하드웨어 동글을 선호하는 사용자가 있음. 손에 잡히는 물리적 장치가 있어야 안심된다고 함
    영구 라이선스를 판매하다 보니 동글이 고장 나면 대체 부품이 없어 곤란함. 클라우드 라이선스는 싫어하지만, 구독 기반 수익을 가능하게 해줌
    하지만 아무리 노력해도 크랙 버전이 온라인에 떠돌고 있음. 법적으로 대응할 여력도 없어서 보호가 필수적임

    • 이런 동글을 선호하는 이유 중 하나는 에어갭 환경 때문임. 군사나 원자력 등 민감한 설계 데이터를 다루는 곳에서는 외부 네트워크 연결이 불가능함
      또 일부는 단순히 제3자 서버에 의존하지 않는 자율성을 좋아함
    • 규제가 느리게 변하는 산업이라 업그레이드 유인이 적다고 했는데, 그렇다면 사용자가 굳이 계속 돈을 낼 이유가 뭐냐는 의문이 있음
    • 아버지가 ‘Cosmos’라는 토목공학 프로그램을 쓸 때 이런 동글을 사용했음. 가끔 인식이 안 돼서 정말 짜증났던 기억이 있음
    • 사용자 입장에서는 “고장 나지 않았으면 굳이 바꾸지 않는다”는 태도가 합리적임
      그래서 SaaS 모델은 사용자에게는 재앙 같음. 불법 복제도 싫지만 SaaS도 마찬가지로 싫음
  • 예전에는 크랙이 훨씬 단순했음
    단순히 JE나 JNE를 JMP로 바꾸는 것만으로도 보호를 우회할 수 있었음
    핵심은 보호 코드가 어디에 있고 어떻게 작동하는지를 파악하는 것이었음

    • 이런 단순한 보호가 생기는 이유는 여러 가지임
      첫째, 개발자는 우리보다 훨씬 오래 코드를 다루기 때문에, 너무 복잡한 보호는 버그 수정을 어렵게 만듦
      둘째, 해커는 각자 몇 가지 트릭만 알아도 되지만, 개발자는 그 모든 트릭을 다 막아야 함
      셋째, 보호 기능은 재미없고 인정도 못 받는 일이라 동기부여 부족이 큼
    • 예전에 데모 소프트웨어를 디버거로 열어봤는데, 메모리 덤프에 활성화 코드 문자열이 그대로 있었음
      그걸 입력하니 바로 활성화됨. 이후엔 정식으로 구매했음
    • dBASE III의 ProLok “laser protection”을 뚫은 적이 있음
      디스켓에 레이저로 서명하는 방식이었지만, 그냥 어셈블리 읽을 줄 아는 10대 소년도 쉽게 뚫을 수 있었음
      심지어 핀으로 디스켓을 긁는 것만으로도 복제 가능했음. 결국 마케팅이 기술보다 앞섰던 사례였음
  • 80년대에 RPG II 코드를 작성했고, 90년대에는 S/36 에뮬레이션 환경으로 이전하는 일을 도왔음
    California Software Products라는 회사의 제품을 사용했는데, 꽤 잘 작동해서 회사가 창업자가 은퇴할 때까지 유지되었음

  • “이 복사 방지 방식이 너무 단순한 거 아닌가?”라는 말에, 그 시절엔 적절한 수준의 엔지니어링이었다고 생각함
    에뮬레이터와 디컴파일러 덕분에 며칠이면 해결 가능했지만, 당시엔 그런 도구조차 없었음

    • 대상 고객이 중요함. 비기술 산업의 일반 기업을 막는 용도라면 전문 리버스 엔지니어를 막을 필요가 없음
    • 디컴파일러가 보호 코드를 분석하지 못했음
      그 시절 소프트웨어의 90%는 정말 그렇게 단순했음. 복잡한 걸 놓친 게 아님
    • 2000년경 부에노스아이레스의 작은 통신사에서 비슷한 해킹 작업을 했었음. 대부분 OP가 설명한 수준의 난이도였음
    • 우리 IT 회사도 의심 파일을 비트 시프트해서 매직 넘버를 제공하는 방식으로 보호함. 복잡할 필요는 없음
  • 어릴 때 Ultima 게임을 크랙한 적이 있음
    플로피를 매번 넣기 귀찮아서였음. 코드가 스스로 복호화되고, 디스크의 특정 섹터에서 시작 주소를 읽어왔음
    그 섹터는 일반 복사 툴로는 복제 불가능했지만, 실행 파일 헤더를 수정해 문제를 해결했음

  • 90년대 초, 프랜차이즈 본사가 자체 개발한 라이선스 갱신 시스템을 유지보수했음
    매달 플로피로 갱신해야 했는데, 본사가 마음에 안 드는 지점을 임의로 차단하기도 했음
    결국 여러 지점이 모여 소송을 제기했고, 나는 DOS 기반 라이선스 생성기를 만들어 각 지점이 전화로 코드를 받아 갱신할 수 있게 했음
    소송이 끝난 뒤에는 라이선스 체크를 완전히 제거하는 패치를 배포했음. 언젠가 DOSBox로 다시 실행해보고 싶음

  • Windows 95가 아직도 현업에서 쓰인다는 글을 보니 흥미로웠음
    화려한 AI 트렌드와 달리, 산업의 지루한 영역에서는 기술 변화가 느림

    • 2014년까지도 Windows 95를 가상화해 돌리는 회사를 봤음. 오래된 의료 소프트웨어였는데, 놀라울 정도로 안정적이었음
    • 스크린샷을 보면 프로그램은 DOS용으로 보임. 아마 Windows는 단순히 파일 공유용으로만 사용된 듯함
    • Win95는 30년밖에 안 됐고, 일부 최신 하드웨어에서도 여전히 구동 가능함
      심지어 PDP-11 에뮬레이터로 돌고 있는 시스템도 아직 존재함
  • 이 소프트웨어와 하드웨어가 아직도 일부 기업에서 사용 중이라는 점이 인상적임
    그래서 크랙 버전을 공개하는 건 법적 위험이 있을 수 있음
    기업들은 오래된 시스템을 유지하기 위해서라면 큰돈을 지불하기 때문에, 이런 벤더 종속이 계속됨
    만약 특허나 지적 재산권이 아직 유효하다면, 공개 전에 반드시 확인해야 함

  • 단순히 일정한 숫자를 반환하는 하드웨어 동글이라니, 정말 단순한 보호 방식임
    하지만 당시에는 그 정도면 충분했음. 오늘날 기업용 소프트웨어도 비슷하게 라이선스 키 정도만 사용함
    결국 80년대 버전의 “청구서가 있다는 신호만 주면 돈을 낸다”는 개념이었음