I'm pretty sure it's not a walk in the park. That's probably what he was getting at
I'm pretty sure it's not a walk in the park. That's probably what he was getting at
Well, you have to reverse-engineer the dlls. VoiDeD is 'just' retrieving the interfaces.
Fair enough. I thought you were implying it was bad to do rather than hard to do.
It is bad, Valve don't like external apps messing with their shit
It will probably go against your EULA or something, or it will think you're using PacSteam or whatever
FU, that's what I was going to start working on today, and now everyone will think I stole the idea :sigh:
lolno
Then they should open up their chat protocol. They told me they would go to XMPP sometime this year, haven't heard from them since.
Edited:
If someone provides you with an idea, it's rarely seen as stolen, you know.
It's it's possible but probably insanely hard to do, right?
It isn't if the OpenSteamworks implementation is really as far as it seems.
Then it's just as easy as coding a new Steam client with the source to the DLLs.
Well, so far VoiDeD only provided the interfaces, as such you cannot code a completly open Steam client yet, until the implementation to the interfaces also gets reverse engineered (or open-sourced by Valve or leaked).
One of the things that VoiDeD discovered is that valve uses key-based encryption for most of it's entry level handshaking. Meaning, unless you know valve's public key, there is no way to actually login to steam with a 3rd party client.
However, since he interfaced steam.dll, he just uses that, bypassing the need of a public key.
The public key is either provided during the logon procedure or is stored in steam itself. I'm unsure as of which and I haven't spent much time figuring it out. Either way it's possible to login with a 3rd party client.
However, reversing the network protocol would not be as hard as reversing steam.dll/steamclient.dll with an aim to recreate all network functionality.
As for what I'm currently doing, I'm trying to figure out how to make steamclient.dll intefaces play well with steam.dll. I'm able to get steam.dll to logon to steam servers, but all secondary logon attempts with steamclient interfaces have failed.
Oh god does this mean this could be used to make a Steam Messenger
Read the damn thread lol
Excuse me as I don't know shit about reverse engineering but how did you get the .lib files?
http://support.microsoft.com/kb/131313
On an unrelated note, I'm still having no luck with the logon procedure so far.
http://code.assembla.com/steamworks/...tform/main.cpp
It seems like it should work, but I always get a SteamServerConnectFailure_t callback with k_EResultInvalidPassword result. I've triple checked that the password is correct, so the error is due to something else.
I hope this makes any sense:
Although I don't know why, but might the function expect a modified password (salted or something)?
Do you have an error in your code so it gives you an InvalidPassword result instead of the correct one?
Very interesting project you've got going.
I wish you nothing, but the best of luck Good Sir.
This is why commas are important.
hi my name is NeoDement and I KNOW NOTHING AT ALL as usual
Oh my shit, we now have the ability to make an iphone app :D
It uses the steam dll, which is not very portable.
If anything it could be used to make a normal Windows application with only messenger capabilities that would run normally under Wine.
you may want to ask...uh... some of the people who have managed to crack steam. most of those programs are open source and you could look in those to see how they are doing it.
I think the standalone downloaders aren't open source.
And even if they are, I think the downloads are handled via a different protocol.
BUT you can make a client for your own server which connects to Steam with the Steam DLL (that's what most of the mobile IM clients for mainstream protocols do anyway)
Exactly my point, Wine can make that cross-platform.
Wait a minute, even better...
Isn't it possible to create a program using Mono that will use the steam.dll?
Edited:
This may help to determine if it'd work:
MoMA
steam.dll isn't a .net assembly, so mono would have no clue what to do with it.
You could, you know, just run that on a Windows server?
A Steam client? Or a relay? Either way, if I go to Linux, I will not have access to one.
Then Wine will still be the way to go.
blankthemuffin was working on seeing if it was possible to use winelib to get steam.dll working on linux. If he ever gets that figured out the only remaining step would be to create a new linux version of steam.exe.
Two problems remain with this: blank hasn't managed to get winelib working, and I haven't figured out steamclient.dll logon yet.
Yeah I've hit an early roadblock with winelib, seems to be x86 vs x86_64 problems on my end, but I'll have to set up the former in a vm to test.
Wouldn't you be able to hack debug functions into the winelib so you could understand more about how steamclient.dll calls the Win32 API (especially networking)?
Oh wait, you could just use a network sniffer... dunno which option's better in this case.
I have no idea how wine/winelib works, so blank would have to answer that.
As for implementing your own version of the network protocol, that's entirely feasible. It's far easier than recreating steam.dll, but still poses it's own challenges. I posted a little bit of how I think the protocol works, so check the previous pages of this thread if you're interested.
You could see way more than, network things.
yes yes yes (i hope)
Why would you need to know that for implementing your own protocol? It can be completely independent
I meant your own implementation of the protocol valve uses.
-the sound that scissors make when cutting paper-
So, is the C# version ready?
god damnt