Me and some friends have been trying for month's to crack the lineage mmorpg's blowfish code, and as far as i know (in the game's 5 years+) noone have ever successfully cracked it (and ALOT have tryed to do it).

For anyone interrestet to look at it, ill post some of the info i got now..

first i did a check on the file using a program called KANAL, it showed it was using:

Blowfish (Check 2), whatever check 2 means.
and
CRC32 (prolly just for file check)

Here are some packet stuff (key auth) happens when you connect to the server (3 packets are transfered)

peer 1_x = server -> client
peer 0_x = client -> server

char peer1_0[] = {
0x0a, 0x00, 0x29, 0xe5, 0x4c, 0x66, 0x79, 0xa8,
0x00, 0x4e
};
char peer0_0[] = {
0x0e, 0x00, 0xcb, 0x45, 0x03, 0xa9, 0x8f, 0x9b,
0x01, 0x20, 0x8c, 0x3b, 0xa8, 0x82
};
char peer1_1[] = {
0x22, 0x00, 0x60, 0xfe, 0x9b, 0x13, 0xac, 0xb8,
0x22, 0x12, 0x3b, 0x11, 0xf6, 0x22, 0x9e, 0x8a,
0x10, 0x45, 0x6c, 0x46, 0xa1, 0xb4, 0x9c, 0x35,
0xef, 0xce, 0xfa, 0xd1, 0x0b, 0x50, 0x95, 0x70,
0xa9, 0x2e
};

firsly some packet info on those 3.

first [xx xx] of every packet = size of packet
rest is data & opcodes and so on.

the 1_0 packet is always code [0x0a 0x00] [0x29] (where 0x29 is opcode)
rest of the data you see is always random numbers and stuff.

we belive server sends a key to client, and client returns a new key encryptet with the key server sends, and then at last packet server receive a key from client wich is the key to use.

(also note, these packets are always same size).

i can post a few here (else go download lineage from www.lineage.com)

packet 1
char peer1_0[] = {
0x0a, 0x00, 0x29, 0xe5, 0x4c, 0x66, 0x79, 0xa8,
0x00, 0x4e
};
char peer0_0[] = {
0x0e, 0x00, 0xcb, 0x45, 0x03, 0xa9, 0x8f, 0x9b,
0x01, 0x20, 0x8c, 0x3b, 0xa8, 0x82
};
char peer1_1[] = {
0x22, 0x00, 0x60, 0xfe, 0x9b, 0x13, 0xac, 0xb8,
0x22, 0x12, 0x3b, 0x11, 0xf6, 0x22, 0x9e, 0x8a,
0x10, 0x45, 0x6c, 0x46, 0xa1, 0xb4, 0x9c, 0x35,
0xef, 0xce, 0xfa, 0xd1, 0x0b, 0x50, 0x95, 0x70,
0xa9, 0x2e
};

packet 2
char peer1_0[] = {
0x0a, 0x00, 0x29, 0x0b, 0x95, 0x58, 0x0b, 0xbf,
0x00, 0x12
};
char peer0_0[] = {
0x0e, 0x00, 0x4e, 0xa7, 0x70, 0x01, 0xa2, 0x27,
0xce, 0x20, 0x7a, 0x5c, 0xbc, 0x59
};
char peer1_1[] = {
0x22, 0x00, 0xe5, 0x1c, 0xe8, 0xbb, 0x81, 0x04,
0xed, 0x12, 0xcd, 0x76, 0xe2, 0xf9, 0xb3, 0x36,
0xdf, 0x45, 0x9a, 0x21, 0xb5, 0x6f, 0xb1, 0x89,
0x20, 0xce, 0x0c, 0xb6, 0x1f, 0x17, 0x24, 0x79,
0xe2, 0xce
};

packet 3
char peer1_0[] = {
0x0a, 0x00, 0x29, 0xb3, 0x75, 0xbd, 0x4c, 0xa2,
0x00, 0x06
};
char peer0_0[] = {
0x0e, 0x00, 0xa3, 0x5a, 0xb2, 0x14, 0x5a, 0xe0,
0xcb, 0x20, 0x55, 0x4c, 0x6e, 0x8e
};
char peer1_1[] = {
0x22, 0x00, 0x08, 0xe1, 0x2a, 0xae, 0x79, 0xc3,
0xe8, 0x12, 0xe2, 0x66, 0x30, 0x2e, 0x4b, 0xf1,
0xda, 0x45, 0xb5, 0x31, 0x67, 0xb8, 0x49, 0x4e,
0x25, 0xce, 0x23, 0xa6, 0xcd, 0x8d, 0x91, 0x0c,
0x7b, 0x54
};

packet 4
char peer1_0[] = {
0x0a, 0x00, 0x29, 0x75, 0xa8, 0x61, 0x25, 0xf1,
0xd8, 0xf6
};
char peer0_0[] = {
0x0e, 0x00, 0x76, 0x27, 0x81, 0x52, 0xc9, 0x3d,
0x25, 0x20, 0xb3, 0xe4, 0xf5, 0xfb
};
char peer1_1[] = {
0x22, 0x00, 0xdd, 0x9c, 0x19, 0xe8, 0xea, 0x1e,
0x06, 0x12, 0x04, 0xce, 0xab, 0x5b, 0xd8, 0x2c,
0x34, 0x45, 0x53, 0x99, 0xfc, 0xcd, 0xda, 0x93,
0xcb, 0xce, 0xc5, 0x0e, 0x56, 0xf8, 0x02, 0xc1,
0xe4, 0xe1
};

I tryed checking the lin.bin file in IDA but im getting sooo lost all the time.

anyways, if anyone wanna have a go or can provide more info, all info is welcome

Thanks.

When you say "crack" the blowfish code, what exactly are you trying to accomplish? Do you want to write a bot for lineage? What is the crypto preventing you from doing?

well first of all, im not doing this to cheat in the game, im trying to figure out, is NCI (the game dev's) as good as people say, for years people have kept saying that it is impossible to crack there encryptions (packets).

NCI is one of the largest company's for mmorpg's, and im trying to see, if people work together, can they beat them.

i might be interrestet in making something for it later (a server emulator) but thats not in the "idea" yet, people are still playing the game on the real servers (altho the server population is getting lower and lower) duo to the fact that it:

Lineage 2 came out and replaces it
cost 15$ a month (same as lineage 2, but 2 is much larger)
Lineage 1 got a very outdatet gfx engine.

when i startet many years ago there was 1000+ ppl online all the time, now its down to 90-160 (160 on a GOOD day) online.

I dont wanna see this game die away, and then sit and have nothing to do, i like this game..

I program visual c++ (winsock mostly) and have the "skills" to make a emulator once needed.

I tryed yesterday again to memory hook it, to see where it does it's winsock call's but that got confusing, i know where it does its sends, but still not where it does its encryption.

The encryption prevents me from seeing the packets, the opcodes, whats wierd is even the ingame messages (eg. chat) is also encryptet.

hope this answers some of your questions, else just let me know

OK, so it's preventing you from reverse-engineering the protocol. My bet is that they construct the packet and then encrypt the whole thing. Finding the encryption code should be straightforward, since you know what it looks like. You can also look for references to the blowfish tables to greatly reduce the amount of code you're looking at.

Set a breakpoint on the call to the encryption function; I bet the buffer that's being encrypted will be the packet you want to dump.

im not 100% what u mean by reference to the blowfish tables
i been reading this one

http://babel.altavista.com/babelfish/trurl_pagecontent?url=http%3A%2F%2Fquequero.org%2Fuic%2FBlowFish.htm&lp=it_en

i cant locate the blowfish reference tho.

has some info on blowfish, but my problem is i cannot execute the file in debug mode to set breakpoints because its memory protectet, game crashes at once when i try to do anything but run it normally (in a read/write memory error).

ill continue to looking at it tho.

OK, this isn't helpful. You are the one who is interested in reverse-engineering this particular target; no one else will do it for you. What we can offer here is techniques, approaches to the problem, tools, etc.
You need to become familiar with the algorithm that does the encryption in order to recognize the code that implements the algorithm. Blowfish was created by Bruce Schneier. You can find a description here

http://www.schneier.com/paper-blowfish-fse.html

The tables to look for are the S and P tables. They start out with known values that are changed during the key setup step. You will find large tables of random-looking constants in the program.

A more pressing problem is the anti-debug code. What do you mean, run it in debug mode? What debugger are you using? If you're using SoftIce and you're running into problems with the target detecting it, you can try some of the other forums for help with bypassing that. It will be almost impossible to reverse-engineer the protocol if you can't set breakpoints.

Good luck!

thanks for the url, and yes i know noone will do it for me, and i AM trying my best, i guess those dumps where useless since they got deletet (sorry for that, just thought i had something there).

And yeah, im very happy that you guys will give me some idea's tips'n'trix

about the debug mode stuff, i used IDA to do it (run program in debugging mode), but im getting softice and ill try again.

in IDA the program crashed at startup, because there is a memory protection thing in the exe, it can detect if something is hooking itself to the client (im not 100% sure but i think its the nprotect thing) to prevent keyloggers and so on..

but ill take a look at what you postet first and have a go with softice and return back to report whatever progress im making.

okay after checking some more i found out the file uses actually 3 encryptions

1) CRC32 (file check only i belive to check if someone tampered with files)
2) Blowfish (only for username / password i think)
3) DES (most likely Triple-DES)

so i think ill go read up on Triple DES & DES first.

Actually, in this situation you probably shouldn't need to know much more about these three algorithms than the following:

CRC32 is a 32-bit hash/checksum, which is a weak enough algorithm (non-cryptographical) to make it completely and fully breakable without any effort at all, if needed.

Blowfish is a symmetrical block cipher, which you should not consider trying to break per se, you will fail.

DES/3DES are also symmetrical block ciphers that for all practical purposes should be considered non-breakable per se.


Knowing this, you should instead concentrate on analyzing the use of these technologies in the application, i.e. the design of the application security model, for which you only need to consider these algorithms above as black boxes, labeled with what I said above. Then you should find weak spots in this general design instead, and exploit these.

thanks delta, problem is the people who made this mmorpg have millions and millions, so i dun think ill find a weak spot easily.

i read DES uses 7 byte key, the first packet i receive (key i guess) is 7 byte data

eg:

[xx xx] size
[xx] opcode
[xx xx xx xx xx xx xx] 7 bytes data.

i tryed IDing the exe file with PeID it said it was:

Microsoft Visual C++ 6.0 [Debug] (this might be a weak spot though if its released in debug mode)

i just wish i knew alot about this stuff, so maybe you are right about i have to find a weak spot and "exploid" it.

but first ill try find out how to remove the damn memory protection (anti debug) stuff in the file.

and besides, if i cant get the encryption/decryption rutine then i cannot make a emu for it at any time if thats what i wish to play around with right?.

Just like with packed programs, it is theoretically impossible to prevent someone that has a working client in his possession from decrypting all communications from the server and modifying the client's responses in a situation like this (no matter how many millions of dollars the developers have access to). Hence, there is no need to find a real "flaw" in the design of the protocol, but rather simply to reverse it and see which points are the natural ones to intercept. Hence, the crypto algorithms used are quite irrelevant, and the great work lies in reversing the program and its design (which will have good interception points in them).

All I mean is that if I were you I'd put the effort into improving my general reversing skills rather than studying some crypto algorithms, you won't be "breaking", or even modifying, any crypto algorithms at all anyway if you do it the right way.

Yep. Server sends encrypted data, client has to decrypt it to show you where everyone else is in the game. So when it's decrypted, you just need to know where to look.

Also, client has to assemble the plaintext before encrypting it to send to the server. Again, you just need to know where to look to find the plaintext.

The kind of encryption is irrelevant, as dELTA said, except to help you find the code that does the encryption. The buffer coming into an encrypt routine is plaintext, and the buffer coming out of a decrypt routine is plaintext. That's where you want to look.

oooh okay, thanks to both of you, that kinda makes sence now.

was getting a headacke trying to figure out the damn encryptions, i wont waste more time on that then, ill rather try locating the buffer, sounds alot easier.

i might be a slow learner, but i wanna learn, so this info helps alot.

Thanks again, ill come back and let ya all know my progress (if any ).

okay i think i found the buffer location, so whats the next step ?

is there a way to "monitor" whats comming in/out of that location ? (i mean data)

note: im using IDA pro right now and Api Monitor 1.5, do i need any other programs ?

(i dont know how to use softice so i hope i wont need that one).

Thanks again

edit: i think this is the buffer because

in trace, all the "text" data goes -> what i think is buffer then -> jumps to encryption rutine area (i think thats it anyways, makes most sence) then -> send ().

I would create a loader that uses the debugging API to place breakpoints just before encryption and after decryption, and then read out the buffers at these points every time they hit. That way, it would be very easy to retrieve/display/store entire communication sessions in unencrypted format, for later analysis or whatever it is you want to do with them.

If you are really lucky and the encryption/decryption routines are located/exported by a dll, you could instead get away with making a proxy dll, for the same kind of interception functionality.

thanks i guess ill have to have a go at that then..

sounds like thats how the bot for the game works (gamenameProxy) it got a exe file and a dll file, and i checked the dll and it uses api hooks.

problem is i never wrote a api hook before, let alone one that can intercept breakpoints.

well guess its time to learn, have to find some info/excamples for that (for visual c++ 6 tho).

Thanks again, ill report back later.

okay i studied some different codes on making a hook.dll and a loader, so far so good, i can run the game, but it doesnt load the dll i injectet into the exe file.

(i know it injectet the dll code because in api spy i can see it does a WriteToProccessMemory)

i cant seem to find any good places to read about injecting a dll into a exe AND locating where to call the load dll string from the exe.

im pretty sure it injects okay, it just dont "execute" aka read the dll file when i start the game.

i found out it need to be near LoadLibraryA, but not how and where to put it.

also while at it, i coudnt find any place to read about my specific problem wich is:

after loader inject the dll, and game loads the dll, how do i monitor the "breakpoint" and how do i set that breakpoint ?

i mean, lets say i want it to break at

0x0049001 buffer
0x0049002 after buffer - break here right ? then read the buffer and continue.
0x0049003 encrypt

my hook is just set with some excamples right now about logging winsock recv() & send() from a exe file, so i know it doesnt load the dll.

sorry but im not good at this reverse engineering thing, and i never did a dll hook like this before, i understand whats it "supposed" to do, but not excatly how.

hope someone can help.

thanks

You cannot create real "breakpoints" by just using an injected dll, you'll have to use a loader with the debugger API for that.

But you can create a hook from an injected dll anyway, let's say your code looks like this, as you say:

0x0049001 buffer
0x0049002 some other instruction 1
0x0049003 some other instruction 2
...
0x0049008 some other instruction N
0x0049009 encrypt


Then you could e.g. patch like this:

0x0049001 buffer
0x0049002 jmp your_hook_proc_in_the_injected_dll
0x0049003 some other instruction 2
...
0x0049008 some other instruction N
0x0049009 encrypt

And your hook procedure in the dll would look something like this:

your_hook_proc_in_the_injected_dll:
0x0099001 <preserve registers>
0x0099002 <do whatever you like>
0x0099003 <restore registers (and stack of course)>
0x0099004 <execute the original instruction you overwrote, i.e. "some other instruction 1">
0x0099005 jmp 0x0049003


Exactly what are you currently using WriteProccessMemory for btw?

thanks that helps alot

mmm i dun know about the writeprocessmemory, api spy just told me my loader did that.

what im doing is:

start loader.exe
hit start button.
it injects the dll call and the dll code (after checked memory is availible and so on).
resumes the game.

anyways, its not completet yet, ill continue to work on it.

thanks for the "process" of injectet / loading

Hmm, something tells me you didn't create that loader yourself...

ofcourse i didnt , i studied some excamples and used some code here and there, and trying to figure out how it works...

i can make applications like well... server software, winsock stuff and so forth in VISUAL c++ (win32 api or MFC for that sake)

...... but not in asm...

asm looks like gibbish to me, i know hex adresses and offsets and so, but as i said before, i NEVER before made a hook, so i have not much of a choice but to study others hooks and see what does what where and when..

putting all them push and pop and asm pointers and who knows what doesnt make much sence to me, making the program is easy, making the "inject" code is hard for me...

if i knew much about this, i prolly woudnt be here asking would i

im still trying to shake some of the hook code out of some of the bot creaters (to attach a logging2file .cpp/.h thing wrote) but they aint really coorparative... and i doubt that will change..

so basicly im having to do "double" work because they aint gonna help me...

its frustrating but o well...

will continue to ask questions here (aslong as i am permittet / you get tired of me)

thanks to all for the help though, its okay if you guys give up on me, but i AINT giving up on this tho...

i waitet almost 4 years for someone to do what im doing, noone ever did, so i guess, if you do nothing, you get nothing... so .... here i am

i have no plans on giving up, not now, not ever (i think ever might be a big word but..)its possible and i wanna do it sooo badly...

the loader DOES work, it does load the & run the exe, and it does resume the thread, and it does try to inject the dll loader codes... but it aint working

i think i know the error tho, and thats the ASM stuff for the inject/loader and the inject addresses... and thats ASM!

Sure, just keep on struggling, you'll get it right in the end. As long as you put in your own effort and make the most out of the replies that people offer, you are always welcome with your questions here.

I didn't read any of this thread... but couldn't you just intercept the packets before the get encrypted?

I didn't read your post, but my guess is that the answer would be somewhere between 42 and Thursday...

hum my plaintext thing aint working, i just dont think i get the general idea...

HOWEVER, i do know HOW it encrypts now, username/pw & ingame packets.

1) username / pw is blowfish, the key is part of the packet you receive at init.
2) the DES key (i found this key so thats done, its 8 bytes) is used for what i belive, is filesystem OR to decrypt the blowfish key from server (first packet)
3) the ingame packets are decryptet via some xor of the username you use to login.

i tryed different ways to find out what and how to "unxor" the ingame packets, but never got plaintext out of it.

for this im using a server wich sends fake encryption packets (blowfish key) and fake responce i recorded from real servers, it will accept any username and password and log me into the map.

in game i type different things on the chatboard and can see i get the same output (packetlog) every time if i use same username, else it will change.

(i testet if it uses password aswell, but it doesnt, only username)

so is a plaintext buffer REALLY nessesary ?? since i cannot make one, i just dont know asm good enough for that....

so i know:

DES key 8 bytes (i got the key, not 100% sure what used for yet, it get init BEFORE packets gets transfered)
Blowfish key, pattern = GetKeyPacket, GenerateKey, and then some more transfers.
Ingame packets = Xor with login username as key

sorry for double post, it was getting long and i wantet to make sure you all understand this

i was thinking this is the encryption "rutine"

init DES with key.
get first packet (blowfish key).
uncrypt with DES key.
send responce packet final key or so (generatekey).
server sends final packet (unknown to me yet).

you login with your username password.

client saves username (it does in a extern file).
client uses the xor key on the data packets.

-----

1 problem though.

if i type hello ingame.

first time i get lets say ".o...!<k"
second time i get maybe "...#..s!"

but, thats ALWAYS like that aswell, if i use same username....

but the text i send is the same, so that does look wierd to me, there has to be something i missed somewhere.

any idea's ?

As discussed earlier, you really shouldn't bother too much with what algorithms are used and try to break these, or even necessarily manually try to catch the key and decrypt them yourself. It's all about finding the point in the code where they are decrypted by the program itself, and then hook it.

And yes, the existence of a plaintext buffer is necessary, otherwise the encrypted data wouldn't be much good for anything, now would it? In the worst case, it could be decypted one block at the time, overwriting the previous block, but it shouldn't be really hard to extract it all by hooking that code either, if you just pinpoint it.

okay hmm, then i need a few links to how :

find a inject address (i use IDA pro if that helps)
find a loader addreess

and how to intercept a buffer -> log buffer -> return to program and continue..

i tryed all kinda things, i just cannot get it to work..... i never wrote a program like this before, and asm pussles me....

i tryed "cracking" this for .... well lets just say.. too long, and the furthest i ever got was, well the stuff i wrote here.

i tryed finding "how to hook plain text buffer" in google, but nothing turned up, i tryed reading some source for another games plaintext buffer hook program, but, he didnt really comment anything very well and it looked VERY advanced..

maybe someone can show me a few code lines that might be interrestet for what im doing ? (eg past projects or something, or perhaps another site with some interresting code snippets)... or simply... alot of documentation on how to do it..

i DO understand that a plaintext buffer hook proggie would be uber good to have, also if they change encryptions or something, but if i got this trouble making it.. well you get the idea...

tools i got right now is:

IDA Pro 4.3
Visual c++ 6.0 sp5

testing inviroment:

fake server with "force set" packets to test stuff locally.
real server acc to test on real servers.

i cant belive it would be this hard to make, sure, its "advanced" but thinking all it have to do is.

print plaintext in buffer
print plaintext out buffer

nothing else..

anyways, once again, i do apriciate all you guys help, and i almost feel bad asking so much, but i really always wantet to do this... imagine it as a dream i have, for along time, its in my grasp, but.... i continue to fail making it work, its so... frustrating..

well, once again, thanks and all further help, guide, links, snippets are appriciatet.

With your current level of knowledge, I sadly think it would be practically impossible to explain any further to you what to do in this case, without actually writing the whole program for you.

Here are some good tips though:

1.
Don't use such specific google searches, you cannot expect to find exactly what you want, you can often just find information that will enable you to do what you want.

2.
Study some assembler programming, then search for, and study, code injection and hooking in general (there are lots of stuff about it available by a simple search on google).

3.
Make sure you understand how crypto can and will be used in programs.

4.
Apply all this knowledge to this problem, and you will come much further.


I'm sorry, but there often isn't a "quick fix" that will work unless you have the required background knowledge, sad but true.

Good luck with it all anyway, and you are very welcome back here with some less general questions related to this project when you have increased your knowledge level to one reasonable for this project.

well, not to talk against you, i do know a bit, its just a few things im in doubt off...

i do understand, if you put in your loading code, you need to save the registers you replace and then after your injection dll is done running whatever it will do, you run thru the registers you saved and jump back into the program.

what i dont understand:

where do you find a empty place to inject your loader code (.data, .text, ...?).
where do you find the inject location to run your "hook". <-- this one i have ALOT of problems with.

obvious, the location to inject the code call whatever_stub need to be at start of the program, or else there aint much point in loading it because the target sends 3 packets i need at init of program.

so question is, should i inject it at init winsock ? since thats usually only done once at program startup ?.

eg:

some asm.
call mydll_stub -> it runs then does what you removed and jmp back to "some more asm"
some more asm.

or should it be put at the buffer location ? this is what i am in doubt about.

and i did study some inject programs, and i did read a bit about asm, but im running tired, and i been at this "target" for over 2 years (i learned alot, in beginning i was a fool though and did all kinda stupid stuff that never worked or could work), so i would say about 6 month trying to locate encryptions, and now finally getting somewhere but still far from...

so as you can see, im determined, and i will make this work, even if i have to sacrifice 2 years more of my life to do so.

Yes, it is indeed very nice to see that you are really determined and willing to put down your own effort to make this happen. What I'm telling you is that at this point you will have to put down just a little further effort before we will be able to answer your remaining questions with any reasonable explanatory effort, that's all, please don't take me wrong.

Just go study code injection/hooking some more, and we will be able to continue, that's all I'm saying. Since you ask where to inject the hook code, I assume you are not very familiar with dll injection, please read up on this subject and then return, and I'm sure we can continue this.

Finding the hook location can only be done by disassembling/tracing/analyzing the code of your particular program, and then following the advice we gave you earlier in this thread about where to inject the hook, and noone here will be able to tell you any more than this, so making sure that your reversing skills are good is critical for this point, more than anything else.

Again, good luck, and see you later.

hehe this aint going so good :\

anyone interrested in making some quick $$ making me the plaintext hook ? (if this board dont allow it, i ofcourse wont do that).

k well i read alot more on hooks, specially enjoyed this one :

hxxp://www.viksoe.dk/code/wepmetering.htm

made it pretty clear what to do and so, i read some about asm but dunno... i just cant get it to work....

i locatet the buffer in & out from winsock (after decryption, before encryption) in the send, recv..

i THINK i locatet the encryption rutine too.. but not 100% on that...

anyways, i still cant get it to work, i have alot of problem on where to inject the hook, and where to inject the call to the hook.

everytime i try it crashes...

okay gonna try removing the anti debugging thing, seems thats a nessesary step to make a hook (locating inject point and so)....

when launching the file in a debugger, i get this error:

the code it breaks at is:


im not quite sure what to do from here, ill try searching the forum a bit more on the topic, but i already tried searching alot, perhaps i missed it...

else, any comments on this would be nice (perhaps if you seen this before).

It's impossible to know from only seeing that single code line. The edx register apparently contains a bad address there, so you should trace its contents backwards to see how this address is built, and the execution paths leading to it, and look for suspicious things along the way.

Hi! I read the whole thread. I summarize here what I understood:

1. we've got a packed application
2. the application communicates to some server with encrypted messages
3. you're trying to find where the plaintext messages get encrypted or decrypted

I'm going to have a lot of spare time and I love to disassemble PE files... Mail me a link where I can download the target if you wish. Best before next Friday.

Peres

P.S.: I won't download ISOs!

i have mailed you thanks

I read through the entire thread as well since I am very interested in game hacking. My suggestions to the author:

1) learn code injection and test with easy target, say notepad.
2) don't worry about encryption, because the game, no matter how strong an encryption it uses, it will have to provide the gamer the plaintext information (if you fail to see this point, you need to really *think* harder which is something currently lacking in what your post has shown), therefore you always have ultimate control of information on client side.
3) i found it most useful to find out the keyboard handler subroutine in a game setting, and hooking that subroutine to execute arbitrary code, again, practice with easy target first, even the ones you write your own keyboard handler source code so you know exactly what's going on.
4) assembly knowledge is a must for this kind of game hacking, therefore prepare to learn it thoroughly or let it pass.

homersux ya, but i would have to use years to learn hardcore assembly for this target, and for this target only since i dont plan of making a habbit out of breaking encryptions (but who knows).

and as i said time is running out for the "target".

btw, the cash offer is still up, and we are not taking 5$ here...

75$ for plaintext hook & source (prefer c or c++).
100$ for plaintext hook & source & the encryption rutines.

the offer is 100% serious, because i do not belive i will ever have all the skills needed for this target.

if people enjoy breaking a exe down, why not do it and make a bit extra ?.

anyways, i downloaded the The Art of Assembly Language book on the net and startet to read it, but its a endless long book if you ask me...

well finally found a memory monitor that works with this target, i can read all memory the target uses, quite some interresting things in there.

now i just need to locate what buffer location is the blowfish key storage location, then i should be able to figure out how it makes that key / what the key is.

Sounds good, keep up the good work. Btw, what is the name of the good memory monitor that you found? Did you try out several of them and can recommend some of them? It's always nice to hear from people who compared several different tools within the same area.

im using MemoryMonitorXP from

http://www.spywindows.com/PAGE1/SOFTWARE.HTM

(note its shareware so i guess its ok to post the link).

it seems really good, im using the "function" in it called Process Memory Explorer, it list the memory locations and so on, and so on, and.. well u get the idea.

this one, instead of hooking the target, it hooks the system memory thingy, and then it can display every programs memory use, without the "target" knowing its there.

so memory hook will work nomather what.

Ok, sounds good. It also seems like they have a pretty nice collection of different kinds of monitoring/hooking tools in general, I'd recommend people to take a look at that site.