2012. 9. 17. 08:37

'Study > Reverse_engineering' 카테고리의 다른 글

[펌]SYBASE ASA DB log file error  (0) 2012.01.11
[분석중]삭제키  (0) 2011.12.28
[놀이]flickhomerun  (0) 2011.12.10
[ARM]자주 사용되는 ARM/THUMB OPCODE 정리  (0) 2011.09.29
[펌]IOS 안티 디버깅 기법  (0) 2011.09.28
Posted by 땡보
2012. 1. 11. 11:29

Case Description
I am receiving the following message "Assertion failed: 201129
(11.0.1.2250) File is shorter than expected". Why is this happening?
Tip or Workaround
 
Resolution
There are certain instances where Microsoft’s OS ignores certain settings (ie. Write-through flags and buffer writes) on the database file and allows buffering when we have told buffering should not take place.

What symptoms would users see in the field?

Users may see such problems as “File is shorter than expected” and issues with the checkpoint log. There is a page (checkpoint information page) at the beginning of the db containing the stores info about the checkpoint log. The Checkpoint log is located at the end of the database file.

There is an inconsistency between checkpoint information page and what was on disk.

A potential workaround was generated (see full description of fix below). Our workaround was to increase the frequency of our calls to FileFlushBuffers . In general there should be time to write to disk.

Here is a description of the fix:

Versions Affected: all Windows versions
Modules Affected: engine/server
Fixed In: 11.0.0 build 2309
9.0.2 build 3885
10.0.1 build 3956
11.0.0 build 1654
Description:
We learned that, in the interest of improved performance, Microsoft Windows explicitly prevents certain documented methods of guaranteeing that data has been written to the physical storage medium from working on IDE/SATA/ATAPI drives (SCSI drives are unaffected). Recoverability after a power outage could be compromised. The database server now performs additional operations to flush data to disk to improve recoverability. In testing, there was no measurable performance degradation by this change.

Additional URLs:
http://groups.google.com/group/microsoft.public.win32.programmer.kernel/browse_frm/thread/4590ed3a4133828f/406cfb3a9deae044
http://www.tech-archive.net/Archive/WinXP/microsoft.public.windowsxp.general/2004-04/8584.html
Other Sources Related to Issue
 Manual
  http://research.microsoft.com/apps/pubs/default.aspx?id=70554


[[['\xdf\xe8\x80\x90\xc5\xedz\xc2\xf3%q\xf0\xfc\x82/\xdaM\x8c\xd2\x81\xfcq8\xc7\xcdm\xb6V\xf6\xe2\xd0\x81']]]
 
 LINK : http://search.sybase.com/kbx/solvedcases?id_number=11562388

'Study > Reverse_engineering' 카테고리의 다른 글

[IOS]ios5+ stuff  (0) 2012.09.17
[분석중]삭제키  (0) 2011.12.28
[놀이]flickhomerun  (0) 2011.12.10
[ARM]자주 사용되는 ARM/THUMB OPCODE 정리  (0) 2011.09.29
[펌]IOS 안티 디버깅 기법  (0) 2011.09.28
Posted by 땡보
2011. 12. 28. 15:44
Uninst.exe -Dlnics27exc

요거면 만사땡

'Study > Reverse_engineering' 카테고리의 다른 글

[IOS]ios5+ stuff  (0) 2012.09.17
[펌]SYBASE ASA DB log file error  (0) 2012.01.11
[놀이]flickhomerun  (0) 2011.12.10
[ARM]자주 사용되는 ARM/THUMB OPCODE 정리  (0) 2011.09.29
[펌]IOS 안티 디버깅 기법  (0) 2011.09.28
Posted by 땡보
2011. 12. 10. 00:09
Posted by 땡보
2011. 9. 29. 17:55
ARM OPCODE
MOV R1, #0 : 00 10 A0 E3
MOVMI R1, #0 : 00 10 A0 43
MOV R1, #1 : 01 10 A0 E3
MOV R0, #0 : 00 00 A0 E3
MOV R6, #0 : 00 60 A0 E3

MOV R0, 0xFFFFFFFF : 00 00 E0 E3

B               : XX XX XX EA
BNE           : XX XX XX 1A

ADD R3, R3, #1 : 01 30 83 E2
ADD R2, R3, #1 : 01 20 83 E2
ADD R2, R2, R1 : 01 20 82 E0
ADD R1, R2, R1 : 01 10 82 E0

SUB R2, R2, #1 : 01 20 42 E2 
Posted by 땡보
2011. 9. 28. 09:07
원본은 www.iphonedevsdk.com 에 Shmoopi가 올린 것이며 이 글은 단순한 번역본에 불과합니다. 잘못된 번역 있으면 댓글로 알려주세요.

#원문링크 

2009년에 올려진 글이라 현재의 iOS에는 적용되지 않을 수도 있으므로 주의하기 바랍니다.

안녕 여러분! 이 글은 전세계에서 모아들인 iPhone/iPod Touch 크랙 방지에 대한 두 번째 튜토리얼이야. 크랙 방지에 처음 발을 들여놓은거라면 최근의 근황에 대해 약간의 정보를 알려주지. 앱스토어 크랙은 엄청나게 확산되고있어. 5백만에 달하는 유저가 크랙버전을 쓰고 있고, 개발자들은 매일매일 엄청난 돈을 잃고 있지. 어떤 회사들은 출시 다음날에 전체 유저 중 크랙버전 유저가 95%에 달한다고 보고하기도 했어.

* 이 튜토리얼은 전세계에서 모은 코드들로 이루어져있으니 각각의 코드에 대한 저작권은 그 코드를 만든 사람에게 있습니다. 또한 저는 해킹이나 크랙 방지에 대한 윤리적 접근은 가급적 피하려고 합니다. 댓글에서도 해당 내용에 대한 언급은 피해주시기 바랍니다.

좋아, 윤리적 접근은 내버려두고 한번 해보자!

첫번째니까 쉬운걸로 한번 해볼까나? 저번 시간에 SignerIdentity에 대해 체크했던건 기억나지? 그 방법은 새로 나온 해킹방법에 의해 곧 무용지물이 될테니까 이번엔 다른 영역으로 접근해보자.

Code:
#if !TARGET_IPHONE_SIMULATOR
int root = getgid();
if (root <= 10) {
	//Pirated
}
#endif
이 코드는 그닥 설명이 필요없을거야. 어플의 사용자가 iPhone Simulator인지 아닌지 검사하고, 프로세스 ID를 얻어와서 root인지 아닌지 검사하는거지. 보통 누군가가 네 어플을 크랙하려고 하면 gdb를 돌리기 위해서 자동으로 root 권한으로 실행하는 경우가 많거든. 그러니까 사용자가 root가 아니란걸 확실히 하자는거지. 이 방법의 문제점은.. 해킹을 하기 위해서 꼭 root로 실행될 필요는 없다는거야. 상당수의 크랙 어플들은 이 검사를 빠져나갈 수 있지.

다음 방법은 iPhoneDevSDK 멤버중 한명인 javaconvert가 고안한 거야

Code:
#define kInfoSize 500
//Place your NSLog Plist Size into the above Define statment
NSString* bundlePath = [[NSBundle mainBundle] bundlePath];
NSString* path = [NSString stringWithFormat:@"%@/Info.plist", bundlePath ];
NSDictionary *fileInfo = [[NSBundle mainBundle] infoDictionary];
NSFileManager *fileManager = [NSFileManager defaultManager];
NSDictionary *fileAttributes = [fileManager fileAttributesAtPath:path traverseLink:YES];

if (fileAttributes != nil) {
	NSNumber *fileSize;
	if(fileSize = [fileAttributes objectForKey:NSFileSize]){
		NSLog(@"File Size:  %qi\n", [fileSize unsignedLongLongValue]);
		//Best to see the File Size and change it accordingly first
		NSString *cSID = [[NSString alloc] initWithFormat:@"%@%@%@%@%@",@"Si",@"gne",@"rIde",@"ntity",@""];
		BOOL checkedforPir = false;
		if([fileInfo objectForKey:cSID] == nil || [fileInfo objectForKey:cSID] != nil) {
			if([fileSize unsignedLongLongValue] == kInfoSize) {
				checkedforPir = true;
			}
		}
		if(!checkedforPir){
			//Pirated
		}
		[cSID release];
	}
}
여기서 사용된 방법은 첫번째 튜토리얼의 두 가지 방법을 결합한거야. plist 사이즈를 체크하는거랑 달콤한 함정을 설치하는방법이지.

그럼 이제 새로운 방법을 알아볼까?
Code:
NSString* bundlePath = [[NSBundle mainBundle] bundlePath];
BOOL fileExists = [[NSFileManager defaultManager] fileExistsAtPath:(@"%@/_CodeSignature", bundlePath)];
if (!fileExists) {
	//Pirated
	NSLog(@"Pirated");
}
BOOL fileExists2 = [[NSFileManager defaultManager] fileExistsAtPath:(@"%@/CodeResources", bundlePath)];
if (!fileExists2) {
	//Pirated
	NSLog(@"Pirated2");
}
BOOL fileExists3 = [[NSFileManager defaultManager] fileExistsAtPath:(@"%@/ResourceRules.plist", bundlePath)];
if (!fileExists3) {
	//Pirated
	NSLog(@"Pirated3");
}
쩔지? 나도 알아 ㅋㅋ 여기서 하고있는건 "_CodeSignature", "CodeResources", 그리고 "ResourceRules.plist" 파일들이 존재하는지를 검사하는거지. 누군가가 어플을 크랙하면 크랙한 사람의 개인정보를 집어넣기 위해서 저 파일들을 제거시켜버리거든. 최고로 완벽한 방법이라고 볼 순 없지만 꽤나 크랙하기 힘들게 만들 수 있어.

다음에 나올 방법은 첨단 기술이라고 볼 수 있지
Code:
NSString* bundlePath = [[NSBundle mainBundle] bundlePath];
NSString* path = [NSString stringWithFormat:@"%@/Info.plist", bundlePath];
NSString* path2 = [NSString stringWithFormat:@"%@/AppName", bundlePath];
NSDate* infoModifiedDate = [[[NSFileManager defaultManager] fileAttributesAtPath:path traverseLink:YES] fileModificationDate];
NSDate* infoModifiedDate2 = [[[NSFileManager defaultManager] fileAttributesAtPath:path2 traverseLink:YES] fileModificationDate];
NSDate* pkgInfoModifiedDate = [[[NSFileManager defaultManager] fileAttributesAtPath:[[[NSBundle mainBundle] resourcePath] stringByAppendingPathComponent:@"PkgInfo"] traverseLink:YES] fileModificationDate];
if([infoModifiedDate timeIntervalSinceReferenceDate] > [pkgInfoModifiedDate timeIntervalSinceReferenceDate]) {	
	//Pirated
}
if([infoModifiedDate2 timeIntervalSinceReferenceDate] > [pkgInfoModifiedDate timeIntervalSinceReferenceDate]) {	
	//Pirated
}
여기서 택한 방법은 info.plist 파일 TimeStamp를 PkgInfo 파일의 실행파일의 TimeStamp와 비교하는 거야. 이 비교를 통해 어플이 만들어진 후에 어떤 파일이 수정되었는지를 알아낼 수 있어. 해커가 어플을 크랙하려고 할 때 일반적으로 메인 파일이나 Info.plist 혹은 둘 다를 건드리게 되거든. 그럼 TimeStamp가 바뀌게 되지. 그들은 보통 PkgInfo 파일은 건드리지 않아. 따라서 이 두 파일의 TimeStamp가 같은걸 확인함으로써 어떤 파일도 수정되지 않았다는 걸 검증할 수 있는 셈이지. *만약에 이 방법을 시도했는데 문제가 생긴다면 00초에 프로젝트를 빌드하도록 해봐(3:14:59 말고 3:14:00 말이야). 이렇게 하지 않으면 정상적으로 만들어진 프로젝트에서 처음 생성된 파일과 나중에 생성된 파일에 시간차가 생길 수도 있거든.

자 그럼, 사라진 파일과 TimeStamp와 함께하는건 여기까지야. 이제부턴 사후처리가 아닌 사전방지를 목표로 움직여보자구
Code:
#import 
#import 

#import 
#import 


// The iPhone SDK doesn't have , but it does have ptrace, and it
// works just fine.
typedef int (*ptrace_ptr_t)(int _request, pid_t _pid, caddr_t _addr, int _data);
#if !defined(PT_DENY_ATTACH)
#define  PT_DENY_ATTACH  31
#endif  // !defined(PT_DENY_ATTACH)


void ZNDebugIntegrity() {
	// If all assertions are enabled, we're in a legitimate debug build.
#if TARGET_IPHONE_SIMULATOR || defined(DEBUG) || (!defined(NS_BLOCK_ASSERTIONS) && !defined(NDEBUG))
	return;
#endif
	
	// Lame obfuscation of the string "ptrace".
	char* ptrace_root = "socket";
	char ptrace_name[] = {0xfd, 0x05, 0x0f, 0xf6, 0xfe, 0xf1, 0x00};
	for (size_t i = 0; i < sizeof(ptrace_name); i++) {
		ptrace_name[i] += ptrace_root[i];
	}
	
	void* handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW);
	ptrace_ptr_t ptrace_ptr = dlsym(handle, ptrace_name);
	ptrace_ptr(PT_DENY_ATTACH, 0, 0, 0);
	dlclose(handle);
}
그래, 살짝 복잡하지. 간단히 설명하자면 어플이 동작할 때에 디버거가 붙어있나를 살펴보는거야, 붙어있다면 디버거를 정지시키는거지. 어플을 크랙하기 위해선 디버거를 붙이고, 어플을 정지시키고, 메모리에서 덤프해와야하는데 이 방법으로 디버거를 떼내버리면 뱀의 머리를 치는 셈이지.

오늘의 마지막 방법이 최고의 방법이야
Code:
#import 
#import 
#import 

/* The encryption info struct and constants are missing from the iPhoneSimulator SDK, but not from the iPhoneOS or
 * Mac OS X SDKs. Since one doesn't ever ship a Simulator binary, we'll just provide the definitions here. */
#if TARGET_IPHONE_SIMULATOR && !defined(LC_ENCRYPTION_INFO)
#define LC_ENCRYPTION_INFO 0x21
struct encryption_info_command {
    uint32_t cmd;
    uint32_t cmdsize;
    uint32_t cryptoff;
    uint32_t cryptsize;
    uint32_t cryptid;
};
#endif

int main (int argc, char *argv[]);

static BOOL is_encrypted () {
    const struct mach_header *header;
    Dl_info dlinfo;
	
    /* Fetch the dlinfo for main() */
    if (dladdr(main, &dlinfo) == 0 || dlinfo.dli_fbase == NULL) {
        NSLog(@"Could not find main() symbol (very odd)");
        return NO;
    }
    header = dlinfo.dli_fbase;
	
    /* Compute the image size and search for a UUID */
    struct load_command *cmd = (struct load_command *) (header+1);
	
    for (uint32_t i = 0; cmd != NULL && i < header->ncmds; i++) {
        /* Encryption info segment */
        if (cmd->cmd == LC_ENCRYPTION_INFO) {
            struct encryption_info_command *crypt_cmd = (struct encryption_info_command *) cmd;
            /* Check if binary encryption is enabled */
            if (crypt_cmd->cryptid < 1) {
                /* Disabled, probably pirated */
                return NO;
            }
			
            /* Probably not pirated? */
            return YES;
        }
		
        cmd = (struct load_command *) ((uint8_t *) cmd + cmd->cmdsize);
    }
	
    /* Encryption info not found */
    return NO;
}
이 방법은 내가 지금까지 본 최고의 크랙 방지법 중 하나야. 실 따위는 붙어있지 않지(?) 여기서 하는 일은 실행파일을 가져와서 암호화가 되어있나 보는거야. 맥 터미널에서 "otool -l 실행파일이름" 을 해봐도 알 수 있어. 아니면 Dr.Touch의  Anti-Crack commercial을 써봐도 되고. 해커가 어플을 크랙할때 어플을 실행하려면 암호화를 벗겨내야 되는데, 이 간단한 방법으로 실행파일이 암호화되어있는지를 확인할 수 있어.

진짜 마지막으로 소개하고자 하는 이 방법은 exit을 숨기지 않는 거야.
Code:
close(0);
[[UIApplication sharedApplication] terminate];
[[UIApplication sharedApplication] terminateWithSuccess];
UIWebView *a = [UIWebView alloc];
UIWindow *b = [UIWindow alloc];
UIView *c = [UIView alloc];
UILabel *d = [UILabel alloc];
UITextField *e = [UITextField alloc];
UIImageView *f = [UIImageView alloc];
UIImage *g = [UIImage alloc];
UISwitch *h = [UISwitch alloc];
UISegmentedControl *i = [UISegmentedControl alloc];
UITabBar *j = [UITabBar alloc];
[a alloc];
[b alloc];
[c alloc];
[d alloc];
[e alloc];
[f alloc];
[g alloc];
[h alloc];
[i alloc];
[j alloc];
system("killall SpringBoard");
해커들이 어플을 크랙하려고 할 때 Hex Editor에서 두 번째로 많이 찾는 게 바로 Close(0) 일거야. Close(0)를 없애서 크랙되는걸 막기 위해서 가능한 한 많은 Close(0)를 만들어주자는거지. 어플이 왜 계속 close를 호출하는지 혼란을 줄 수 있을 뿐만 아니라 어플을 수정하는 것도 힘들게 만들 수 있어.



 


Posted by 땡보
2011. 9. 3. 19:47
흐흣 역시 휴일은 좋구나~

엠파이어워~ 를 한번 해봤숩니다.. 요샌 아이폰에서도 할만한 게임들이 많이 있네요~

일정 시간마다 증가하는 골드를 계산하는 부분을 찾아 해보았습니다.. 핵심부는... 요기..
 


네용~~

위의 부분을 적절히 인터벌없이 지속적으로 골드가 계속해서 최대량 만큼 증가하겠네요..

또한 하래의 0x19 부분을 예를들어 0xC8 정로로 수정하면 계속해서 200씩의 골드가 증가하겠죠..

뭐 하지만 이렇게 되면 게임의 재미가 반감되는건 어쩔수 없겠네요..

실력으로 클리어 하신후 한번 해보시는것도 재미겠네요~

 

Posted by 땡보
2011. 8. 15. 08:07

음.. 간만에 쉬는 날이니까.. 오늘도 하나 투척~!

같은 계열사 임에도 불구하고 신한은행, 신한카드 등 다른 어플과는 약간 다른 로직이네요..

개발 외주를 다른데 줬나 ㅡㅡㅋ

아무튼... 신한굿아이는 바로 요부분에서 검사를 해서 분기하네요~


음.. CBZ네용?

지금 조기 노랭이 부분에서 또로로록 점선화살표를 따라가면 굿아이 앱이 좔좔좔좔 잘 돌아가고,
점선을 안따라가믄 "순정이 아니네 홈버튼이 어쩌네 기타 궁시렁 궁시렁...ㅁ나어" 하면서 뒈지는데요..

그럼 요기서 잠깐 쓸데없는 ARM/thumb instruction set을 알아보죵..

CBZ 또는 CBNZ의 syntax는

CBZ [비교되어질 레지스터], 분기할 OFFSET
CBNZ [비교되어질 레지스터], 분기할 OFFSET

으로 이루어 지는데...

CBZ는
CMP [비교되어질 레지스터], #0
BEQ  분기할 OFFSET
과 같고
CBNZ는
CMP [비교되어질 레지스터], #0
BNE 분기할 OFFSET
과 같아부린거죵..

고래면..

지금 조짝에서 딱 보믄... 비교되어질 레지스터는 R5가 될끼고
R5가 0과 같으면 또로로로록 점선을 따라서 살텐데....
R5가 0이 아니면 궁서렁 구렁텅이로 빠지겠네용..

여하튼 결론은 좌우당간... 요놈에 앱을 기냥 탈옥폰에서도 팽팽 쓸라믄
0x33EC까지 진행혔을때 R5에 0이 있던가,
아니믄 0x33EC를 기냥 기냥 B라는 무식한 눔으루다가 대체를 하던가 기냥
뭐 방법이야 개성대로~

글구 엄청나게 휘황찬란하고 뽠따스틱한 ARM의 세상에 대하여 완죤하게 알고싶으신 분은 요리로..

ARM Information Center : http://infocenter.arm.com/help/index.jsp

숑숑..


Posted by 땡보
2011. 8. 13. 08:33

흠.. 오늘은 요새 오르락 내리락 하는 주식 차트를 확인하는데 자주 사용하는 앱인.. 증권통입니다.

증권통 앱이 탈옥 여부를 체크하는 핵심 로직 부분은 바로 요 부분.. 입죠..


수정포인트는 몇군데 일까요?? ㅋ

여러포인트가 될 수도 있고 한포인트가 될 수도 있겠네요.. 머 그건.. 개성대로~~

숑숑~
Posted by 땡보
2011. 8. 5. 18:57
요샌 회사가 늠흐 늠흐 바빠가가 틈이 나질 않네요.

머.. 일단 그나 저나 IDA는 쥔짜로 날로 날로 좋아지누무나...

요기가 바로 현대카드 탈옥 체크루틴 핵심부 입죠..
 


그럼...

Posted by 땡보