오늘이 마지막날 이라서 어쩔수 없이 KT와 쇼부를 치기 위해 전화를 했다.
최대한 굽신굽신 모드. OTL
일단 KT에서 요구 하는 사항은 서비스 번호
그리고 내가 물어 보는 것들은
1. 우리가 사용중인 단말이 몇대냐?
2. 사용중인 단말의 기준은 무엇이냐? 인터넷 사용이냐?
3. 그 단말은 어떻게 검출해 내냐?
였는데.. 그쪽 상담원의 말을 빌리자면
"MAC 어드레스 라는 것이 있어서 그것을 통해서 사용중인 단말을 검사합니다. 그리고 사용중인 단말기는 인터넷을 사용하는 것을 기준으로 산정됩니다"
라고는 하는데.. 솔찍히 MAC 어드레스로 어떻게 검출을 하는지 넌저시 물어 봤더니 딴소리 ㄱ-
어떠한 방법을 사용하여 검출을 하던, 결국에는 패킷 변조가 동원되는게 아닐까 생각이 되는데..
머 기업비밀이니 패킷을 변조하거나 위조하면 불법이라는 건 기업에게는 안통하는건가?
한가지 희한한 점은.. FireFox나 Chrome 으로 할 때는 인증 수 제한조치 관련 팝업이나 redirection이 통하지 않는다는 것이다.
웬지.. 이 부분이 상당히 찜찜하다...
다르게 말하자면 IE를 사용하지 않고 다른 브라우저로 사용하면 검출이 안될 가능성도 있고,
혹은 IE에 특화된 어떠한 backdoor code를 이용하여 불법하게 검출을 해낸다는 이야기가 아닐려나?
An object
is a data structure that represents a system resource, such as a file,
thread, or graphic image. An application cannot directly access object
data or the system resource that an object represents. Instead, an
application must obtain an object handle, which it can use to examine or modify the system resource.
typedef struct tagBITMAPFILEHEADER
{
WORD bfType;
DWORD bfSize;
WORD bfReserved1;
WORD bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER, *PBITMAPFILEHEADER;
WORD bfType; // 위의 첫 바이트 BM 으로 Bitmap 이라는 의미를 지닌 헤더
DWORD bfSize; // 0x00075736 = 481078 bytes, 파일 전체 크기(헤더 포함한 전체 파일)
WORD bfReserved1; // 0x0000 으로 사용하지 않는 부분
WORD bfReserved2; // 0x0000 으로 사용하지 않는 부분
DWORD bfOffBits; // 현재 위치로부터 실제 데이터가 존재하는 곳 까지의 거리
bfOffBits는 약간의 설명이 필요하다. 일단 256색상 이하의 비트맵은 indexed color 방식으로
팔레트를 이용하게 된다. 팔레트 이후에는 1pixel = 1byte로 연결된 인덱스들이 나열되어 있다.
그런 이유로, 팔레트에 저장된 색상의 갯수가 다르거나, 팔레트를 사용하지 않는다면 이 값은 상당히 다른 값을 보이게 된다.
자세한 내용은 아래의 팔레트를 참고하면 된다.
typedef struct tagBITMAPINFO
{
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[1];
} BITMAPINFO, *PBITMAPINFO;
256 색 이하의 이미지라면, RGBQUAD는 팔레트로 사용되고,
16bit 이상의 이미지라면 이 내용에 바로 pixel별 색상이 들어간다.
typedef struct tagBITMAPINFOHEADER
{
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER, *PBITMAPINFOHEADER;
DWORD biSize; // BITMAPINFO 헤더의 크기
LONG biWidth; // 이미지의 넓이(화면상에 보이는 크기)
LONG biHeight; // 이미지의 높이(화면상에 보이는 크기)
WORD biPlanes; // 이미지의 장수(bitmap은 layer가 존재하지 않으므로 항상 1)
WORD biBitCount; // 한 픽셀의 컬러 비트수(256컬러는 2^8 이므로 8이 표기됨)
DWORD biCompression; // 비트맵이 압축이 되었는지 어떠한 방식으로 압축이 되었는지 표시
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
BYTE rgbBlue; // RGB 중 파랑(Blue)에 대한 값
BYTE rgbGreen; // RGB 중 녹색(Green)에 대한 값
BYTE rgbRed; // RGB 중 빨강(Red)에 대한 값
BYTE rgbReserved; // 사용하지 않음
---------------------------------------------------------------------------------------------------
1.
bitmap은 단순하게, 하나의 pixel에 대한 RGB 정보나 index 정보를 이용하여 이미지를 표시한다. pixel은 Picture Element의 약자이며, 우리가 말하는 점 하나를 의미한다.
2. 비트맵은 4사분면을 기준 좌표로 사용하며,
좌상단이 (0.0)이다. 하지만 pc에서는 1사분면을 기준 좌표로 사용하므로 우하단이 (0,0)이다.
그런 이유로, 좌표대로 출력을 하면 비트맵은 상하가 뒤집힌 채로 나오게 된다.
(다르게 말하면, 저장시에 데이터는 상하가 뒤집힌 채로 저장되어 있다)
3.
비트맵은 특정 크기의 데이터를 한번에 전송하기 위해 DMA(Direct Memory Access)나 BLIT(Bit-Block Transfer)를
사용한다. 그런 이유로 특정 블럭을 맞추어 주어야 하고, 그렇기 때문에 이미지는 byte align이나 DWORD align을
사용하게 된다(DWORD = 4bytes = 64bit) 이 방법은 몇 비트 이미지냐에 따라 달라지게 되는데,
기본적으로는 4byte align을 맞춰준다.
예를들어 256색 이미지라면, 각각은 1byte로 표시되며, 이미지가 309 x 200 이라고 한다면, 309은 4의 배수가 아니므로
4의 배수가 되어 포함할 수 있는 312 의 width를 사용해야 하고 남는 3pixel은 padding으로 무시하거나 0값을 갖는다.
그리고 24bit의 경우 RGBQUAD가 아닌 RGBTRIPLE을 이용함으로, 309pixel의 width를 지닐경우
927byte를 사용하게 되고, 927을 포함하는 가장 작은 4의 배수는 928 이므로, 1바이트의 padding을 가지게 된다.
4. 256색 미만의 비트맵은 팔레트라는 것을 사용한다. (팔레트는 RGBQUAD 구조체 사용)
이러한 팔레트는 8bit로 표현이 가능하므로, 256가지의 색상을 팔레트로 주로 사용가능하다.
예를 들어
이러한 팔레트를 만들고, 번호만으로 각 픽셀별로 색상을 지정해준다. 그렇다면 상당한 저장 공간을 아낄 수 있다.
그런 이유로, 팔레트를 사용하는 경우에는 팔레트를 Lookup(참조) 하여 변환을 해야하는 작업이 추가되게 된다.
300x200 크기의 이미지를 저장한다고 할 때, 팔레트를 사용하지 않고 RGBQUAD를 이용한다면
sizeof(RGBQUAD) = 4 이고, 이로 인해 60,000개의 픽셀을 각각 4바이트가 필요하게된다.
60,000 * 4 = 240,000 대략 240KB의 용량을 필요로 하게 된다.
하지만 팔레트를 이용하여 256새가지의 색상만을 사용하는 비트맵이라면
256 * 4 = 1024의 용량과 300 * 200 * 1의 용량을 계산하면
60,000 + 1024 = 61,024 대략 62KB의 용량을 필요로 하게 된다.
이러한 이유로 색상수가 적을 경우에는 팔레트를 사용하게 된다.
grayscale의 경우에는 256color RGBQUAD 구조체
팔레트가 없을 경우(jpeg 변환등) for(i=0;i<256;i++) ; 을 이용하여 생성하면 된다.
5.
이유는 모르겠지만, 24bit 비트맵의 경우는 RGBQUAD가 아닌 RGBTRIPLE이라는 구조를 사용한다.
where
adapter Connection name
(wildcard characters * and ? allowed, see examples)
Options:
/? Display this help message
/all Display full configuration information.
/release Release the IP address for the specified adapter.
/renew Renew the IP address for the specified adapter.
/flushdns Purges the DNS Resolver cache.
/registerdns Refreshes all DHCP leases and re-registers DNS names
/displaydns Display the contents of the DNS Resolver Cache.
/showclassid Displays all the dhcp class IDs allowed for adapter.
/setclassid Modifies the dhcp class id.
다른 사람 pc에서 뜬걸 캡쳐 하고, 내 자리에서는 잘 안뜨길래 일단 캡쳐만 해봤다.
날짜까지 명시하고는 상당히 협박성으로 적어 놓는다.
그런데.. 1280x1024 사이즈에 맞춰서 디자인한건 의도한 걸까? 엿 먹으란걸까?
그리고, 첫 기본 페이지가 daum.net 이었는데, 별다른 것 없이 바로 팝업으로 별도로 뜨는 것 봐서는
패킷 변조가 아닐까 생각이 되는데..
자기네 페이지에 남의 페이지로 무단으로 redirection 하거나 embed 하는 건 불법이 아닌가?
적고나서 테스트로 다른 페이지를 하니 드디어 떠서 소스 캡쳐!
이것은 congnamul.com 접속시에 뜬 불법(?!) 하게 리다이렉션 시켜주는 소스
Having a low ID does not mean that no upload or download is possible but has several disadvantages:
1) No IP is known of the machine eMule is running on therefore all requests like queue or connection requests to this client have to be routed over the server, the low ID
client is connected to. This routing causes considerable amount of CPU
load on the server thus reducing the maximum number of users the server
can cope with. Lugdunum’s servers limit the number low ID users or even ban them at all.
2) Two clients on low ID cannot connect to each other, as it is not possible to route messages over two different servers. This will lead to less sources for the downloads.
3) On busy servers it may well happen that the messages get lost and eMule misses important information about queue progression or download requests. This may lead to fewer credits and worse downloads.
bitmap_dump_beta_3.zip
