i finally finished checkrevision code in vb, and my bot now relies on no non-system/vb runtime dlls! yay!
the only problem is that, unless i compile the bot, it takes fuckin' forever to do checkrevision -- upwards of 2000ms -- while the debugger is active. anybody know any way to speed that up?

ooh yeah, and does anybody know a way to get rid of overflow checks in vb, if it's possible? it takes a lot of needless cpu power to convert to a double and add/subtract until it's acceptable to convert back to a long :|

why on earth would you convert checkrevision to vb?!

because people like to try new things, or do things differently to gain more knowledge...

why reinvent the wheel? especially when your turning it from a circle, to a square

lol ;D that's a good quote btw...

i'm not turning a circle in to a square, i'm turning a cricle in to a trampy purple wheel with seven nipple tassles. and i did it because i dont want to have to send dlls with every release of my bot, and because i had nothing better to do at the time. right now i'm working on odbc support so that i can have my bot use an sql database and all of that great stuff that leads to web channel display without creepy vl people pouncing on my cd key and password :P. i'm also making it more scriptable than it needs to be, just so i can say i did it. when i'm done, the bot will probably not be able to connect to battle.net at all without script.txt ;D

i just made that up ^_^!

camel, whats the point of a bot then? you should make it work perfectly. THEN add script.txt

[quote]does anybody know a way to get rid of overflow checks in vb[/quote]

Correct me if I'm wrong, but you can turn integer overflow checks off in the Project Properties dialog on the Compile tab, under Advanced Optimizations.

P.S.. The vL people are only creepy at night, when it's dark outside... *lightning flash*

Edit: Minor grammatical error

[quote author=Camel link=board=17;threadid=992;start=0#msg7361 date=1049854881]
i finally finished checkrevision code in vb, and my bot now relies on no non-system/vb runtime dlls! yay!
the only problem is that, unless i compile the bot, it takes fuckin' forever to do checkrevision -- upwards of 2000ms -- while the debugger is active. anybody know any way to speed that up?

ooh yeah, and does anybody know a way to get rid of overflow checks in vb, if it's possible? it takes a lot of needless cpu power to convert to a double and add/subtract until it's acceptable to convert back to a long :|
[/quote]I wouldn't hope for too much when running CheckRevision from VB. Even written in conventional pure C, CheckRevision is far too slow (upwards of 250ms to run on Starcraft, and far far longer to run on, say, Warcraft III). It takes a pretty creative approach to achieve a decent execution speed (i.e. as fast or faster then Blizzard's versions, which run the above check in more like 10-15ms).

[quote author=Camel link=board=17;threadid=992;start=0#msg7375 date=1049862002]
i did it because i dont want to have to send dlls with every release of my bot, and because i had nothing better to do at the time. right now i'm working on odbc support so that i can have my bot use an sql database and all of that great stuff that leads to web channel display without creepy vl people pouncing on my cd key and password :P.[/quote]

This is just plain wrong on several issues. First, you could use BNLS to avoid sending the DLLs out (and BNLS runs the checks very quickly compared to what you'll achieve in VB). Second, we've never pounced on any cdkeys or passwords. Third, even if you don't take my word on the safety of vL products, you could use the webchannel interface. All you need is a WebChannel-compliant client (i.e. botnet client with whisper sending capability) and to be on the WebChannel accesslist. It's an open spec that anyone can implement.

[quote author=Camel link=board=17;threadid=992;start=0#msg7375 date=1049862002]without creepy vl people pouncing on my cd key and password :P[/quote]

Despite hundreds of thousands of BNLS usages, can you name a single instance of Skywing using BNLS to steal someone's cdkey or password? No? Maybe there's a good reason for that.

[quote author=Stealth link=board=17;threadid=992;start=0#msg7378 date=1049862441]
you can turn integer overflow checks off in the Project Properties dialog on the Compile tab, under Advanced Optimizations.[/quote]
i meant while the debugger is running...that only takes effect post-compile

skywing, i'm quite aware of the real-time-speed issue. it's not *that* hard to time how long it takes to run the checkrevision and cheat 0x25 by that much...
right now, my checkrevision() runs in ~20-30ms post-compile, taking in to account my functions on _every_ add/subtract operation that converts to double to prevent overflows. i suppose i should #if..#endif those out...

[color=red] * Camel was being facetious about cd key and passwords[/color] ::)

[quote author=Camel link=board=17;threadid=992;start=0#msg7396 date=1049892973]
[quote author=Stealth link=board=17;threadid=992;start=0#msg7378 date=1049862441]
you can turn integer overflow checks off in the Project Properties dialog on the Compile tab, under Advanced Optimizations.[/quote]
i meant while the debugger is running...that only takes effect post-compile

skywing, i'm quite aware of the real-time-speed issue. it's not *that* hard to time how long it takes to run the checkrevision and cheat 0x25 by that much...
right now, my checkrevision() runs in ~20-30ms post-compile, taking in to account my functions on _every_ add/subtract operation that converts to double to prevent overflows. i suppose i should #if..#endif those out...

[color=red] * Camel was being facetious about cd key and passwords[/color] ::)
[/quote]Trying to cheat SID_PING will result in you getting IP-banned now, btw.

You also have to take in to account computer speed when benchmarking these of course - the number I gave were for a 450MHz P3 - if your system is fast enough, I suppose it doesn't matter if your CheckRevision isn't extremely efficient, though at the time Blizzard designed it, efficiency was a necessity (this would have been in 1997).

Some people (like me) would rather do stuff the hard way :-)

well actually, i just realized that i dont need to spoof ping at all: DoEvents will make the socket send it's buffer. since 0x25 comes before 0x51, the ping is not affected. sure, it slows down login a little, but who the fuck cares? on my computer (AMD 2100+, 1.73GHz) it takes only about 250ms. imho, that's a small price to pay for 1) bragging rights and 2) not having to explain to all the newbie/idiots how to get bnetauth.dll and where to put it because they were too stupid to extract everything from the zip file...

[quote author=Camel link=board=17;threadid=992;start=0#msg7429 date=1049939833]
well actually, i just realized that i dont need to spoof ping at all: DoEvents will make the socket send it's buffer. since 0x25 comes before 0x51, the ping is not affected. sure, it slows down login a little, but who the fuck cares? on my computer (AMD 2100+, 1.73GHz) it takes only about 250ms. imho, that's a small price to pay for 1) bragging rights and 2) not having to explain to all the newbie/idiots how to get bnetauth.dll and where to put it because they were too stupid to extract everything from the zip file...
[/quote]I'd argue that efficiency is a much better reason for bragging rights :p

If your users don't know where to put things, perhaps you should consider using an installation program so that they don't have to know where stuff is supposed to go. Windows Installer (MSI) has the advantage of the nice 'repair' option, which basically reinstalls the whole thing without asking the user for their setup informaton again - rather useful if they've managed to delete a dependant library or such.

While you might be right about a slow CheckRevision not impacting the ping time of a single connection, what if you later decide to implement support for multiple connections? Or even run multiple instances of the same program? All those wasted CPU cycles do add up - something to think about.

definately worthy of contemplation, but my bot was designed as an ops bot. i have no reason to support mass loading bots, and 2 or 3 instances of the bot wont really add up to much because it only takes time during connect--the function is only called once for 0x51

MSI is terrible. If it breaks, everything else breaks with it.

[quote author=St0rm.iD link=board=17;threadid=992;start=15#msg7480 date=1050003022]
MSI is terrible. If it breaks, everything else breaks with it.
[/quote]
That made no sense. If the installer is corrupted then, yes, it wouldn't work.

Actually, St0rm is right.

Try to annoy MS Office 2000. Then you'll see the fury of MSI unleashed.

He could always use machine code and still have the advantages of an independent package with a _little_ less overhead than a full visual basic implementation perhaps?

[quote author=TheMinistered link=board=17;threadid=992;start=15#msg7529 date=1050031666]
He could always use machine code and still have the advantages of an independent package with a _little_ less overhead than a full visual basic implementation perhaps?
[/quote]And how exactly do you plan on doing this with VB? Using CallWindowProc, something which is not guaranteed to work and likely to break on future platforms?

[quote author=Yoni link=board=17;threadid=992;start=15#msg7528 date=1050031656]
Actually, St0rm is right.

Try to annoy MS Office 2000. Then you'll see the fury of MSI unleashed.
[/quote]MS Office 2000's screwed itself up many times for me, but I've seen countless damaged Office installs and never seen one which took the rest of MSI with it.

[quote author=Yoni link=board=17;threadid=992;start=15#msg7528 date=1050031656]
Actually, St0rm is right.

Try to annoy MS Office 2000. Then you'll see the fury of MSI unleashed.
[/quote]

If MSI is that messed up, turn it off through MMC.

HOW!!?!?!@^#$^(!?

[quote author=St0rm.iD link=board=17;threadid=992;start=15#msg7607 date=1050100827]
HOW!!?!?!@^#$^(!?
[/quote]

From Windows 2000 Help (this took about 5 seconds to find via the index):
[quote]Managing options for computers through Group Policy
Windows Installer can be configured using Group Policy and Active Directory to manage the computer installation options.

The following table shows policies concerned with managing the Group Policy computer options for Windows Installer. To configure these policies, start Group Policy as described in Start the Group Policy snap-in. Next, in the console tree, click the Windows Installer node.

Where?

applicable policy name
Computer Configuration
Administrative Templates
Windows Installer
Policy Details
Disable Windows Installer Disables or restricts the use of Windows Installer.
This policy can prevent users from installing software on their system or permit users to install only those programs offered by an administrator.

If you enable this policy, you can use the options in the Disable Windows Installer box to establish an installation policy.

Never
Windows Installer is fully enabled. Users can install and upgrade software. Windows Installer is enabled by default in Windows 2000.
For non-managed apps only
Users can install only those programs that an administrator assigns (offers on the desktop) or publishes (adds to Add/Remove programs).
Always
Windows Installer is disabled.
Note

This policy affects Windows Installer only. It does not prevent users from using other methods to install and upgrade programs.

Always install with elevated privileges Windows Installer uses system permissions when it installs any program on the system.
This policy extends to all programs the elevated privileges usually reserved for programs that have been assigned to the user (offered on the desktop) or the computer (installed automatically), or made available in Add/Remove Programs in Control Panel. This policy lets users install programs that require access to directories that the user might not have permission to view or change, including directories on highly restricted computers.

If you disable this policy, or do not configure it, the system applies the current user's permissions when it installs programs that are not distributed or offered by an administrator.

Note

This policy appears both in the Computer Configuration and User Configuration folders. To make this policy effective, you must enable the policy in both folders.

Disable browse dialog box for new source Prevents users from searching for installation files when adding features or components to an installed program.
This policy disables the Browse button beside the Use feature from list in the Windows Installer dialog box. As a result, users must select an installation file source from the Use features from list configured by the administrator.

This policy applies even when the installation is running in the user's security context.

If you disable this policy or do not configure it, the Browse button is enabled when an installation is running in the user's security context, but only administrators can browse when an installation is running with elevated system privileges, such as installations offered on the desktop or in Add/Remove Programs.

This policy affects Windows Installer only. It does not prevent users from using other browsers, such Windows Explorer or My Network Places, to search for installation files.

Disable patching Prevents users from installing patches to upgrade their programs.
Patches are updates or upgrades that replace only those program files that have changed. Because patches can be easy vehicles for malicious programs, some installations prohibit their use.

This policy applies only to installations that run in the user's security context. By default, users who are not administrators cannot apply patches to installations that run with elevated system privileges, such as those offered on the desktop or in Add/Remove Programs.

Disable IE security prompt for Windows Installer scripts Allows Web-based programs to install software on the computer without notifying the user.
By default, when a script hosted by an Internet browser attempts to install a program on the system, the system warns the user and allows him or her to select or refuse the installation. This policy suppresses the warning and allows the installation to proceed.

This policy is designed for enterprises that use Web-based tools to distribute programs to their employees. However, because it might pose a security risk, it should be applied cautiously.

Enable user control over installs Permits users to change installation options that typically are available only to administrators.

This policy bypasses some of the security features of Windows Installer. It permits installations to complete that otherwise would be halted due to a security violation.

The security features of Windows Installer prevent users from changing installation options that are typically reserved for administrators, such as specifying the directory to which files are installed. If Windows Installer detects that an installation package has permitted the user to change a protected option, it stops the installation and displays an error message. These security features operate only when the installation program is running in a privileged security context in which it has access to directories that are denied to the user.

This policy is designed for less restrictive environments. It can be used to circumvent errors in an installation program that prevent software from being installed.

Logging
Enter one or more of the following installation log mode options:

[i][w][e][a][r][u][c][m][p][v][o]
Specifies the types of events that Windows Installer records in its transaction log for each installation. The log, Msi.log, appears in the Temp directory of the system volume.
When you enable this policy, you can specify the types of events you want Windows Installer to record. To indicate that an event type is recorded, enter the letter representing the event type. You can enter the letters in any order and list as many or as few event types as you want. To disable logging, delete all of the letters from the box.

The Windows Installer logging options are as follows:

Mode Log entry
i Status messages
w Non-fatal warnings
e All error messages
a Startup of actions
r Action-specific records
u User requests
c Initial user interface parameters
m Out-of-memory
p Terminal properties
v Verbose output
o Out of disk space messages

Notes

If you disable this policy, or do not configure it, Windows Installer logs the default event types, represented by the letters iweap.
You can include all possible events in the installation log file by entering iwearucmpvo. However, doing so will add considerable time to the installation process. [/quote]

But real hackers don't ever read the documentation, right, $t0rm? ;)

There is another method other than using CallWindowProc which works.

[quote author=TheMinistered link=board=17;threadid=992;start=15#msg7614 date=1050102957]
There is another method other than using CallWindowProc which works.
[/quote]Feel free to elaborate on it, then, especially if you're suggesting people use machine code from VB!

Thank you kindly.
BTW, I never used the windows help, thanx.

[quote author=St0rm.iD link=board=17;threadid=992;start=15#msg7617 date=1050104054]
Thank you kindly.
BTW, I never used the windows help, thanx.
[/quote]As I finished explaining to Yoni, it's actually got some useful information you probably didn't know - enough that he decided to re-add it to his Start menu, anyway :p

Amazingly enough, the Windows help actually has useful information. I guess I was used to Win98, where there is no useful information (and no useful commandline tools, either!) in the Windows help, which was probably the reason I removed Help from the start menu (using TweakUI) in the first place. (I originally installed Win2k over Win98.)

For those of you who don't want to spend the 2-3 minutes I spent looking for the actual help file, it's %SYSTEMROOT%\Help\Windows.chm.