Accelerate3g5 -- blobb¶
Trying to come up with a fuzzing interface.
- André (email: firstname.lastname@example.org)
1) First setting up the femtocell and understand necessary basics of UMTS communication to do so. (done)
2) Collecting information e.g. slides, talks, docu about fuzzing of wireless protocols. (done)
3) craft requests and run fuzz tests against subscriber. (in progress)
Note: first time fuzzing.
TD1: Samsung Galaxy S5 Mini (G800F)
OS: Lineage OS (14.1/7.1.1)
TD2: LG Nexus 5 (hammerhead)
OS: Android Marshmallow (6.0)
TD3: HTC One M9
OS: Android Lollipop (5.1)
SIM: NanoSIM (cutted MicroSIM)
TD4: Samsung S3 (GT-I9300)
OS: Android Jelly Bean (4.3)
Pick up package at Sysmocom office.
Having an informative conversation with Neels about Jenkins, Docker and build artifacts.
Set up wiki page.
Seeing femtocell on network interface.
Compiled source as described, but couldn't configure/launch CN successfully (yet).
Next time will try Neels' launch script and same IP range.
2) Collecting input about fuzzing:
MobiDeke: Fuzzing the GSM Protocol Stack - S. Dudek & G. Delugr, hack.lu 2012
Base Jumping - Attacking the GSM BB and BTS - grugq, 2010
Fuzzing your GSM phone - Harald Welte, 26c3 2009
Fuzzing the Phone in your Phone - C. Miller & C. Mulliner, Blackhat 2009
Injecting SMS Messages into Smart Phones for Security Analysis - C. Mulliner, 2009
Security Testing esp. Fuzzing - E. Poll, ????
Resolving HLR issue and set correct IPs in *.cfg files.
hNodeB connects to hnbgw, but no UE is connecting to it.
[issue from wiki: ...unable to resolve DNS record look up of 0.ipaccess.pool.ntp.org... no trx].
Connect femtocell to LAN with internet access to resolve DNS record look up issue, still no phones are connecting (yet).
Adding SIM cards to hlr.db, after creating db successfully [thanks to andreas]
Create and attach build_3G.sh (adapted from build_2G.sh).
Rebuild with correct branch/tag (openbsc:vlr_3G,libosmo-sccp:old_sua).
TD1 and TD2 successfully connected to femtocell!!! \o/
Voice calls work (TD1<->TD2).
Create and attach configure_nano3G.exp.
Invoke expect script within run.sh to automate initial nano3G configuration via telnet.
SMS work (TD1<->TD2), probably worked before but have been tested "today".
Compile OpenBSC with --enable-mgcp-transcoding flag and create 127.0.0.2 on lo. :)
Attach refactored version of build_3G.sh.
Data "works" (TD1<->TD2, TDx<->tun0/192.168.42.1
Note: data "worked" before (UEs got IP 2017-4-20). But I didn't manage to forward packets from tun0->eth0->inet yet, although the following iptable rule has been applied:
sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Create and attach find_nano3G.sh.
Picked up TD4 at a friend's place. Now I don't need to change the SIM/USIM card in TD1, which is my "normal" cell phone to test functionality. Thanks a lot buddy :)
As it actually belongs to the accelerate3g5 project, I add the hands-on repo this journal.
It provides functionality to clone necessary git repos and build accerelate3g5 CN stack.
Test MMS, doesn't work.
I'd changed MCC and MNC from the wiki-default values (MCC=901, MNC=98) to MCC=809 and MNC=90 on the hNodeB (telnet) to align with SIM-cards' IMSIs and avoid roaming, but it didn't work out (yet).
Set csgAccessMode to CSG_ACCESS_MODE_CLOSED_ACCESS to avoid interfering with UEs now owned by me.
Set additional ip table rule. UE's have finally internet connection. \o/
sudo iptables -t nat -A POSTROUTING -o lo -j MASQUERADE
UEs are not roaming anymore \o/. Actually the explanation of a friend how the MCC and MNC has to be set according to the IMSI (0-2 MCC, 3-4 MNC digits) was correct,
but I didn't read the IMSI correctly from the "sysmocom full-size SIM card". Such IMSIs on the full-size SIM card consist of 18 digits.
After using IMSIs from delivery e-mail (which are 15 digits long and not 18 as full-size-SIM-card-IMSI) it works.
Moreover, I now know that the IMSI can ONLY hold 15 digits and consists of MCC (3), MNC (2-3) and MSIN (9-10).
A poor/manual stability test for the entire UMTS network has been successful for 12 hours ((DL: 7,8-5,9, UL: 1,2-0,8) Mbit/s and ping: 170-150 ms).
system is only mounted as read-only, but as usual the following command changes this behavior to rw:
mount -o remount,rw /
Change ssh_banner (just for fun):
Changing thttp port to 80 and show own index.html (just for fun).
Entire network still works fine, when thttpd port changed to 80.
Thinking about installing python and scapy on the hNodeB to see whether we could fuzz directly on the imq0-15 interfaces as they might represent UL+DL connections of UEs.
(nano3G S8 can serve up to 8 clients -> 8*(UL+DL) = 16 interfaces)
First problem we only have ~ 20 MB storage left for python and scapy, which are around 70 MB and we cannot use ipkg to install anything as the repository servers are not available.
Storage problem can be solved by creating a ramdisk. I've create a 70 MB ramdisk and verified whether the entire network still works.
Yes it does, although only 2.4 MB RAM was left and 2 UEs have been connected.
Copying Python binaries and dependent libs (libssl.so.1.0.0,...) from a RaspberryPi Model A, because they use same processor/architecture.
After all dependencies have been copied via ssh, python still doesn't run, showing some "GLIBS_VERSION" error, so I tried to replace libc.so.6 with the one on the RasPi too.
This was a huge mistake, which showed me that I am missing system level and C knowledge, because some google research (afterwards) proofed that replacing libc.so.6 is a very, very bad idea.
After replacing libc.so.6 any executed command resulted in -> "Illegal Instruction - Core Dumped"... :S
I did it a "Factory Reset", but it seems to only reset AP configuration settings or might be damaged as well in fact of the libc.so.6 change.
The hNodeB still gets an IP from the DHCP server and one can ping it. But no ports are open anymore, thus I cannot connect at all. :/
It seems that I really have bricked the hNodeB... -.-"
A friend supported me (thanks!) with his experience and equipment to see whether any Serial or JTAG interface might still works, so we may could change the wrong symlink.
The following pictures show results of our probing (SK1, PL1, PL2, PL3, J1 and J4):
Unfortunately we didn't find any Serial connection, although some pins indicated some sort of communication.
Furthermore the used Spansion S29GL-512P10FFCR2 flash is BGA and not TSOP (datasheet). So a try to unsolder and fix tehe flash as described in Reverse Engineering Flash memory for Fun and Benefit could not be applied.
Thinking about buying a BGA64 test socket in order to desolder and fix the Spansion flash.
But first buying a S29GL512P10FFCR2 (LAA064), a S29GL512P10TFCR2 (TSO56) an a TSOP56 test socket - which is much cheaper than the BGA64-test socket - to play around with such flash type before doing anything with/on the hNodeB.
- UE's are connecting. Voice calls + SMS + data are working and UEs are not roaming. =)
- Never ever mess around libc.so.6 :/