Yes 4G on Linux is not a dream .. Part2

[Updates]
I was planning to write this post earlier but my workload piles up like a bad case (trainer/pentest/business proposal blax3) . But strange enough i have time to update myfacebook/twitter/kpop -addiciton instead of dwelling in codes. For that dear reader, i apologize. Disclaimer what i wrote is something I understand from base on my own observation it may be wrong or it may be right.


Remember previously I told that if we have the NSPID correctly the driver would work well? It turns out i`m wrong 720 degree . A fail is a fail but no doubt it helps me understand how wimax really work well. In brief if you really want to understand the whole procedure of a[ wimax network architecture read the tech spec from wimaxforum T31 , T32 , T33 .

In Brief


A Wimax Network Model Reference model courtesy of juniper

Let's move on to the technicality part of our Yes4g Dongle Specs:


now the driver for gctwimax 7205 is available on google codes. but the major problem is in the Wimax world every driver information is unique to it's NSP ... Any Wimax provider may use the same chipset but the logical information inside it for authentication may vary/diff from others.

Since the information that we have is just only the tech specs from wimaxforum and the current driver which is available at google code. So we dig inside our own Yes directory.




which actually contains a lot of useful information such as our NSPID , NAI, and everything else .

After we found our initial information , we try to understand how Yes4G Network Connectivity works by sniffing it. For this activity we were using Usblyzer to sniff it. A generic shortcut to usb sniffing ..

In: Data that the Device receive from buf
Out: Data that the Device send to buf

So we going to divide our sniffing from a working drivers into two segments . Initatializing Device, Network Authenthication.

Initialization Part1


So what actually happens when u lunch the Yes4G Connect Apps?
Attach here is the link a USB Sniffshot : http://www.mediafire.com/?vu2eae78lu4gaxy

In the buffer what happen initially .
The device will write to the buffer the code 03 12 00 06 01 01 00 00 . This is actually a code to call the device to start extracting the cert information into the device. Now the garbage data that u see that i have highlighted in red is actually the cert information to connect to the yes4G APN . the function call is define in protocol.c




But the actual extracting is being handle by wimax.c starting from line 773




After the certs have been extracted , now the buffer will be fill with 00 06 00 00 telling the device to turn on the RF Signal ON or in other words starts scanning this is define by protocol.c line 696..






After radio mode is turn on , config file will be read by nwsettings inside the Yes Application ( I think so) and the device will send a code into the buffer to search for the Yes Network.



Now that's number one issue overhere. If u refer to my previous post our Linux driver didn`t detected the Yes Network coverage. Now let's analyze why it cannot found in the first place.

What happens actually? http://www.mediafire.com/?qgduh3zmcwyco6a the gagal file..


Check at URB75 on both files we found out the buffer is slightly different


Notice the Sub1 string and the size of the buf is way too different between linux and win drivers.

to cut short the story What happen during the NAP Scanning is can be found in wimax.c line 815 the scan loop function




If u look at the code it try to fill the buffer with a function call fill_find_network_req which actually located at protocol.c line 755


SO u see the linux driver will fill the buffer wit this code

03 12 00 06 01 06 00 00 00 00  

where the 4th byte is actually the size of the parameter which is 6

If we look ath windows driver the size of the parameter is slightly larger which is 0C (12 in Dec)

01 0D 00 0C 02 D2 03 00 00 40 D4 04 53 75 62 31 

To proceed from here u have to options two hacks. Either wimax.c directly or fix the protocol.c . A quick non chalant hack is to fill the buffer value hardcodely inside wimax.c insitead of relying on protocol.c something like this.




We will continue with part 3 later on .. But for now the code will detect the network properly.