Question: can this tool be used with UERANSIM?

[andreaterni7]

Hello @Matheus-Garbelini and everyone! I am using your tool in Ubuntu 20.04 and I wanted to know if your tool can only be used with the suggested setup or can it also be used in a simulated environment e.g. using UERANSIM to simulate both gNodeB and UE?

Waiting for a reply, best regards.

[Matheus-Garbelini]

Hi @andreaterni7, not exactly as UERANSIM completely bypasses the 5G data link (MAC, RLC, PDCP) generation that OpenAirInterface handles. However, I've pushed a commit which explains how to use 5Ghoul PoC in simulator mode (implemented by OpenAirInterface): https://github.com/asset-group/5ghoul-5g-nr-attacks?tab=readme-ov-file#21-simulation-testing-5ghoul-without-sdr

This would allow you to simulate both the UE and gNB without requiring SDR. In short, you can run the command: sudo bin/5g_fuzzer --EnableSimulator=true --EnableMutation=false --GlobalTimeout=false

Note that this is mostly an RF simulation which is experimental and as such the UE cannot finalize the NAS Authentication procedure without Open5GS rejecting the UE.

[shuimoshusheng]

@Matheus-Garbelini Hello, is the modification of this fuzz before or after the n1/n2 signaling encoding? According to the packet capture file, the injected error values are only in the case of full hexadecimal 1 or full hexadecimal 0? Also, is this packet capture file capturing the protocol stack packets of Openairinterface5g or the logs of the mobile baseband chip? thanks！

[Matheus-Garbelini]

Hello, is the modification of this fuzz before or after the n1/n2 signaling encoding?

Hi @shuimoshusheng assuming a downlink direction (core to UE), the fuzz applies the modification after n1/n2 sctp encoding, before over-the-air MAC data link transmission. It does so by modifying the raw Physical Data Shared Channel PDSCH transport block bytes.

According to the packet capture file, the injected error values are only in the case of full hexadecimal 1 or full hexadecimal 0?

Not sure if I fully understand your question. The exploits introduce specific values at raw byte offsets that are not necessary 0xFF or 0x00. This is exemplified in the User Exploit Script Example: https://github.com/asset-group/5ghoul-5g-nr-attacks?tab=readme-ov-file#42-example-macrlc-crash-c-script

In the case of the Invalid MAC RLC PDU DoS , 2 bytes are modified of the downlink transport block:

pkt_buf[60 - 48] = 0xB5; // Modify raw packet at offset 12
pkt_buf[61 - 48] = 0x02; // Modify raw packet at offset 13

Therefore bytes 0xB5 and 0x02 correspond to RLC sequence numbers being altered from the original message (shown in the wireshark capture here).

Normally other attacks might inject values that will corrupt the structure of the ASN.1 payload to the point of many optional bits set to either 1/0 or other information element (IEs) fields being null or set to other integer numbers.

Also, is this packet capture file capturing the protocol stack packets of Openairinterface5g or the logs of the mobile baseband chip?

The capture file shows the over-the-air packets received or transmitted from Openairinterface5g (OAI) protocol stack as you have 1st pointed. More specifically, the capture file is collected at the data link handler of OAI (transport blocks channels) via the interception API as illustrated here: https://github.com/asset-group/5ghoul-5g-nr-attacks?tab=readme-ov-file#4--create-your-own-5g-exploits-test-cases

Let me know if this clarifies your questions.

[shuimoshusheng]

@Matheus-Garbelini I'm very sorry for replying now. I probably understand it, but I need to look at the code of the processing process to become familiar with these operations. Thank you for your detailed explanation. Thank you.🤝