Legacy RO - Harmony 2.0

[Kleenex]

Hmm... On most chinese botting communities, AuKore is usually the 'fall back' program if openkore fails to connect to a target server. It's widely known for being able to just about everything.
As far as the technical parts go, I have little understanding of the difference between openkore and aukore... I'm just a random user. AuKore just always works, in one way or another.

[paradox]

any updates darkfate?

[ic434]

Guys... This is a easy one. Let me enumerate the vulns..

From bottom to top, this thing is totally open to cyborging... At least what Ive seen so far seems to indicate that. There MAY be some client protection to stop DLL injection but thats easy to bypass..

Inject option 1) They have a loader exe. LOAD IT WITH ANOTHER EXE AND HOOK THE CreateProcess function and inject your hax dll before they can inject theirs. Note DO NOT hook the connect and send functions, you WANT to pass your packets through their dll so they get crypted...

Inject option 2) Note this one takes some shell code to do so you gotta know some asm for it.
Build the following... NASM will work fine....
Something like this...

Code: Select all

;Thread main call like thing, doing a remote create thread...
;DWORD shellcode( void* lp_dllname )
push ebp
mov ebp, esp
push [ebp-8] ;Name of our dll
call LoadLib ; Needs to be the hard coded address of load lib....
;Hura we are done
mov esi, ebp
xor eax,eax
retn 4

The dll should NOT attempt to locate the REAL addresses of the send and recv functions, used the hooked ones so your packets are crypted.

Option three) They have a key SOMEWHERE, either its in the dll or sent by the server, neither is hard. They are HOOKING at least the send, go in set a break point in the send function of the exe and trace it through IDA.* They are going to crypt the packet there so they have the key somewhere in there. I bet if someone went looking they could find it in under two hours. I know I could but I dont want to install their client.

*YES sakexe sends all its packets through ONE point. send is called from a DWORD value, find it, trace the reference and set the break. The DWORD they write the function address to is EASY to find. Look up the references to the GetProcAddress function in the sakexe and find where it passes the string "send" to it. The dword they store the address to IS VERY CLOSE TO THAT!

Why did I post this? Not because I dislike legro but because if they are going to do protection they should DO IT RIGHT.

Was it good for you too?

[darkfate]

Guys... This is a easy one. Let me enumerate the vulns..

From bottom to top, this thing is totally open to cyborging... At least what Ive seen so far seems to indicate that. There MAY be some client protection to stop DLL injection but thats easy to bypass..

Inject option 1) They have a loader exe. LOAD IT WITH ANOTHER EXE AND HOOK THE CreateProcess function and inject your hax dll before they can inject theirs. Note DO NOT hook the connect and send functions, you WANT to pass your packets through their dll so they get crypted...

Inject option 2) Note this one takes some shell code to do so you gotta know some asm for it.
Build the following... NASM will work fine....
Something like this...

Code: Select all

;Thread main call like thing, doing a remote create thread...
;DWORD shellcode( void* lp_dllname )
push ebp
mov ebp, esp
push [ebp-8] ;Name of our dll
call LoadLib ; Needs to be the hard coded address of load lib....
;Hura we are done
mov esi, ebp
xor eax,eax
retn 4

The dll should NOT attempt to locate the REAL addresses of the send and recv functions, used the hooked ones so your packets are crypted.

Option three) They have a key SOMEWHERE, either its in the dll or sent by the server, neither is hard. They are HOOKING at least the send, go in set a break point in the send function of the exe and trace it through IDA.* They are going to crypt the packet there so they have the key somewhere in there. I bet if someone went looking they could find it in under two hours. I know I could but I dont want to install their client.

*YES sakexe sends all its packets through ONE point. send is called from a DWORD value, find it, trace the reference and set the break. The DWORD they write the function address to is EASY to find. Look up the references to the GetProcAddress function in the sakexe and find where it passes the string "send" to it. The dword they store the address to IS VERY CLOSE TO THAT!

Why did I post this? Not because I dislike legro but because if they are going to do protection they should DO IT RIGHT.

Was it good for you too?

Hello ic434

First of all thanks for your help/information about the encryption/protection. Well Legacy RO had a protection before which was using blowfish with a 256 byte key which changed after every packet. Anyway that encryption was cracked by us in less than an month after it got released.

The main problem is that it's a private encryption which will change again after we crack it. It would be stupid to crack Legacy RO's encryption again. First of all there aren't enough botters on that server and the encryption would probably change again after a month or less. So what we need is a general solution to bypass encryptions by using the client, in this way we could support a lot more servers (there are enough private servers using encryption out there) and make it harder for the server owners to develop an encryption.

The solution I had in mind is "XKore 3", sending the packets through the clients socket instead of redirecting everything to openkore and sending it from there (well we'll still redirect the packets to openkore to mangle them if necessary but then send them back to the client).

I'll probably have some time again after my last exam which is next week, but if anyone wants to start the development of a general encryption bypass system for openkore just go ahead and don't forget to post here that you're doing so. (It would be silly to code it twice..)

[Motivus]

XKore 3 is a good idea, but it's much like emulating the encryption. They can easily update to detect it as long as they have a coder who wants to do it.

[sli]

So a whole new version of X-Kore (which doesn't work as it is) just for servers that use encryption? Ok guys.

[Motivus]

So a whole new version of X-Kore (which doesn't work as it is) just for servers that use encryption? Ok guys.

XKore is completely functional, but no one has added support for the latest EA packet version yet.

[darkfate]

XKore 3

Basic idea

• Use the client's own send() function which is often hooked by general encryption systems to encrypt the packets to be sent.

How

• Develop a DLL which hooks into the client process and hooks its send function.
• Develop an OpenKore plugin to redirect all the packets to the injected XKore 3 DLL.
• DLL and plugin will communicate through a socket. Either DLL or plugin will have to act as server.

1. The injected XKore DLL redirects the packets to OpenKore
2. The XKore 3 plugin hooks the send function in Network::Send and redirects the packets to the injected XKore 3 DLL
3. The DLL will then call the client's send() function to send the packets received by the XKore 3 plugin

Implementation
Since I'm not interested at all in implementing an encryption bypass system for a few people that play on those private servers which use an encrypton I won't develop this. If you are a developer and want to play on a private server that uses an encryption, feel free to develop XKore 3 and share it with the community (only if you want of course).

Resources

• DLL Injection Methods
• Detours Library
• XKore Sources

FAQ
Q: Why would you redirect the packets to OpenKore first and the redirect them back to the client? Can't you just let the client send its packets and redirect OpenKore's packets to the client?
A: The reason why XKore redirects the packets to OpenKore is to let OpenKore have more control over the packets being sent. Like this OpenKore can mangle or modify the packets sent by the client before sending them to the server.

Q: Will this really work?
A: Actually I don't know, it's only an idea I had in mind and if this is every developed, private servers will most likely find a way around this too.

So what you should do: GIVE UP! Unless you don't keep a reversed encryption or bypass system for yourself it will probably change in less than a month. Unlike encryptions on official servers, private encryption solutions can even change weeks or days after a solution for the encryption has been released.

[paradox]

nice job keeping everyones hopes up for 3 months you [censored] promising to fix kore for lRO, and not actually doing anything in the end.

[censored]

EDIT: Disregard that, I suck cocks.

[darkfate]

nice job keeping everyones hopes up for 3 months you [censored] promising to fix kore for lRO, and not actually doing anything in the end.

[censored]

What, 3 months? I fully reversed/cracked the last harmony encryption and that was about 1 1/2 months ago.
Next time you're banned you ungrateful idiot. Oh and actually, I don't remember promising anything XKore 3 was just an idea from beginning, nothing more.

Btw didn't you actually get the point? It doesn't make sense to fix it since they will have a new system after a month or less anyway.

People like you are the reason why I hate 99% of the OpenKore community. You want to bot on lRO? You don't deserve it and you didn't do anything to deserve it either. At least others (like Barracks and Kees) were in IRC every day and even helped cracking the old encryption. What did you do? You were probably wanking or w/e..