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

Show consumed traffic amount? #7

Open
delebedev opened this issue May 6, 2015 · 7 comments
Open

Show consumed traffic amount? #7

delebedev opened this issue May 6, 2015 · 7 comments

Comments

@delebedev
Copy link

It would be really lovely to see amount of traffic for each app, or is it out of scope for Loading?

@BonzaiThePenguin
Copy link
Owner

Right now it's definitely outside the scope of the project, but at some point I agree it would be nice to have that information in there somewhere.

@ricardopereira
Copy link

+1

1 similar comment
@matiassingers
Copy link

👍

@BonzaiThePenguin
Copy link
Owner

:)

@dbkaplun
Copy link

I'm looking to implement similar functionality in a different project. Can you point me to resources regarding NetworkStatistics, reverse engineering advice, etc? Thanks in advance!

@BonzaiThePenguin
Copy link
Owner

NetworkStatistics is completely undocumented, but I used Hopper Disassembler and a ton of trial and error to find the right framework and function calls that I needed. Hopper can give you the function definition to a point, but it will say things like int when it's actually a Core Foundation class. For return types of int I think I called CFStringRef CFCopyDescription(CFTypeRef cf ) on them, at which point it would either crash (which tells me it's not a Core Foundation object) or it'd return something like "CFDictionary" which is even more helpful. I'd then use Hopper to find things that looked like constant declarations (_kNStatSrcKeyRxPackets), then I'd pass all of them in as keys into the dictionary to see what values they returned, if any.

@BonzaiThePenguin
Copy link
Owner

Inspecting the disassembled code for each function usually gives hints for what the parameters are supposed to be, like NStatManagerCreate has a line that copies a block so one of the arguments is probably a block, it uses dispatch queues so another argument is probably a queue, it uses the Core Foundation allocator so it probably needs a kCFAllocatorDefault argument, and so on.

For reverse-engineering data formats, you usually just use the app that generates the data to make known changes, then inspect the data in a hex editor and see what changed. If you change the rating for a song in iTunes from one star to two stars and one of the bytes in the file changes from 51 to 102, the rating is probably stored in that byte as rating * 51.

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

No branches or pull requests

5 participants