3줄 요약
1. 맨 앞 숫자 0은 버전 정보
2. 나머지 문자열은 JSON 문자열을 zlib level 9로 한번 압축하고 이후 Base64로 인코딩 되어있음
3. 복호화 하는데 소스코드 4줄 들어감
이제 31시간 해놓고 과학팩3 다음부터 자동화 못해서 현자타임에 빠진 팩린이임
이것저것 꿀팁같은거 찾아보다가 청사진이라는걸 알게 되었고, 얘가 문자열로 제어된다는걸 알게됨
https://gall.dcinside.com/mgallery/board/view/?id=factorio&no=11692
가장 처음에 념글에서 봤던 태양광 청사진이었음 이거 보고 내가 지어놓은 발전소가 너무 못생겨 보이기 시작했다
암튼 거두절미하고 본론으로 들어가자면, 생각보다 깔끔한 기능임
0eNqdl02PmzAQhv8K8qlVYYU/QoBjpN4r9VhVkZO1VtYag8C7bbTiv9cQdU ...
0eNqVm+tqI0kMRt+lfztDV1XXpfMqwzA42WYwOHbwZdkQ8u7rZMhsWPRV6/...
위 두 문자열은 다른 청사진인데, 뒤에까지 다 쓰면 너무 길어서 후략 했음
공통적으로 보면 가장 앞에 0 이라는 숫자가 붙어있는데, 이는 다른 모든 청사진 문자열에 붙어있음
이런식으로 공통되게 만들어진 숫자는 같은 문자열을 암호화 했거나, 그냥 강제로 때려박은 숫자이거나 둘중 하나임
무슨 암호화 방식인지는 대충 파악했는데 글자수가 안맞기 때문에 거의 100퍼센트 강제로 때려박은 숫자라고 생각했고, 그게 맞았음
청사진 문자열의 첫 문자는 그냥 강제로 때려박은 숫자 0인데, 아마도 청사진 암호화 버전을 뜻하는거 같다
나중에 맨 앞 숫자가 1 이나 다른 숫자로 바뀌면 이 암호화 방식이 아니라 다른걸로 바뀌었다는 것 ㅇㅇ
그러면 일단 맨 앞 숫자 0의 비밀은 알았으니 걔는 떼고 생각하자
eNqdl02PmzAQhv8K8qlVYYU/QoBjpN4r9VhVkZO1VtYag8C7bbTiv9cQdU ...
eNqVm+tqI0kMRt+lfztDV1XXpfMqwzA42WYwOHbwZdkQ8u7rZMhsWPRV6/...
그 후 남아있는 애들은 암호화 되어있는 문자열인데, 대체로 /+-= 같은 특문이 많이 나오는 암호화 방식은 Base64 방식의 알고리즘임
매우 간단한 암호화 방식이라서 쉽게 decoding가능하다
솔직히 여기서 끝인줄 알았음
이것도 너무 길어서 후략한 것
대충 뭔가 더 있는걸 이때 알았음
이렇게 생긴 암호화는 본적이 없어서 내부적으로 hash key를 집어넣어서 복호화 하는 인코딩이라고 생각했는데, 실제로는 문자열 압축 이었음
zlib라는 라이브러리를 통해 문자열을 압축시켜버린건데, 쉽게 설명하면 .txt 파일을 .zip으로 압축하듯이 문자열을 압축했다고 생각하면 됨
물론 .zip파일도 압축 해제가 되듯이 문자열도 같은 방식으로 압축 해제가 가능함
실제로 해당 압축 문자열을 압축해제 해보면 나오는 문자열은 아래와 같음
위 사진처럼 드디어 읽을 수 있는 문자열이 나오게됨. 해당 문자열 포맷은 JSON 방식으로 데이터를 전달/저장하는 방식 중 하나임
이거를 보기좋게 다듬어보면
이런식으로 되어있음
아이콘은 청사진 겉면에 붙은 구조물 아이콘이 뭐가 들어가 있는지 들어있는 곳이고,
실제로 구조물들이 들어가는것은 entities라는 리스트에 오브젝트로 묶여서 구조물의 number, name, position 정보가 들어있음 ㅇㅇ
개인적으로 entitiy_number 변수는 굳이 필요한가 싶음 내부적으로 쓰이는 뭔가가 있는건가
말이야 거창하고 어려운 얘기 밖에 없지만 실제로 복호화 하는 코드를 짜보면
import부분하고 문자열 넣는 부분 빼면 4줄밖에 안됨
아무튼 결론은 청사진 문자열은 개좋은 기능이 맞고 잘만들기도 했고
해당 문자열은 복호화 하기 쉬우니 관련 유틸리티를 만들어보는것도 좋을거 같음
이참에 웹으로 청사진 생성/수정 할 수 있는거 만들어보려고 생각중
끝
해당 댓글은 삭제되었습니다.
사실 내부적으로 아이템 코드를 숫자로 따로 분류시켜놨으면 문자열 존나 짧아졌을것 ㅇㅇ - dc App
구글신은 모든 답을 알려주신다...
청사진 문자열이 길다-> 저런게 길다 로 해석하면 되는거지? - dc App
청사진이라는게 다양한 모드에도 전부 대응을 할 수 있어야 할테니 압축방식에 대한 한계가 있을수밖에 없을것같음
엔티티를 번호로 대응하지 않고 엔티티 이름으로 대응한 이유는 모드때문임
번호로 매칭시켜도 충분함 마인크래프트만 봐도 번호 매칭인데 모드 잘 넣는데 뭘
마크 지금은 모르겟는데 옛날엔 모드 여러개 깔면 아이템 코드 충돌일어나서 실행안되서 일일이 지정해줘야 하는 경우가 많았음 가령 1~1000까진 바닐라 탬들이 사용하고 모드 A가 1500~2000쓰고 모드 B가 1700~2300으로 지정해주면 1700~2000구간은 충돌일어나서 실행안됨, 나중엔 이런 현상을 방지하기 위해서 뒤에 모드 설치순서대로자동으로 게임내에서 코드를 부여해줫는데, 이러면 충돌현상은 확실히 줄어들지만, 사람들마다 부여된 코드가 조금식 다르게되서 설계도같은걸 당연하게 공유 할 수가 없음, 심지어 이 코드 리스트가 적힌 컨피그를 날려버리면 코드를 다시 부여해서 새 월드를 시작하면 문제가 없지만 기존 월드를 다시 불러오면 아이템 A가 B나 C로 바뀌는 경우도 있엇음
번호매칭은 "내부적으로 그렇게 안돌아감". 모드가 다르면 번호도 다르게 뽑히도록 설계되었기 때문. 그리고 문자열 반복성이 짙어서 zip으로 묶으면서 번호랑 크게 다른것도 없을걸? - dc App
그니까 json을 zip형식으로 압축한걸 base 64로 인코딩 하고 앞에 0을 붙인게 청사진 문자열이란 말이지? - 팩토리오 개꿀잼
Base64 인코딩보고 암호화라고 하는 사람이 있네 ㅋㅋㅋㅋㅋㅋ - dc App