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.

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

Crash on iPhone5/4s simulator caused by recursive function call #31

Open
draveness opened this issue Sep 1, 2016 · 5 comments
Open

Comments

@draveness
Copy link

draveness commented Sep 1, 2016

Recently, we are using fishhook to change some low-level function in linux/socket, but we met a quite strange bug. Use fishhook to rebind connect symbol to our new one leads to recursive call and ultimately crash on iPhone5/4s simulator specifically.

The code works totally fine on iPhone5s/6/6s and etc simulator and iPhone4s/iPhone5 device.

dae70ac2-6f22-4fd5-8c42-c9d5542d133b

Here is some info about my current MacBook and version of fishhook

  • OS X EI Captain 10.11.6
  • MacBook Pro (Retina 13-inch Early 2015)
  • Processor 2.7 GHz Intel Core i5
  • Memory 8 GB 1867 MHz DDR3
  • fishhook 0.2

You can find the ViewController.m file here which contains all the code in this project.

Plus, I don't know the reason for the problem. And I'm not the code are 100 percent safe on a real iOS device. Here are the thing and some idea I have tried to figure out this problem.

  1. I make a breakpoint to print all the symbols in all image files, and there of several dozens of connect symbol. fishhook changes implementation of each connect method
  2. This kind of crash only happens when hooks symbols which located in different images multiple times. And function like SSLWrite doesn't lead to this problem.

Thanks for your reading.

@draveness
Copy link
Author

Update: Crash on iPad 2 Simulator which is 32 bits. And works fine on other 64 bits simulator.

@draveness
Copy link
Author

It seems like when using fishhook to rebind symbols in all images on 32-bits simulator finally bind connect function to libsystem_sim_kernel.lib. And when using 64-bits finally bind to libsystem_kernel.dylib and the function imp of connect in libsystem_sim_kernel.lib may don't related to networking.

So when new_connect is being called, it doesn't return the correct result to the upper layer. This may lead to infinite looping problem.

I fixed this problem by using rebind_symbols_image function to change specific function imp in libsystem_network.dylib. Questions seem to be solved.

Only puzzle remains now, does the connect function in libsystem_kernel.dylib has the same function as which in libsystem_network.dylib, when using 64-bits simulator with rebind_symbols. Fishhook rebinds all the symbols in images and coincidently bind function in libsystem_kernel.dylib to our origianl_connect function pointer which has the same implementation. So all the code works fine?

I don't quite believe in fortune or coincidence. But really thanks feeding some info on this lib's usage.

👍

@kastiglione
Copy link
Contributor

The solution here may be to support for mach-o's two-level namespaces. When rebinding a symbol, fishhook should first check to see if that symbol refers to a specific library. If there is a specific library, fishhook should not rebind symbols of the same name that are bound to other libraries.

@kastiglione
Copy link
Contributor

kastiglione commented Sep 8, 2016

I don't know if helps the problem you're hitting, but I put up a pull request (#34) to support two-level namespaces. If there are multiple functions named connect as you suggest, then the new code would allow the rebinding of only symbols from a specified library.

@draveness
Copy link
Author

draveness commented Sep 8, 2016

I don't know that either. But after this pull request is merged, we will ship to the latest version of fishhook. But currently, we iterate all the images loaded by dyld and use regex to get the specific images by name. Ultimately use rebind_symbol_images method to solve this problem temporarily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants