Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fixed memleaks and optimizations in my fork #387

Open
GermanAizek opened this issue Jan 12, 2025 · 3 comments
Open

Fixed memleaks and optimizations in my fork #387

GermanAizek opened this issue Jan 12, 2025 · 3 comments

Comments

@GermanAizek
Copy link

@rofl0r, im fixed in my fork this https://github.com/GermanAizek/reaver-wps-fork-t6x/

=================================================================
==119963==ERROR: LeakSanitizer: detected memory leaks
                                                                                                                                                                                                                  
Direct leak of 2423 byte(s) in 10 object(s) allocated from:
    #0 0x55754a4227f2 in calloc (/home/debian/GIT/reaver-wps-fork-t6x/src/reaver+0x807f2) (BuildId: d73d45a8f7672b631f021968770c751cc5fd3f17)                                                                     
    #1 0x55754a429de4 in build_eap_packet /home/debian/GIT/reaver-wps-fork-t6x/src/builder.c:355:9

Direct leak of 26 byte(s) in 1 object(s) allocated from:
    #0 0x55754a42256d in malloc (/home/debian/GIT/reaver-wps-fork-t6x/src/reaver+0x8056d) (BuildId: d73d45a8f7672b631f021968770c751cc5fd3f17)                                                                     
    #1 0x55754a426326 in set_ap_htcaps /home/debian/GIT/reaver-wps-fork-t6x/src/globule.c:547:20

Direct leak of 12 byte(s) in 12 object(s) allocated from:
    #0 0x55754a4227f2 in calloc (/home/debian/GIT/reaver-wps-fork-t6x/src/reaver+0x807f2) (BuildId: d73d45a8f7672b631f021968770c751cc5fd3f17)                                                                     
    #1 0x55754a42ebdc in get_wps_data_element /home/debian/GIT/reaver-wps-fork-t6x/src/libwps/libwps.c:467:35
    #2 0x55754a42ebdc in parse_wps_tags /home/debian/GIT/reaver-wps-fork-t6x/src/libwps/libwps.c:240:9
    #3 0x55754a42ebdc in parse_wps_parameters /home/debian/GIT/reaver-wps-fork-t6x/src/libwps/libwps.c:397:14

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x55754a42256d in malloc (/home/debian/GIT/reaver-wps-fork-t6x/src/reaver+0x8056d) (BuildId: d73d45a8f7672b631f021968770c751cc5fd3f17)                                                                     
    #1 0x55754a4263b0 in set_ap_rates /home/debian/GIT/reaver-wps-fork-t6x/src/globule.c:566:22

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x55754a42256d in malloc (/home/debian/GIT/reaver-wps-fork-t6x/src/reaver+0x8056d) (BuildId: d73d45a8f7672b631f021968770c751cc5fd3f17)                                                                     
    #1 0x55754a426440 in set_ap_ext_rates /home/debian/GIT/reaver-wps-fork-t6x/src/globule.c:588:26

Indirect leak of 2160 byte(s) in 6 object(s) allocated from:
    #0 0x55754a4227f2 in calloc (/home/debian/GIT/reaver-wps-fork-t6x/src/reaver+0x807f2) (BuildId: d73d45a8f7672b631f021968770c751cc5fd3f17)                                                                     
    #1 0x55754a426627 in initialize_wps_data /home/debian/GIT/reaver-wps-fork-t6x/src/init.c:69:17
    #2 0x530000000025  (<unknown module>)

Indirect leak of 912 byte(s) in 6 object(s) allocated from:
    #0 0x55754a4227f2 in calloc (/home/debian/GIT/reaver-wps-fork-t6x/src/reaver+0x807f2) (BuildId: d73d45a8f7672b631f021968770c751cc5fd3f17)                                                                     
    #1 0x55754a435344 in wps_registrar_init /home/debian/GIT/reaver-wps-fork-t6x/src/wps/wps_registrar.c:453:30
    #2 0x530000000025  (<unknown module>)

Indirect leak of 216 byte(s) in 3 object(s) allocated from:
    #0 0x55754a4227f2 in calloc (/home/debian/GIT/reaver-wps-fork-t6x/src/reaver+0x807f2) (BuildId: d73d45a8f7672b631f021968770c751cc5fd3f17)                                                                     
    #1 0x55754a435a02 in wps_registrar_add_pin /home/debian/GIT/reaver-wps-fork-t6x/src/wps/wps_registrar.c:524:6

Indirect leak of 24 byte(s) in 3 object(s) allocated from:
    #0 0x55754a42256d in malloc (/home/debian/GIT/reaver-wps-fork-t6x/src/reaver+0x8056d) (BuildId: d73d45a8f7672b631f021968770c751cc5fd3f17)                                                                     
    #1 0x55754a435a2f in wps_registrar_add_pin /home/debian/GIT/reaver-wps-fork-t6x/src/wps/wps_registrar.c:531:11

SUMMARY: LeakSanitizer: 5785 byte(s) leaked in 43 allocation(s).
@rofl0r
Copy link
Collaborator

rofl0r commented Jan 13, 2025

a "leak" is only real when there's no longer a pointer held to the actual storage. we allocate various things without explicitly freeing them, since they're automatically returned to the OS on exit. did you notice an actual leak that would steadily increase memory usage during execution, or are you just playing around with compiler options ?

@GermanAizek
Copy link
Author

a "leak" is only real when there's no longer a pointer held to the actual storage. we allocate various things without explicitly freeing them, since they're automatically returned to the OS on exit. did you notice an actual leak that would steadily increase memory usage during execution, or are you just playing around with compiler options ?

Hello again, in general, im run LeakSanitizer less than 30 seconds Online Brute WPS, I'm now measuring whether leakage increases over time (example 1 hour). I noticed that online brute is very long. In theory, 10 hours real time are needed for one AP, so I decided to optimize by reducing all timeout parameters. Also making Fail: and Timeout: 0, with router having an ideal signal 78db, I thought about how to optimize creation WPS and EAPOL sessions, structure alignment seemed to really speed up process exchanging Request, M1, M3,M5 messages, etc. On vanilla branch, I had 8 pins in 45 seconds, on my branch, 8 pins in 43 seconds, it seemed like a tiny error, but I decided to measure the average on one rtw8812 adapter with one driver.

I also tried to fix memory leaks, but I only broke original behavior, so I didn't push to my branch.

@rofl0r
Copy link
Collaborator

rofl0r commented Jan 13, 2025

I also tried to fix memory leaks, but I only broke original behavior

right, fixing what isn't broken is usually not that great of an idea

structure alignment seemed to really speed up process exchanging Request, M1, M3,M5 messages

i'm pretty sure your feeling is wrong because most time is spent waiting for responses, and in the active code doing syscalls and the kernel communicating with the driver firmware. if you want a speedy reaver maybe try adding -O3 to your CFLAGS, so reaver's code runs in 1ns instead of 2ns while the kernel spends milliseconds for the above. in reality, reaver could probably be written in python and a full brute-force session wouldn't take more than a few seconds longer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rofl0r @GermanAizek