MavproxyUser
-
Posts
65 -
Joined
-
Last visited
-
Days Won
1
Everything posted by MavproxyUser
-
Ok folks... word on the street is that DJI is pulling firmware. Please start uploading your archived firmware to GoogleDrive and linking here or in slack https://dji-rev.slack.com #firm_cache on OSX /Applications/Assistant.app/Contents/MacOS/Data/firm_cache or on Windows C:\Program Files (x86)\DJI Product\DJI Assistant 2\Assistant\Data\firm_cache Please archive all contents such as: wm220_0100_v02.01.55.93_20170120.pro.fw.sig wm220_0100_v02.02.56.29_20170317.pro.fw.sig wm220_0100_v02.05.04.34_20170209_ca02.pro.fw.sig wm220_0100_v02.06.04.84_20170324_ca02.pro.fw.sig wm220_0101_v02.01.55.93_20170120.pro.fw.sig wm220_0101_v02.02.56.29_20170317.pro.fw.sig wm220_0101_v02.05.04.34_20170209_ca02.pro.fw.sig wm220_0101_v02.06.04.84_20170324_ca02.pro.fw.sig wm220_0305_v34.04.00.23_20161122.pro.fw.sig wm220_0306_v03.02.13.16_20170112.pro.fw.sig wm220_0306_v03.02.30.13_20170405.pro.fw.sig wm220_0400_v01.50.11.93_20170116.pro.fw.sig wm220_0400_v01.50.12.01_20170414.pro.fw.sig wm220_0600_v00.00.01.27_20161017.pro.fw.sig wm220_0601_v00.00.03.04_20170329.pro.fw.sig wm220_0603_v00.00.06.07_20170314.pro.fw.sig wm220_0801_v01.04.17.03_20170120.pro.fw.sig wm220_0801_v01.05.00.20_20170331.pro.fw.sig wm220_0802_v01.00.03.08_20170116.pro.fw.sig wm220_0803_v00.00.04.06_20160621.pro.fw.sig wm220_0803_v00.00.04.08_20170314.pro.fw.sig wm220_0804_v01.00.00.08_20170113.pro.fw.sig wm220_0805_v01.01.00.71_20161227.pro.fw.sig wm220_0805_v01.01.00.87_20170427.pro.fw.sig wm220_0905_v00.00.01.04_20170301.pro.fw.sig wm220_0907_v43.97.02.05_20170111.pro.fw.sig wm220_0907_v47.26.02.11_20170419.pro.fw.sig wm220_1100_v01.00.07.24_20161206.pro.fw.sig wm220_1200_v01.09.00.00_20161204.pro.fw.sig wm220_1201_v01.09.00.00_20161204.pro.fw.sig wm220_1202_v01.09.00.00_20161204.pro.fw.sig wm220_1203_v01.09.00.00_20161204.pro.fw.sig wm220_1301_v01.04.17.03_20170120.pro.fw.sig wm220_1301_v01.05.00.23_20170418.pro.fw.sig wm220_1407_v43.97.02.05_20170111.pro.fw.sig wm220_1407_v47.26.02.11_20170419.pro.fw.sig wm220_2801_v01.02.21.01_20170421.pro.fw.sig wm220_2803_v00.00.03.08_20170302_cd01.pro.fw.sig wm220_2803_v00.00.03.08_20170302_cd02.pro.fw.sig wm220_2807_v47.26.02.11_20170419.pro.fw.sig
-
Looks like the cat is out of the bag btw... https://github.com/mefistotelis/phantom-firmware-tools/issues/32#issuecomment-311488395
-
For those of you that are more active... stop by and see us in slack. Don't come ask dumb questions! Stop by with the mindset of participation. https://join.slack.com/dji-rev/shared_invite/MjA0NTE3MzM5NjM0LTE0OTg1OTc5MjUtNzE0NWM3ODI5OQ
-
I don't think many folks have quite gotten there yet Nick. can you tell us more about this? Is there a fix on p3 ? We can likely find an analog in the config options. Did you by chance get video, or have the logs from the flight of it occurring? That would be interesting. You of course saw this already via GitHub comments.
-
BTW... I assume you all saw the Ground Control Station?
-
Yes... see my recent post above.
-
That could be version specific... they should NOT be read-only, you should have the ability to readily change them. There is however a specific subset that Are marked read only.
-
Clever trick! That may be useful for the "Preserve log" functionality alone.
-
I'm loving that people are following the trail of bread crumbs... *hat tip*. At this point in the game I suspect quite a bit of the "dir traversal" on the FTPD was a red herring. In reality I think the "traversal" is the mere fact that the ftpd root is "/data" on the drone. There are a number of scripts that call things from "/data". It is *possible* that early versions of the ftpd allowed the placing of a symlink, OR that somehow you could trigger a .zip or .tar file to be unpacked with a symlink contained within. Think of the NFZ db as it gets pushed, I forget the filename but it is like data_transfer.tar or something. I've only seen ONE instance of a symlink depicted on the ftpd server... but I can't for the life of me figure how it got there. Note the "~" in the picture... http://kvadrik.blogspot.com/2017/03/dji-mavic-pro-500.html Really, the ONLY way this is possible is if DJI was stupid when they modified the Busybox source code and some how introduced it. It is also possible that the original factory firmware used a really old vulnerable version of Busybox, but that doesn't fully explain the behavior. P0V's original words were "Mavic it's restricted to '/ftp' directory. Luckily, there are underground 0day exploits for FTPD for path traversal. I can confirm that you can traverse out of the '/ftp' directory and reach the init scripts to set debug flag". I am not entirely convinced this isn't where the red herring lays, but I suspect so. https://www.rcgroups.com/forums/showthread.php?2747762-Official-DJI-Mavic-***Owner-and-Developer-sThread***/page1008#post36232471 I think the best hint here is to study the words in the old P3 paper: "Unfortunately, on the latest firmware (V01.07.0090), the root ftp access to the drone is chrooted and I wasn’t able to escape the /tmp directory" https://voidsec.com/hacking-dji-phantom-3/ I did note specifically "Port 21 is running vsFTPd 3.0.2 which as of the time of this writing, only has one minor known vulnerability" https://courses.csail.mit.edu/6.857/2016/files/9.pdf "Unspecified vulnerability in vsftp 3.0.2 and earlier allows remote attackers to bypass access restrictions via unknown vectors, related to deny_file parsing." https://bugzilla.redhat.com/show_bug.cgi?id=1187041 So in theory... it is possible at one time they used Vsftpd instead of Busybox ftpd on the Mavic, P4, or i2. This really jumped out at me, and fits my suspicions above regarding "~" "In particular aware that if a filename is accessible by a variety of names (perhaps due to symbolic links or hard links), then care must be taken to deny access to all the names." https://bugzilla.redhat.com/show_bug.cgi?id=1187041#c2 It seems a good start would be to locate a P3 on pre V01.07.0090 firmware and confirm how THAT ftpd handled. Then we need to figure if any of the REALLY early Mavic's shipped with that variant. It is possible P0V got ahold of a bird that was in engineering mode I suppose (meaning pre-release firmware version). The decryptor code was seemingly less useful at the end of the day for what folks are trying to accomplish here. I found the *most* utility to be in the fact that it could read the kernel log sans root. $ python dji_ftpd_descrambler.py kernel00.log oOZTPTP7] c0 1 (init) init: untracked pid 621 exited <7>[ 52.603083] c3 0 (swapper/3) Warnning: timer5 int-excep <7>[ 77.938720] c0 419 (dji_hdvt_gnd) bridge: start_xmit info: lmi42 xmit skb cb444000 CP busy! <7>[ 78.001593] c0 461 (keyscan_task) bridge: start_xmit info: lmi42 xmit skb cb444000 CP ready! <7>[ 162.814198] c3 439 (dji_hdvt_gnd) bridge: start_xmit info: lmi42 xmit skb ce24a300 CP busy! <7>[ 162.891897] c0 273 (MB_Socket_Recei) bridge: start_xmit info: lmi42 xmit skb ce24a300 CP ready! <7>[ 356.750230] c0 419 (dji_hdvt_gnd) bridge: start_xmit info: lmi42 xmit skb ce39fa80 CP busy! <7>[ 356.814311] c0 461 (keyscan_task) bridge: start_xmit info: lmi42 xmit skb ce39fa80 CP ready! Being able to pull the DAAK from the kernel command line was interesting for sure... <5>[ 0.000000] c0 0 (swapper) Kernel command line: watchdog_thresh=3 console=ttyS1,921600 vmalloc=412M android firmware_class.path=/vendor/firmware isolcpus=2,3,4 initrd=0x07400000,1M lcpart=mmcblk0=gpt:0:2000:200,ddr:2000:2000:200,env:4000:2000:200,panic:6000:2000:200,amt:8000:20000:200,factory:28000:4000:200,factory_out:2c000:4000:200, recovery:30000:8000:200,normal:38000:8000:200,system:40000:40000:200,vendor:80000:20000:200,cache:a0000:80000:200,blackbox:120000:400000:200,userdata:520000:228000:200 chip_sn=31337000 board_sn=01EAT2D111XXXX daak=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA daek=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA drak=6f707f2962351d75bc089ac34da119fa saak=6f402fb8625205ce9bdd580217d218d8 waek=WIFIPASS production quiet board_id=0xe2200026 @hdnes "Or does it simply read to produce the files", yes... THAT. It is simply a tool to manually decrypt ONE file that you have already pulled, OR to attempt to pull the entire ftpd for you.
-
As a heads up TheDJIProblem on Twitter == MavProxyUser on GitHub. He is I and I am him... slim with my tilted brim.
-
Do you care to share the pinouts? There are at times glitching techniques and other errata that make certain parts of chip memory accessible, etc depending on the chip.
-
Stop by and see us on this thread if you are bored... we are trying to keep the conversation heated up and on topic! Too many folks deviating and using speculation too drive their typing. We want to get back to *real* progress.
-
Can you show us the test points that you have soldered on to?
-
@droner69 I noticed from your "Mountain Pack - speed+atti" dump above the following params: g_config.flying_limit.limit_height_abs_without_gps 2500 g_config.flying_limit.limit_height_absd 2500 g_config.flying_limit.limit_height_rel2 2500 g_config.flying_limit.height_limit_enabled_P 2 g_config.mode_sport_cfg.tilt_atti_range 60 g_config.mode_sport_cfg.vert_vel_up 10 g_config.mode_sport_cfg.vert_vel_downs -10 g_config.mode_sport_cfg.vert_acc_up 10 g_config.mode_sport_cfg.vert_acc_down -10 g_config.fw_cfg.max_speed 20
-
As you guys keep working out *fun* parameters, share them here for folks to use with the websocket tool =]
-
I meant via the archive.is interface... I'm glad another crawler picked it up. I think you took me too literally though.
-
Well played on that btw. I like the way you think.
-
FWIW... I anticipated one of those threads getting eaten and preemptively added it to Achvive.is. The last page was archived 2 weeks ago though. https://archive.is/Ijk4Z
-
Certainly an interesting rabbit hole to head down... I am off on the opposite end of the spectrum worried about the NFZ references in dji_flight ("nfz gps not reliable", "INIT DB", "LOAD DB"), and dji_vision ("nfz monitor", and "query_nfz") and such. See the notes above about how to coax that window into opening. Patching these may be a quick path to enlightenment.
-
Thanks for that... this seems to be interesting reading on the root of the subject. I was not familiar with it. https://segmentfault.com/a/1190000006087527 https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fsegmentfault.com%2Fa%2F1190000006087527&edit-text=&act=url He suggests a few ways to "patch" the cause of the issue.
-
/dev/__properties__ is the Android android: persist system properties are stored. When you type "getprop" this is what you see. These are what the default properties on my Mavic look like. root@wm220_dz_ap0002_v1:/ # getprop [dalvik.vm.lockprof.threshold]: [500] [dalvik.vm.stack-trace-file]: [/data/anr/traces.txt] [dji.encoding_service]: [1] [dji.flight_service]: [1] [dji.hdvt_service]: [1] [dji.monitor_service]: [1] [dji.sdrs]: [1] [dji.sdrs_log]: [1] [dji.system_service]: [1] [dji.vision_service]: [1] [init.svc.adbd]: [running] [init.svc.console]: [running] [init.svc.dji_encoding]: [running] [init.svc.dji_flight]: [running] [init.svc.dji_hdvt_uav]: [running] [init.svc.dji_monitor]: [running] [init.svc.dji_sys]: [running] [init.svc.dji_vision]: [running] [init.svc.sdrs]: [running] [init.svc.sdrs_log]: [running] [init.svc.start_dji_system]: [stopped] [init.svc.ueventd]: [running] [net.bt.name]: [Android] [net.change]: [net.bt.name] [persist.sys.adb.backroot]: [0] [persist.sys.usb.config]: [adb] [persist.sys.vold.primary]: [0] [ro.allow.mock.location]: [0] [ro.baseband]: [unknown] [ro.board.platform]: [lc1860] [ro.bootloader]: [unknown] [ro.bootmode]: [unknown] [ro.build.characteristics]: [default] [ro.build.date.utc]: [1490926279] [ro.build.date]: [Fri Mar 31 10:11:19 CST 2017] [ro.build.description]: [full_wm220_dz_ap0002_v1-userdebug 4.4.4 KTU84Q eng.jenkins.20170331.101040 test-keys] [ro.build.display.id]: [leadcore1860] [ro.build.host]: [APServer01] [ro.build.id]: [KTU84Q] [ro.build.product]: [wm220_dz_ap0002_v1] [ro.build.tags]: [test-keys] [ro.build.type]: [userdebug] [ro.build.user]: [jenkins] [ro.build.version.codename]: [REL] [ro.build.version.incremental]: [eng.jenkins.20170331.101040] [ro.build.version.release]: [4.4.4] [ro.build.version.sdk]: [19] [ro.debuggable]: [1] [ro.factorytest]: [0] [ro.hardware]: [leadcoreinnopower] [ro.product.board]: [evb2] [ro.product.brand]: [Leadcore] [ro.product.cpu.abi2]: [armeabi] [ro.product.cpu.abi]: [armeabi-v7a] [ro.product.device]: [wm220_dz_ap0002_v1] [ro.product.hardware.version]: [Ver0606] [ro.product.locale.language]: [en] [ro.product.locale.region]: [US] [ro.product.manufacturer]: [LEADCORE] [ro.product.model]: [L1860] [ro.product.name]: [full_wm220_dz_ap0002_v1] [ro.revision]: [0] [ro.secure]: [1] [ro.serialno]: [] [ro.wifi.channels]: [] [service.adb.root]: [1] [service.adb.tcp.port]: [-1] [sys.usb.config]: [rndis,mass_storage,bulk,acm,adb] [sys.usb.state]: [rndis,mass_storage,bulk,acm,adb] [wl.link.prefer]: [SDR] I've attached a copy of the resulting file, in the event it is useful for you. __properties__
-
As I recall it... they have progressively added *checks* as the versions went on. With regard to the connection time outs and such, that is your big hint right there for the other versions. Have you considered using Wireshark to see what DJI Assistant wants to talk to *before* giving you access to the unlocked menus? It does vary across versions with regard to what those pre-requisite connections, or interactions may be. Another hint is to try running the program from the console... (older versions were WAY more chatty than newer ones). I assume you noticed it hangs looking for *something* very specific, see if you can spot it here. THIS trick is pretty well "burned" seems more and more people figured it out. $ /Applications/Assistant_1_0_4.app/Contents/MacOS/Assistant --debugger 2017-06-26 14:10:23.670 Assistant[1928:56248989] kCFURLVolumeIsAutomountedKey missing for file:///private/tmp/b/: Error Domain=NSCocoaErrorDomain Code=260 "The file “b” couldn’t be opened because there is no such file." UserInfo={NSURL=file:///private/tmp/b/, NSFilePath=/private/tmp/b, NSUnderlyingError=0x7fd241416cd0 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}} 2017-06-26 14:10:23.671 Assistant[1928:56248989] kCFURLVolumeIsAutomountedKey missing for file:///private/tmp/a/: Error Domain=NSCocoaErrorDomain Code=260 "The file “a” couldn’t be opened because there is no such file." UserInfo={NSURL=file:///private/tmp/a/, NSFilePath=/private/tmp/a, NSUnderlyingError=0x7fd241603af0 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}} PING swsf.djicorp.com (198.105.254.130): 56 data bytes --- swsf.djicorp.com ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss 2017_05_27@22_38_01 - Sat May 27 22:38:01 2017 [ 30] reserved 2017_05_28@00_40_16 - Sun May 28 00:40:16 2017 [ 29] reserved 2017_05_29@21_22_07 - Mon May 29 21:22:07 2017 [ 28] reserved 2017_06_01@12_05_46 - Thu Jun 1 12:05:46 2017 [ 25] reserved 2017_06_01@12_06_41 - Thu Jun 1 12:06:41 2017 [ 25] reserved 2017_06_01@12_09_35 - Thu Jun 1 12:09:35 2017 [ 25] reserved 2017_06_02@13_27_13 - Fri Jun 2 13:27:13 2017 [ 24] reserved 2017_06_02@13_30_34 - Fri Jun 2 13:30:34 2017 [ 24] reserved 2017_06_02@13_48_07 - Fri Jun 2 13:48:07 2017 [ 24] reserved 2017_06_02@13_48_50 - Fri Jun 2 13:48:50 2017 [ 24] reserved 2017_06_02@13_49_26 - Fri Jun 2 13:49:26 2017 [ 24] reserved 2017_06_02@13_49_44 - Fri Jun 2 13:49:44 2017 [ 24] reserved 2017_06_02@13_51_34 - Fri Jun 2 13:51:34 2017 [ 24] reserved 2017_06_02@13_51_47 - Fri Jun 2 13:51:47 2017 [ 24] reserved 2017_06_02@16_35_52 - Fri Jun 2 16:35:52 2017 [ 24] reserved 2017_06_02@16_56_49 - Fri Jun 2 16:56:49 2017 [ 24] reserved 2017_06_02@16_57_49 - Fri Jun 2 16:57:49 2017 [ 24] reserved 2017_06_02@16_58_15 - Fri Jun 2 16:58:15 2017 [ 24] reserved 2017_06_02@17_02_19 - Fri Jun 2 17:02:19 2017 [ 24] reserved 2017_06_04@12_49_31 - Sun Jun 4 12:49:31 2017 [ 22] reserved 2017_06_04@12_56_15 - Sun Jun 4 12:56:15 2017 [ 22] reserved 2017_06_04@12_58_12 - Sun Jun 4 12:58:12 2017 [ 22] reserved 2017_06_04@18_08_44 - Sun Jun 4 18:08:44 2017 [ 22] reserved 2017_06_04@18_10_02 - Sun Jun 4 18:10:02 2017 [ 22] reserved 2017_06_04@18_10_20 - Sun Jun 4 18:10:20 2017 [ 22] reserved 2017_06_04@18_11_16 - Sun Jun 4 18:11:16 2017 [ 22] reserved 2017_06_05@07_57_20 - Mon Jun 5 07:57:20 2017 [ 21] reserved 2017_06_05@08_57_29 - Mon Jun 5 08:57:29 2017 [ 21] reserved 2017_06_05@09_31_07 - Mon Jun 5 09:31:07 2017 [ 21] reserved 2017_06_05@12_48_21 - Mon Jun 5 12:48:21 2017 [ 21] reserved 2017_06_05@12_49_52 - Mon Jun 5 12:49:52 2017 [ 21] reserved 2017_06_05@12_55_33 - Mon Jun 5 12:55:33 2017 [ 21] reserved 2017_06_05@13_51_39 - Mon Jun 5 13:51:39 2017 [ 21] reserved 2017_06_05@14_07_27 - Mon Jun 5 14:07:27 2017 [ 21] reserved 2017_06_05@15_38_05 - Mon Jun 5 15:38:05 2017 [ 21] reserved 2017_06_05@15_43_37 - Mon Jun 5 15:43:37 2017 [ 21] reserved 2017_06_06@00_51_55 - Tue Jun 6 00:51:55 2017 [ 20] reserved 2017_06_06@09_50_06 - Tue Jun 6 09:50:06 2017 [ 20] reserved 2017_06_07@13_20_03 - Wed Jun 7 13:20:03 2017 [ 19] reserved 2017_06_18@00_17_56 - Sun Jun 18 00:17:56 2017 [ 8] reserved 2017_06_18@15_21_20 - Sun Jun 18 15:21:20 2017 [ 8] reserved 2017_06_20@10_10_08 - Tue Jun 20 10:10:08 2017 [ 6] reserved 2017_06_20@16_01_01 - Tue Jun 20 16:01:01 2017 [ 6] reserved 2017_06_21@13_02_48 - Wed Jun 21 13:02:48 2017 [ 5] reserved 2017_06_21@22_14_43 - Wed Jun 21 22:14:43 2017 [ 5] reserved 2017_06_21@22_16_41 - Wed Jun 21 22:16:41 2017 [ 5] reserved 2017_06_24@00_59_00 - Sat Jun 24 00:59:00 2017 [ 2] reserved 2017_06_26@14_02_45 - Mon Jun 26 14:02:45 2017 [ 0] reserved log:[dServer ] Service at19870 qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_client_callback qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_client_method qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_client_method qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_server_method qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_server_method qt.network.ssl: QSslSocket: cannot resolve SSL_select_next_proto qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_next_proto_select_cb qt.network.ssl: QSslSocket: cannot resolve SSL_get0_next_proto_negotiated qt.network.ssl: QSslSocket: cannot call unresolved function SSL_get0_next_proto_negotiated log:[dServer ] 1 Connected <- root If you know the answer, just pipe up for the others that are tired of my riddles. =]
-
Thanks for sharing brother...
-
Will you share with the rest of the group the parameter names you changed... this will go well with the web socket code I posted above (and shared with you previously).
-
There is really no point in sharing if others do not reciprocate... ;) Must keep a cycle of love going...
