Video Game Hacking using Kotlin/Native by Ignat Beresnev

Рет қаралды 16,174

Күн бұрын

Recording brought to you by American Express. americanexpress.io/kotlin-jobs
Have you ever wondered how video game hacks, trainers, and bots work under the hood? Would you like to implement one in pure Kotlin? If your answer to either question is yes, then this talk is for you! We’ll cover the theory behind basic video game hacking and see how easy it is to take the first steps with Kotlin/Native - all with approachable instructions and examples to get you started.
Talk by: Ignat Beresnev
#hacking #games #KotlinConf

Пікірлер: 32

@hbfl3x50 Жыл бұрын

Bring this guy to most of your conf. He just sparked kotlin to be taken seriously

@mohamedrejeb6595 Жыл бұрын

This is one of the best presentations in KotlinConf, I laughed a lot and learned a lot 🤣👏

@AntonArhipov Жыл бұрын

It's the best 😁

@majacekic5466 Жыл бұрын

I like how he started with hacking and ended it with how to fix bugs and patch libraries. Hacking is bad, we don't do that, unless we have to fix issues. 🤣

@soheibbettahar1996 Жыл бұрын

This is the most enjoyable tech talk I've ever watched.

@abunaser3525 Жыл бұрын

he just make me interested in kotlin native ..

@balen7555 Жыл бұрын

Here's something that would be really cool and make this much better (and I've done this in languages like Julia): hosting a REPL in the game When you're hacking a game internally, the majority of development time is spent on the very long feedback loop of having to do the following whenever you make a change. - recompile the dll - restart the game, then load the map/state (which sometimes takes more than 1-2 minutes) - reinject the dll And you will be making a lot of changes very frequently, so you end up wasting a lot of time like this. You could streamline the experience more by having a proper hooking system, so that you only have to recompile the dll, uninject the dll from the game, and reinject, all without restarting the game. But having a REPL is even better. Though since Kotlin/Native uses LLVM, and I presume is AoT compiled, I am not sure if there's any good REPL for it. With a REPL, you could also do exploration, which is quite necessary, e.g. to test your patterns and poke at data.

@raphaelortolan4776 Жыл бұрын

This is a really good talk!

@valizeth4073 Жыл бұрын

Small correction: The windows API is NOT written in C++, it's written in C, their examples say "C++" but it's 100% C code. In C++ an equivalent API would look nothing alike.

@cpepos Жыл бұрын

great and funny presentation. ~give that man a beer meme~

@shinyparadise Жыл бұрын

Чел хорош, не волнуйся так, классная подача и материал неплохой) Надеюсь будут еще видео с тобой про хакинг с котлином

@unaisulhadi9102 Жыл бұрын

Possibilities are endless 🚀 Impressive presentation, keep going.

@TonyCalaider Жыл бұрын

Wow, it’s really cool and funny😺

@StuartGilbert Жыл бұрын

I don't really need to hack any processes, but I sure do want to right now!

@chillbro2275 3 күн бұрын

hahaha, I definitely wouldn't have thought of any of this but it was fun. Patching a bug, or writing a plugin? That sounds really cool, and useful!

@alskaa1 Жыл бұрын

Love this talk

@codemachine19 Жыл бұрын

thanks for this amazing talk =)

@sunstixy Жыл бұрын

Two things I really love, Kotlin 💜 and gaming 🎮

@AboveTHATUSA Жыл бұрын

thanks from Turkey it was a great presentation. appreciate.

@thanosfisherman Жыл бұрын

So how did he work around the WINAPI thing in his injector if not with a c++ wrapper?

@asm0di0 Жыл бұрын

Probably makes sense to read the code of injector4k

@thanosfisherman Жыл бұрын

@@asm0di0 I did but I couldn't figure it out. I'll give it another shot soon.

@cargeh Жыл бұрын

Hey! Feel free to create an issue in the repo, I'd be happy to walk you through Not sure what you mean by solving the winapi thing though

@thanosfisherman Жыл бұрын

@@cargeh thank you. I mean since Kotlin native does not yet support this WINAPI stdcall what was your workaround? How did you do it in other words if not with a c++ wrapper.

@balen7555 Жыл бұрын

@@thanosfisherman Normally, all you do is LoadLibrary your dll in the process memory, and that will call the standard DllMain entrypoint. What Injector4k is doing is besides LoadLibraryA it'll also use another CreateRemoteThread that will execute a function from the loaded dll, that doesn't have to be the standard DllMain with stdcall calling convention. In short, his workaround is in the dll injector.