FPHG Version 2

[jukofyork]

Finally had some time today to implement the new hand-grabber code another 2+2er send me (he wishes to remain anonymous, but we have ALOT to thank him for!). The new method used in FPHG Version 2 is a huge improvement compared to the old FPHG code:

(1) Uses almost no CPU time.
(2) Never misses any hands (or hand endings).
(3) Has a simple GUI which minimizes to the system tray.
(4) I've packaged all the code using an installer, so it should be simpler for those who are not very computer literate (no more batch files, ect).

<u>RELEASE NOTES</u>

(A) All of the old V0.x options (such as '-o' and '-6max') have been removed due to the total re-write of the code. Alot of the old options are now redundant because of the new method, and the useful options will be added back after version 2 has been beta tested.

(B) I haven't as yet provided the source as I did for the old version. The reason I haven't done this is because it uses the same DLL injection techniques as Dollar2BB and PartyPopupBuster uses. These techniques can be abused, but overall I am leaning towards releasing the code for all three apps due to the fact I don't have a great deal of time, and by open-sourcing them others may be able to work on and improve the code.

(C) The main FPHG page has been updated with the new code, but just in case, I have also left both version 0.6b and version 0.7b up for the time being (in case some people can't get version 2 to work - it's beta at the moment...).

(D) Please make sure you don't block the DLL injection using ProcessGuard, as it needs to do this to function properly (just as Dollar2BB and PartyPopupBuster do).

(E) The hand histories are saved to a folder on the root of drive C: called 'C:\FPHG_HandHistories'. I know this is not ideal for some people, but it will be changed in the near future to save the hand histories to a sub-folder below the installation folder (eg: 'c:\program files\FreePHG\HandHistories\').

Please save this thread for posts related to problems, ideas and questions about <u>FPHG Version 2</u> ONLY. If the problem is related to PokerTracker not importing the hand histories, then the correct place to post those questions is in the PokerTracker forums or in the partner thread I have created here.

Juk [img]/images/graemlins/smile.gif[/img]

[_dave_]

Awesome work, seems good so far Juk (5 minute test lol)


I voted YES to source code, for two main reasons:

1) Evildoers will research DLL injection techniques of their own accord, not because they are published here. You learnt how to do it, after all? How could publishing your work prevent others from learning these methods?

2) Publishing of source code allows others to verify the legitimacy / security of this software. I MEAN NO INSULT. I DO NOT MEAN TO INDICATE THAT YOU MAY PUBLISH A KEYLOGGER, ETC. With your history of open publishing / GPL etc. I would hope you know by pointing this out I mean no untoward implications towards you and your software. Source code that can be user-compiled is an excellent way to verify the safe nature of an executable software.



Those who voted NO, pls explain your reasoning.


dave.

[PokerAce]

I voted no and I'll tell you why.

True software development is difficult. To know what you want to do and figure out all the details takes a great amount of time, dedication, skill and experience. The people who have these attributes are smart, intellegent people who are less likely to release something to our community that could cause problems. Simply because they know their time is better spent elsewhere.

Most "hacking" incidents are caused by script kiddies. These are hacker wannabes who know the bare basics of coding and can only do anything useful by cutting and pasting other people's code. These are the people who will take this code and write something malacious to be released.

DLL injection isn't an easy thing to code yourself from scratch. There's no reason to make it any easier for those who would use it to cause problems.

[CrashPat]

I would publish the code, it isn't like dll injection is some kind of secret. If somebody wanted to use it for malicious purposes all it takes is a quick google and there are multiple guides with sample code, etc.

Edit: If I remember right the Gametime+ code uses dll injection to grab hands from UB.

[yellowbluebus]

Juk,

Excellent job once again! Just in time for the Party reload bonus!

[rvg72]

[ QUOTE ]
I voted no and I'll tell you why.

True software development is difficult. To know what you want to do and figure out all the details takes a great amount of time, dedication, skill and experience. The people who have these attributes are smart, intellegent people who are less likely to release something to our community that could cause problems. Simply because they know their time is better spent elsewhere.

Most "hacking" incidents are caused by script kiddies. These are hacker wannabes who know the bare basics of coding and can only do anything useful by cutting and pasting other people's code. These are the people who will take this code and write something malacious to be released.

DLL injection isn't an easy thing to code yourself from scratch. There's no reason to make it any easier for those who would use it to cause problems.

[/ QUOTE ]

I voted no for basically the same reasons. Releasing it removes one or two potential barriers of entry for "evildoers"

rvg

[jukofyork]

[ QUOTE ]
I voted YES to source code, for two main reasons:

1) Evildoers will research DLL injection techniques of their own accord, not because they are published here. You learnt how to do it, after all? How could publishing your work prevent others from learning these methods?

2) Publishing of source code allows others to verify the legitimacy / security of this software. I MEAN NO INSULT. I DO NOT MEAN TO INDICATE THAT YOU MAY PUBLISH A KEYLOGGER, ETC. With your history of open publishing / GPL etc. I would hope you know by pointing this out I mean no untoward implications towards you and your software. Source code that can be user-compiled is an excellent way to verify the safe nature of an executable software.

[/ QUOTE ]

[ QUOTE ]
I voted no and I'll tell you why.

True software development is difficult. To know what you want to do and figure out all the details takes a great amount of time, dedication, skill and experience. The people who have these attributes are smart, intellegent people who are less likely to release something to our community that could cause problems. Simply because they know their time is better spent elsewhere.

Most "hacking" incidents are caused by script kiddies. These are hacker wannabes who know the bare basics of coding and can only do anything useful by cutting and pasting other people's code. These are the people who will take this code and write something malacious to be released.

DLL injection isn't an easy thing to code yourself from scratch. There's no reason to make it any easier for those who would use it to cause problems.

[/ QUOTE ]

[ QUOTE ]
I would publish the code, it isn't like dll injection is some kind of secret. If somebody wanted to use it for malicious purposes all it takes is a quick google and there are multiple guides with sample code, etc.

[/ QUOTE ]

It isn't so much that I want to stop people from learning how to use DLL injection and/or hooking API calls (although I do agree with Josh that implementing DLL injection is harder than it seems on the outset [of all the code snippets, libraries, etc available on the net... the majority of them do not work properly...]). The main worry I have is that I release the source and somebody makes a modified ("improved") version which they compile/package with a Trojan inside (not everybody can read the source, and many will just take the modified binary to be "OK" because it's related to the original project...).

To use these utils you have to agree to let the DLL be injected, and once a Dll has been injected into a target process, it can fairly easily bypass your firewall and allow malicious code to run in the target process (whereas normal non-DLL injecting code is much easier to verify that it isn't dialing out, etc).

I agree fully that releasing the source is much better overall for a number of reasons (transparency of code, learning from code snippets, improvement by another author, etc), and if it wasn't for the DLL injection part I would happily release the source for all three apps.

I think overall the best approach may be to try to create a sourceforge project (or failing that, something very similar), where only one or two trusted admins have the power to re-compile the binaries. This way at least many people can benefit from the source and at the same time it negate the likelihood of a malicious/modified version being released.

Juk [img]/images/graemlins/smile.gif[/img]

[jukofyork]

[ QUOTE ]
Juk,

Excellent job once again! Just in time for the Party reload bonus!

[/ QUOTE ]
NP, but I wish Party would offer me a reload! They been as tight as [censored] for the last 3/4 months with me! [img]/images/graemlins/frown.gif[/img]

Juk [img]/images/graemlins/smile.gif[/img]

[CrashPat]

A sourceforge/related project would be a good idea for a lot of reasons including version control, etc.

I didn't think about somebody modifying the code and releasing it as yours, or people assuming that it would be safe, which is a very valid concern.

I guess I did make it seem like dll injection is trivial and I suppose it would qualify as an advanced coding topic. And it is very difficult for somebody to learn enough just from reading the code to copy the idea if they do not have a solid background in software design.

[rvg72]

I guess I'm posting the first bug?

Fired up a set of 6 SNG's and ran FPHG 2 in the background. First 6 or 7 minutes were fine but then every 1 to 3 minutes one of the tables would stop having the hhf file updated until after about 25 minutes when none were recording to the hhf file. Once stopped they never begin recording again.

rvg