Hello fellow proggramers.

What is the general community stance on reverse engineering the binaries to make mods.
Something like LFSLazy does where the application hooks into the Direct3D calls to draw stuff on screen.

Since some features in LfS could only be implemented in such a way is it frowned upon to post certain addresses somwhere if someone did RE the binaries.

Displaying engine damage by reading memory was in my opinion a cheat and I did not like it. Not a big deal but it was one reason why I never used that program. (Yes, I know that newest LFS version has engine damage display for everyone, so it is fair now)

Another function I do not like is "Radar", no matter if it is done by normal Insim or by hooking into LFS.exe
I am simply not a fan of too much on-screen GUI in sims. For many car classes it feels out of place, too high-tech. I feel that being aware what happens around your car (mirrors, sound, looking around) is an important skill. Radar goes against that. However, on some setups with small screens can be hard to do that so I do not mind if people use it.

I am not aware of anything else.
Sometimes broadcasts use overlays for position lists etc, I do not know how they do that. I am okay with whatever way they do it because it is only used for videos, not for racing.

If LFS get modified too much there might be a risk of breaking multiplayer?
I would not like if some races required manually downloading modified files because that is always a mess in other games. (I think in LFS that was only done once for a NASCAR experiment, before mods system)

Its not all bout overlays.

What I wanted is to document function addresses for plugin development. Either graphical or other.
The mod system currently only revolves around cars.

Basically what Im trying to do is see if Scawen minds me and other people possibly messing with the binaries as well as the stance by the community at large.

If it is acceptable it would be nice to have a forum thread dedicated to documenting various addresses accross versions wich would help old and new InSim proggramers.

Sky is the limit, knock your self out

Quote from Gutholz :

Sometimes broadcasts use overlays for position lists etc, I do not know how they do that.

With InSim.

Quote from mbutcher :

With InSim.

Everything? Some things are not possible with Insim I think.
For example:

At least the car graphic must be overlaid in another way. (Maybe in the streaming software)

All of the data in our broadcasts is pulled via InSim, but that car graphic is generated before the broadcast from the skins teams submit.

There is no point in talking about streaming software. As said before this is not entirely about graphics.

Imagine finding a raycasting function somwhere inside the binaries to use within your own program.

Imagine having voice chat inside LfS and better chat integration.

A similar discussion in the LFSLazy thread with reactions from Scawen: https://www.lfs.net/forum/post/2044466#post2044466

Yeah I've seen that. Kindoff what sparked this question.

Started the reverse engineering project by myself to make an API for local InSim apps.
Since LFSLazy does hook into the LFS.exe process but Scawen says its allowed in that case.
I dont know if it would be allowed publicly doe.

So mainly the goal here isnt to make a copy of LFS but to document the binary for mod development.

I already have a small chunk reversed but in reality I wouldnt feel good publishing my findings knowing that the devs disagree no matter the legality of it.

Quote from xolan1993 :

So mainly the goal here isnt to make a copy of LFS but to document the binary for mod development.

That sounds like a different kettle of fish to what's going on in the LFSLazy thread. Maybe pinging the devs an email might be a good starting point to see what they think about that idea, before you sink too much more time into it.

Quote from xolan1993 :

So mainly the goal here isnt to make a copy of LFS but to document the binary for mod development.

Assuming Scawen was OK with it, wouldn't you still need to redo this work every time there's an update? I don't know much about the practicalities of compiling source to an executable (mine are not-that-kind-of-compilation), but is it possible and/or practical to steer a compiler to store variables in a set place in an exe?

Quote from Gutholz :

I am simply not a fan of too much on-screen GUI in sims. For many car classes it feels out of place, too high-tech. I feel that being aware what happens around your car (mirrors, sound, looking around) is an important skill. Radar goes against that. However, on some setups with small screens can be hard to do that so I do not mind if people use it.

Same, if I use a radar it's more for other people's benefit than my own

I always preferred to use the AONIO radar over Lazy's because it was 'lower-tech'... but have to admit Lazy's was much more helpful (too helpful for realism, as you say, but it is nice to not be "that guy who doesn't know what's happening around him" now and then).

Quote :

I don't know much about the practicalities of compiling source to an executable (mine are not-that-kind-of-compilation), but is it possible and/or practical to steer a compiler to store variables in a set place in an exe?

No it is not possible by conventional means. Meaning each version should be reversed individually.
Its tedious but trivial to find those addresses with software like Ghidra, CheatEngine and dbg64.
The hard part is the addresses of the functions and what those functions do. That is where reversing becomes hard.

Reverse engineering LFS.exe is a fantastic gateway to cheating.

Well, it's the key, right?

I can't see positives in it. I can see many negatives including the total destruction of online racing. With other software I believe this is usually banned. We provide a special interface "InSim" to get data from LFS and set values in LFS by legitimate means.

We have a lot of community interaction and we often add new features to InSim when they are requested by community developers.

We've created a mods system so there is no need for editing the exe for "tweak" purposes.

So, I can see no reason to allow, accept or support editing of the LFS.exe by community developers.

Thanks so much for your input Scawen.

So as prommised I wont publish my findings no matter how much this saddens me.
I will doe use my findings in any future InSim program and will probbably try to obstruct the addresses so others can not snoop around my binaries to gain access to them, if that is acceptable.

As much as I think cheating software can be fun, naturally it degrades the online experience and noone wants that.

With kind regards

Shouldn't you share your findings with Scawen, so maybe there's a way to make it less easy for cheating?

I'm still not hearing good reasons why memory access should be accepted or allowed these days.

Isn't it better to take the approach of adding certain values to InSim packets?

I mean something like this:

- Person suggests idea for value to be input or output by InSim
- Community discusses this idea, alerts me
- If possible I add the value to an InSim packet

This can take time but then everyone is happy.

While I agree the topic is sensitive and can bring havoc like it already did, I have never been satisfied with Insim as a way to access car data, and this for 2 main reasons :

- too few data things available via Insim.
For years I wanted to access fuel level to check for cheating, because it's so easy to change that value in memory and cheat races without being noticed, specially endurance. Now you added it in Insim and people can make code to check fuel usage and expose bad guys, that's good ok.
It would be usefull for example to get access to tyre temps, tyre wear or clutch wear because those are as easy as fuel level to tamper with.

- for a local app, like "revbouncer" for example, the issue with Insim is the complexity of the code for network communication compared to direct memory access (at least for me), and also the lower access speed with network, wich is a major issue for a responsive ignition cut rev limiter (ability to ignition cut without mem access is another example missing from Insim).

Maybe something like an API would be nice, we could even overlay graphics easily with it.

Am not writing that mem access should be supported at all, this just a perspective from someone who spent some years exploring lfs code and mechanics, with passion and love, because hacking is like solving a scientific problem or a criminal investigation.
I learned a lot with it and I didnt release anything that would allow cheating so it's not always bad.

On a side note : you do great job again, but please clone yourself or teach Scawen Jr. so he can help

One technique that iRacing uses for its telemetry is a memory mapped file for telemetry that then applications can read to get data out of. It might provide that same ease as just reading the memory without requiring reading memory.

Regarding rev bouncer, an option would be to have it implemented as an official optional feature of car mods? This would eliminate the need for such 3rd party app.

Hey there,

I've created the PACT Driving Assistant Scawen mentioned in an earlier post and I have to say I see why for some use cases it might be a little more suitable to read and write memory directly,

BUT most (almost any) application or use case i can think of can be done with data from insim. For some cases like ignition, you can just go ahead and send some kind of direct input to LFS to emulate keyboard inputs / axis inputs. You can even switch immediately between controlling axis with insim (that enables me to "override" user input with steering wheels by just emulating another controller and then switching between them in game).

While i get that this might not be perfect for every use case, you can achieve most things very easily and with the insim interface, everybody has the same rules for whats possible and what isnt. Thats fair and has always worked for me. Car radar, and most car data use cases are possible with insim easily as well so i also dont really see the point of memory reading either.

And a revbouncer is one of the easiest tasks with insim, works perfectly and required like 5 lines of code . Even though i agree it would be cool to have a revbouncer option natively in LFS.

hey rob2003
If I read u well, Insim wouldnt have needed any update since first version of the MCI packet.
Maybe u dont see the point of hacking because something blocks your view, or maybe u just not curious... a few tools using mem access like steerlock or templock have been very popular for a reason.

Anyway for rev limiters, switching ignition via Insim by sending keyboard input has already been done a few times in the past and it's always been terrible because that method is much too slow to achieve a convincing result.

Quote from mbutcher :

All of the data in our broadcasts is pulled via InSim, but that car graphic is generated before the broadcast from the skins teams submit.

It was the idea of this suggestion (to automate it a lot) : here

As for Rev bouncer/throttle blip, It should not be OK if it is not part of the car.

Yeah right. Forgot to ask.

If by any chance durring my adventure digging trough LFS I happen to run by a bug or some decrepid piece of code that should be updated how do I go about reaching out to Scawen in order to alert him to the issue.

Posting it here publicly could be a bit of a security concern I belive.