xfangfang / PPPwn_cpp

C++ rewrite of PPPwn (PlayStation 4 PPPoE RCE)
GNU General Public License v3.0
389 stars 57 forks source link

problem with WRT MikroTik RouterBOARD 941-2nD - STAGE 1: Memory corruption #56

Closed oubahell closed 4 months ago

oubahell commented 4 months ago

i am running on system type : Qualcomm Atheros QCA9533 ver 2 rev 0 machine : MikroTik RouterBOARD 941-2nD processor : 0 cpu model : MIPS 24Kc V7.4 BogoMIPS : 432.53 wait instruction : yes microsecond timers : yes tlb_entries : 16 extra interrupt vector : yes hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb] isa : mips1 mips2 mips32r1 mips32r2 ASEs implemented : mips16 shadow register sets : 1 kscratch registers : 0 package : 0 core : 0 VCED exceptions : not available VCEI exceptions : not available


problem is image

this is my run.sh config and i triend --real-sleep and --buffer-size 10240 but didnt work either, and i update the files with the latest pppwn_mips

#!/bin/sh

interface=$(sed -n '1p' /root/PPPwn_WRT-main/settings.cfg)
firmware=$(sed -n '2p' /root/PPPwn_WRT-main/settings.cfg)

# capture the output of uname -m
machine_arch=$(uname -m)

# choose script based on the architecture
if echo "$machine_arch" | grep -q "arch64"; then
    script_name="pppwn_arch64"
elif echo "$machine_arch" | grep -q "armv7"; then
    script_name="pppwn_armv7"
elif echo "$machine_arch" | grep -q "x86_64"; then
    script_name="pppwn_x86_64"
elif echo "$machine_arch" | grep -q "mips"; then
    script_name="pppwn_mips"
else
    echo "Unsupported architecture: $machine_arch"
    exit 1
fi

# kill any previous instance
/root/PPPwn_WRT-main/kill.sh

# Construct and execute the command with the chosen script
 echo "timer" > /sys/class/leds/rb:green:user/trigger
/root/PPPwn_WRT-main/${script_name} --interface $interface --fw $firmware --stage1 /root/PPPwn_WRT-main/stage1_$firmware.bin --stage2 /root/PPPwn_WRT-main/stage2_$firmware.bin --buffer-size 10240 --auto-retry
echo "none" > /sys/class/leds/rb:green:user/trigger
echo "default-on" > /sys/class/leds/rb:green:user/trigger
xfangfang commented 4 months ago

This is more like a problem with the system you are using than with pppwn_cpp. If there is enough memory, then unless the system restricts the creation of new threads, I don't know why threads cannot be created

Run the following content and send the output:

  1. cat /proc/1/limits
  2. cat /proc/sys/vm/max_map_count
  3. cat /proc/sys/kernel/threads-max
  4. ulimit -a
  5. free -m
xfangfang commented 4 months ago

And you can test this version, it won't crash when thread creation fails, as long as it is run with the --real-sleep option, it should be able to run normally.

https://github.com/xfangfang/PPPwn_cpp/actions/runs/9260818040 https://nightly.link/xfangfang/PPPwn_cpp/actions/runs/9260818040/mips-linux-musl.zip https://nightly.link/xfangfang/PPPwn_cpp/actions/runs/9260818040/mipsel-linux-musl.zip

If it still doesn't work, you can:

  1. update the system
  2. debug the problem yourself
  3. wait for a programmer with similar problems to debug

Without a real device, I can't provide more help.

3po3po commented 4 months ago

run 92608 I can confirm "--real-sleep" options help to do the job on t-plink 1043nd

3po3po commented 4 months ago

Output of the requested commands:

root@OpenWrt:~# cat /proc/1/limits

Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size 0 unlimited bytes Max open files 1024 4096 files Max address space unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 201 201 processes Max locked memory 65536 65536 bytes Max file locks unlimited unlimited locks Max pending signals 201 201 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us

root@OpenWrt:~# cat /proc/sys/vm/max_map_count 65530

root@OpenWrt:~# cat /proc/sys/kernel/threads-max 403

root@OpenWrt:~# ulimit -a -f: file size (blocks) unlimited -t: cpu time (seconds) unlimited -d: data seg size (kb) unlimited -s: stack size (kb) 8192 -c: core file size (blocks) 0 -m: resident set size (kb) unlimited -l: locked memory (kb) 64 -p: processes 201 -n: file descriptors 1024 -v: address space (kb) unlimited -w: locks unlimited -e: scheduling priority 0 -r: real-time priority 0 root@OpenWrt:~#

root@OpenWrt:~# free -m

          total        used        free      shared  buff/cache   available

Mem: 27080 11628 11052 80 4400 12976 Swap: 0 0 0 root@OpenWrt:~#

xfangfang commented 4 months ago

@3po3po

I feel that the problem is that the threads-max value in your system is too small, which prevents the creation of new threads. runs/9260818040 It simply ignores the error caused by thread creation, and by using --real-sleep, even without this additional thread, it will not affect the pppwn runs.

However, when you want pppwn_cpp to run in the background and enable web interface (which makes it easier to control) by using --web, you may encounter the same problem, and at this point, the problem cannot be avoided.

I think you need to adjust the settings or update the system.

For comparison, this is the output of my router:

root@OpenWrt:~# cat /proc/sys/kernel/threads-max
7956
3po3po commented 4 months ago

What it can be done to free additional memory from firewall ? How much we need additionally does further improvements in function can bring desired effect ? Or we can label workaround from smaller memory systems ?

SyderaLGaming commented 4 months ago

raducir texto con la cámara I have the same problem in the memory corruption process, Mikrotik rb941-2nd, openwrt 19.07

If there is anything I could do to help resolve the issue, please feel free to write to me.

excuse my english (google translator)

xfangfang commented 4 months ago

What it can be done to free additional memory from firewall ? How much we need additionally does further improvements in function can bring desired effect ? Or we can label workaround from smaller memory systems ?

I don’t think this is a problem related to memory.

xfangfang commented 4 months ago

I will close this issue because it is duplicate to https://github.com/xfangfang/PPPwn_cpp/issues/61