| CS.RIN.RU - Steam Underground Community http://cs.rin.ru/forum/ |
|
| CAC stuff by ChrisMRuLZ http://cs.rin.ru/forum/viewtopic.php?f=15&t=37857 |
Page 19 of 23 |
| Author: | eliteapu1 [ Monday, 04 Sep 2006, 23:11 ] |
| Post subject: | |
yeah, leme get a valid mac, ill get some stuff in return |
|
| Author: | xT-Dart-Tx [ Monday, 04 Sep 2006, 23:38 ] |
| Post subject: | |
The Rules wrote: Do NOT post or request any MAC network adresses which allow you to use Cybercafe software (CAC/CAS)!
|
|
| Author: | Magnetsillen [ Tuesday, 05 Sep 2006, 00:13 ] |
| Post subject: | |
krailord wrote: The Rules wrote: Do NOT post or request any MAC network adresses which allow you to use Cybercafe software (CAC/CAS)! Exactly - the rule still exist. I watch you guys.. |
|
| Author: | ChrisMRuLZ [ Tuesday, 05 Sep 2006, 00:20 ] |
| Post subject: | |
S.T.A.R.S™ wrote: krailord wrote: No matter what, it is impossible for VALVe to make the passwords serverside. It is possible to get the passwords at the moment, I have done it, S.T.A.R.S has done it, and I'm sure a few others. I think crismrulz doesn't think it is possible because he doesn't know how. right krailord... and please allow me to explain something that would lead to some kinda misunderstanding.. people think now of two server side issues... 1- one resposible for showing the password on the steam/cac/cas GUI. 2- second is that those Passwords are stored on servers, so thats why we say server side. so, again allow me to go little further... Chris thought of a much complicated procedure to approching revealing the password. and he thought we might been talking about sniffing or what so ever network-related stuff to be done in order to optain the passwords showen again on the same steam/cac/cas GUI. this is not true at all... as I said it doesnt need all this complicated shit. the cac passwords are stored on the servers of valve = server side the way we see passwords = not a server side at all, and actually has nothing to do with what we talking about here. it's just coded in the dll, and if you work around it, you just put it back to where it was before.. so no big deal... it's just a logic calling approche, and it worked out. and as I can see from what Chris wrote in hCUPa's Post: ChrisMRuLZ wrote: hCUPa, this is still getting it by decrypting the packets though isn't it? as far as i can see, there's still no way to do it the 'legit' way anymore as it's not placed in a control or anything.. I can tell that Chris seem to know nothing... "sorry chris" but what you just said there profes it buddy. you say: ChrisMRuLZ wrote: as far as i can see, there's still no way to do it the 'legit' way anymore as it's not placed in a control or anything.. you meant exactly and clearly what you said, because as you also said: for as far as you know... and you also said: NO WAY to do it the LEGIT way... sorry man, you're wrong... and please, I and many already knows that to change this whole thing compeletly "the login information sending" is like to have a new STEAM System. so no need for this to be the talking start point for explaining why you said: it's a SERVER SIDE... I hope you now understand it... and please, it doesnt always need some complicated stuff to work things out. sometimes it would only need a little txt file to assest. man, I'm out... When i posted it in here and in hCUPa's thread i was just going off what everyone else had said that "hCUPa's wasn't working anymore". by that i thought all it received was maybe a boolean '1' to say it had logged into an account server-side. a quick debugging of cacdll.dll did show some changes, and before there used to be a variable it was stored in, now i can't see anything where it is used locally. but obviously it is still there because i've tried hCUPa's old one and it still works. I was wrong. but i should have checked out what other people were saying instead of just trusting them. p.s. if you want you can delete the crap about server-side now it will probably just confuse people. and can you p.m. me atleast a hint? an offset? i don't like using the cracking methods, they can be easy to fix. i'm saving that stuff for the new client. the reason i made it the 'legit method' was so that i would have an advantage when it came to valve trying to fix it. they surprised me i'll admit.. i thought they would have a better way of screwing over all of there customers.. |
|
| Author: | cYCyIYoRDf [ Tuesday, 05 Sep 2006, 16:27 ] |
| Post subject: | |
can you make a tool for the acc, cause this which is version 1 doesn't work tey log only the username not the password |
|
| Author: | hCUPa [ Tuesday, 05 Sep 2006, 19:05 ] |
| Post subject: | |
ChrisMRuLZ wrote: When i posted it in here and in hCUPa's thread i was just going off what everyone else had said that "hCUPa's wasn't working anymore". by that i thought all it received was maybe a boolean '1' to say it had logged into an account server-side. a quick debugging of cacdll.dll did show some changes, and before there used to be a variable it was stored in, now i can't see anything where it is used locally. Sounds a bit like nonsense. This update changed nothing except that poor password editbox. Quote: and can you p.m. me atleast a hint? an offset? i don't like using the cracking methods, they can be easy to fix. i'm saving that stuff for the new client. Huh? What are other methods you know? Quote: the reason i made it the 'legit method' was so that i would have an advantage when it came to valve trying to fix it.
they surprised me i'll admit.. i thought they would have a better way of screwing over all of there customers.. I think this change does not affect legit customers at all. Only prevents people from using easy macros to get password. That's it. |
|
| Author: | ChrisMRuLZ [ Wednesday, 06 Sep 2006, 01:09 ] |
| Post subject: | |
hCUPa wrote: Sounds a bit like nonsense. This update changed nothing except that poor password editbox. well i pretty much explained what happened so i dont know why you dont get it.. oh well.. Quote: Huh? What are other methods you know? i know two other ones that are in my client.. and apparently stars knows one aswell. i guess your one just receives it before it starts doing the next packet so you dont have to deal with that.. Quote: I think this change does not affect legit customers at all. Only prevents people from using easy macros to get password. That's it.
it does. there was two functions that enabled CAC users to do things with the CAC account of there choice, to personalise it on the pc it was on etc.. my friend runs lans with CAC and he is pissed cos he liked to use 1 account across all instead of random logins. some of it is even documented in the cac stuff from steampowered.com. |
|
| Author: | hCUPa [ Wednesday, 06 Sep 2006, 07:54 ] |
| Post subject: | |
ChrisMRuLZ wrote: well i pretty much explained what happened so i dont know why you dont get it.. oh well.. Because you did not explain. Such explanations are best when they come with at least offsets or anything else that makes it clear you know what you are talking about. After your insights on "proper" MAC generation, "legit" account grabbing and now about mysterious "boolean variables" it is really hard to believe without. Quote: i guess your one just receives it before it starts doing the next packet so you dont have to deal with that.. Wrong. CAG is the one that does packets, CacLauncher does not do it. Quote: it does. there was two functions that enabled CAC users to do things with the CAC account of there choice, to personalise it on the pc it was on etc..
my friend runs lans with CAC and he is pissed cos he liked to use 1 account across all instead of random logins. some of it is even documented in the cac stuff from steampowered.com. I'm not talking about functions. Sure, they are missing. But from legit customer perspective it's all the same. Steam logon is completely transparent and it does not matter if one account is used or several. Why is your friend wanting to use one account? Any single reason this is better than random logins? |
|
| Author: | ChrisMRuLZ [ Thursday, 07 Sep 2006, 06:27 ] |
| Post subject: | |
1. i explained that i believed everyone else about all that stuff and assumed about the "boolean variables" etc.. didn't think it is that hard to understand.. people said yours wasn't working so i made assumptions about what valve had done without checking. legit means they couldn't stop it without removing the entire function, which they did. the proper mac generation is true.. s.t.a.r.s. and i both know you don't understand. macs are not just hexidecimal chars. even preselecting used manufacturers for the first 6 digits isn't going to get it done the best way. for one thing the mac needs to be generated the same way. it is NOT just random hex chars. it is an algorithm which i can show you. if you tell me what the encryption is for the CAC packets, i'l show you how the algorithm works. 2. thats what i was saying even in that quoted text. notice i said "receives it before it starts doing the next packet".. i'm saying isn't it a crack in the cacdll before it starts doing the packets etc..? 3. from a legit customers perspective it is different because the functions are missing. have you read the documentation from valve about CAC? my friend ran a lan and he liked to use the one account as he had a special setup using the functions CAC allowed (to use one account using command-line arguments). those functions are now gone. to some users it may be transparent.. if they didn't know how to or didn't need to use those functions. but just remember this is for cafes. they might like to have special setups based on the functions of the software. p.s. Why do you continue to talk with me about this stuff but you still haven't replied to my p.m. about the packet decryption?? |
|
| Author: | hCUPa [ Thursday, 07 Sep 2006, 08:55 ] |
| Post subject: | |
ChrisMRuLZ wrote: 1. i explained that i believed everyone else about all that stuff and assumed about the "boolean variables" etc.. didn't think it is that hard to understand.. people said yours wasn't working so i made assumptions about what valve had done without checking. legit means they couldn't stop it without removing the entire function, which they did. I was talking about "quick debugging of cacdll". Now you are saying it was all pure assumptions without checking. Make up your mind Quote: the proper mac generation is true.. s.t.a.r.s. and i both know you don't understand. macs are not just hexidecimal chars. even preselecting used manufacturers for the first 6 digits isn't going to get it done the best way. for one thing the mac needs to be generated the same way. it is NOT just random hex chars. it is an algorithm which i can show you. Yeh. You have already shown how to do it "properly". What surprises me is that you talk about some mysterious algorithm, while your implementation is in fact bad quality randomization over all six bytes of MAC address. Enough to keep user doing for years. Quote: if you tell me what the encryption is for the CAC packets, i'l show you how the algorithm works. I fail to see how MAC generation algorithm is related to username/password encryption. Quote: 2. thats what i was saying even in that quoted text. notice i said "receives it before it starts doing the next packet".. i'm saying isn't it a crack in the cacdll before it starts doing the packets etc..? No, it is not. Quote: 3. from a legit customers perspective it is different because the functions are missing. have you read the documentation from valve about CAC? my friend ran a lan and he liked to use the one account as he had a special setup using the functions CAC allowed (to use one account using command-line arguments). those functions are now gone. to some users it may be transparent.. if they didn't know how to or didn't need to use those functions. but just remember this is for cafes. they might like to have special setups based on the functions of the software. Main question not answered: why using single login is better than using normal CAC login? I don't see any single reason for that. And its not transparent to "some", users do not care how exactly logon to steam network is done as long as it is unattended and done properly. Quote: p.s. Why do you continue to talk with me about this stuff but you still haven't replied to my p.m. about the packet decryption??
I continue to talk because you are too often trying to "explain" things you have no clue about. |
|
| Author: | BosmouZ [ Thursday, 07 Sep 2006, 13:11 ] |
| Post subject: | |
@hCUPa were the fuck does ur thingysaves the thingys lol |
|
| Author: | The Death [ Friday, 08 Sep 2006, 02:53 ] |
| Post subject: | |
how i must use it right? should i use proxy? Because if i beginn to bruteforce mac's it does 4 mac's or something about that and than ip is banned i think. |
|
| Author: | cadexxx [ Friday, 08 Sep 2006, 03:17 ] |
| Post subject: | |
it was told before if you brutefore mac they ban your ip soo stop bruteforce that mac |
|
| Author: | aaaa [ Saturday, 09 Sep 2006, 00:18 ] |
| Post subject: | |
Hi, I can create accounts but in cacaccounts.txt dnont have any password. Why? plz help me sry 4 my english. iam from poland ; p |
|
| Author: | Mr.Deviance [ Saturday, 09 Sep 2006, 00:51 ] |
| Post subject: | |
aaaa wrote: Hi, I can create accounts but in cacaccounts.txt dnont have any password. Why? plz help me
sry 4 my english. iam from poland ; p You are not alloud to talk about this here! |
|
| Page 19 of 23 | All times are UTC + 3 hours |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|