Today I finished up the registration / login code as well as the integration with Plimus, our new payment processor. You can purchase RiPE VIP after logging into your account. Note that these accounts are separate from the forum.

Before purchasing VIP, please remember: THERE IS NO NEXON GAME SUPPORT FOR RIPE STAR VIP OR ANY OTHER PROGRAM ON THIS SITE.

As a side note, I have also updated the "Change HWID" page. If you're logged in, you don't have to re-enter your user / pass.

I have also removed ads for people who are logged in.

RiPE Star VIP v2012-01-22 is now out. It's been a long time coming, but RiPE plugin support is now here. There will probably be a few minor bugs with RiPEST still, but I'll get them worked out asap. Please let me know if you stumble upon any RiPEST bugs as well.

• Added plugin support for RiPE. You can now use RiPEST scripts to modify the way RiPE behaves. There's a convenient button to add scripts on the Game Select Menu.
• Added many new functions to RiPEST.
• Fixed many bugs in both the lexer and the parser.
• Added near function calls. Example usage:
  
  Code:

  ---

  someFunction = 0x00401000
someFunction(14, 23)
calling_convention = msthiscall
this = 0x12345678
someFunction(this, 14, 23)

  ---

• Added support for the following calling conventions: cdecl, msfastcall, borlandfastcall, syscall, gccthiscall, msthiscall, stdcall. If you need help understanding how each of them works, please review http://en.wikipedia.org/wiki/X86_calling_conventions.
• Added ASCII message boxes. The function for this is "messageboxa."
• Added support for 'strings'. Example usage:
  
  Code:

  ---

  // Note the SINGLE QUOTES.
messageboxa('Hello World')

  ---

• Added support for the "scan" function. This allows you to scan for AoBs (Arrays of Bytes). Example usage:
  
  Code:

  ---

  // Note the single quotes.  Do NOT use double quotes for this function!!! 
// Scan for the AoB matching 12 34 56 ?? ??.  Get the 2nd result.
// Start at memory address 0x00401000, and scan until 0x00600000.
AwesomeFunction = scan('12 34 56 ?? ??', 2, 0x00401000, 0x00600000)

  ---

Over the next few days, we will be migrating to a new domain name, unallied.com. I decided to make this change, because I feel that unallied.com is a much more professional name than riukuzaki.com. I will leave riukuzaki.com up to redirect to unallied.com, as it is not my intention to change domain names to avoid anyone or anything.

For those of you who haven't gotten the message already, all Nexon game support has been removed from RiPE, RiPE Star, RiPE VIP, and RiPE Star VIP. Furthermore, no current or future version of any of my programs will support Nexon games.

This was also the cause for RiPE and RiPE Star's sudden and complete termination a few days ago. As most of you have already found out, RiPE and RiPE Star close instantly as soon as they're opened. This is not an accident. I will upload a new version of RiPE Star that has all Nexon support removed from it.

A new version of RiPE Star VIP is now out.

• Nexon games are no longer supported.
• Added GUI improvements for RiPEST. You can now save, load, and delete scripts. As of now, "Load Scripts" will simply reload scripts found in the /scripts folder. Saved scripts will auto-load when you start up RiPE.
• Added "time" events to RiPEST. Below is an example usage of a time event:
  
  Code:

  ---

  time 1200:  // every 1.2 seconds
    send("12 34") // send the packet "12 34"

  ---

You can download the latest version [Here].

P.S. It would be really great if I could get some sort of "custom RiPE" support for RiPEST. Such as being able to change how/where RiPE hooks, what information is logged, and so on. I think this would be a much easier to reach goal than making some super-generic "uber" script that can magically detect how to work for some program.

In fact, this feature would probably take very little time to implement. I'll consider it once I have some more of RiPEST finished. Before I add this level of support, I'm going to need at least the following:

• Function calls to arbitrary addresses in RiPEST.
• Support for "AoB" scanning.
• Support for all common calling conventions.
• Support for DR / Int3 / direct hooks.
• Support for modifying RiPE through RiPEST.

I guess this will really test just how efficient RiPEST is when it comes to performance!

I have decided to change my MSN address to separate all things Riukuzaki.com, Gamersoul, and PonyMS related. My old address was just for friends. Now getting some people that only need help with RiPE, BT, ect.

New address: ipodguru@hotmail.com This address is mainly for help with RiPE, BT, ect. Mainly anything that does with here or Gamersoul.:D

Note: Original address I will use until I have enough contacts to stop using the old one less then before.

As some of you know, I've been working a bit on a new MMORPG. The client will be written in Java, and the server will either be C++ or Java (I'm leaning towards C++, but we'll see). The game is essentially a mix of RuneScape + MapleStory + Dark Cloud 2 + WoW + Terraria. I'll leave it up to your imaginations what that kind of game will be like, but I will say this: the focus is on solo / small group play.

So far I have finished the documentation for it, so now it's time to "jump in" and start coding the basic parts. I'm expecting this game to take one week for networking, one week for basic game logic, one week for the server, and then the rest of the time will be spent on more specific mechanics. Some of the specific mechanics include: creating monsters, items, different blocks, skills, etc.

I'll release more updates as I make more progress. As usual, donators will not be forgotten. I'll have to think of something. :)

Due to some complaints, RiPE, RiPE Star, RiPE VIP, and RiPE Star VIP are going to be changed. Instead of choosing an algorithm based on program name, RiPE is going to learn how to encrypt/decrypt/send/recv packets based on a generic algorithm. It's going to be very hard to do, but I'm sure it's possible. Some of you may not know this, but RiPE actually uses the same exact algorithm for several programs. ;)

It is very likely that, once this is finished, you will have to help RiPE learn how to encrypt/decrypt packets. I have some ideas floating around in my head at the moment, but one requirement is most likely going to be sending a packet that has a string inside of it, such as "abc123." RiPE will look for this, and if it's found, it will know that it has the decrypted packet.

The next step is probably going to be to repeat that a few times to make sure RiPE gets the right header. This could be very tricky, because headers can be of different length.

I also have an idea for a generic bypass. I've never made a bypass before, but I'm pretty sure this method will work. Basically it involves the following steps:

1. Make a copy of a region of executable memory. Think of this as part of what LoadLibrary does when it's loading a Portable Executable.
2. Set the copy to have executable / writable permission.
3. Fix the offsets in the copy.
4. Set the original region of memory to read only. This will cause a CRC to continue reading as if nothing is wrong, but an exception will occur if an instruction is executed.
5. Using Vectored Exception Handling, redirect Eip to your copy. The stack will fix itself over time.
6. Use this new, undetected, region of memory to make any changes.

For an experienced coder, I estimate that this will take three days to code or less.


Question: As a company, how can I stop this method?
Answer: Simple. Create a new thread that scans for a duplicate region of the memory you want to protect with a CRC. If you find more copies than you expected, then terminate / crash the program. In fact, this is probably going to work for almost all CRC bypasses, and it's very easy to implement. You will need to be watch out for the following three cases:

• The copy of memory may not be aligned on a page. Because of this, you shouldn't make assumptions about its location. Just scan through all memory.
• The copy may be protected on both sides by what are known as "guarded" regions of memory. If you use IsBadXXXPtr, you will fall into this trap very easily. There are several easy methods for dealing with this, so I'll leave it up to you on how to handle it.
• The copy may be protected by what is known as a "debug register", or hardware breakpoint. You should have a sufficient method for detecting DRs. One such method is to simply use all of the DRs yourself, and if any of them change, the program crashes from an unhandled exception that won't be caught. You, of course, will need to set it up like this.

RiPE VIP and RiPE Star VIP have been updated with some bug fixes for RiPEST, the packet scripting language.

• Fixed issue with empty lines causing blocks to mess up.
• Fixed issue with empty comment lines.
• Fixed issue with carriage returns messing up scripts in rare cases.
• Fixed issue with function calls that caused problems when using operators. e.g. messagebox(s[1].s[0]).

RiPE VIP and RiPE Star VIP have been updated. The new version contains:

• Added bypassless block and modify for send and recv. Should work almost identical to the bypass required version. Please note that as of now, you cannot shorten the length of a packet. This will be fixed in a future update.
• Fixed modify across all games
• Fixed miscellaneous bugs

You can get the latest version [Here].

Starting in a few days at most, we will be implementing a new system for determining if someone is able to use RiPE VIP. This will only affect people who have been getting RiPE VIP from their BT purchases on GamerSoul.

The new system will give you access at the time you purchase a BT license. For example, if you purchase a 31 day BT license, you will get 31 + 7 days of RiPE VIP starting on that day.

No other changes are being made to the RiPE VIP system at this time. Again, this only affects those of you who are getting RiPE VIP access from a BT license.

Update: The changes have now been put in place. For more information, see http://www.gamersoul.com/forums/show...ough-BT-Update.