Well, we already have source and binaries of ssh for Playbook (command-line).
We also have ftp, irc and a hundred other nice things.
How long would it take to add a GUI when we get native SDK? Hm, probably first day.
Printable View
Well, we already have source and binaries of ssh for Playbook (command-line).
We also have ftp, irc and a hundred other nice things.
How long would it take to add a GUI when we get native SDK? Hm, probably first day.
If we can ssh into the playbook as root (once somebody figures this out), does this mean that we can finally start playing with its core settings, because i cant wait to write a app for the playbook that lets the user access all the hidden settings once the Ndk comes out.
On a side note if we can eventually figure out a way of getting root access does somebody want to write a quick command line app for it so we can access it right from the device, i mean it is QNX after all and that's just Linux at heart so its only fair that we have a terminal.
Technically it should be possible to make terminal and ssh right now by using Air for the UI and bundling the console apps.
Air lets you run a native binary or not? It will have the permissions but is there an API?
Failing that, perhaps a console app that runs air app.
I wonder if this thread is what made RIM (possibly) change their mind. First Kevin suggests PlayBook updates were halted until the big 2.0 release, but today 1.0.7.2942 gets released according to Bla1ze's twitter. I still don't see the update yet (still have 1.0.7.2670) but ...
Either way, I'ma hold off updating to see if this thread progresses.
Sent from my BlackBerry 9780 using Tapatalk
Read up on Adobe Native Extensions if you want to bundle native code with an AIR app. By the time you get it working right, the NDK will be out ;)
Hah! Come on now... By the time RIM releases the NDK I could have learnt Air from scratch and coded this, and my coding/scripting skill goes no further than mirc and a little bit of bash currently.
I'm predicting the NDK is RIM's present for the PlayBook's birthday.
*EDIT* looks like i was wrong about the NDK hah. I've not been so happy to be wrong in quite a while.... yay RIM
When using blackberry-connect to start the listener it pushes the public key to the devuser account so I assume blackberry-connect is set up to only send to devuser...would this be considered a true statement?
Would there be a way to change bb-connect to push the public key to a different user?
How did you determine SSH is enabled for root? We cannot get into roots home dir /root to see if it has /root/.ssh/xxxxx. Root would need a public key set up somewhere, even if you find it it would be next to impossible to crack it to get the private key wouldn't it?
Would getting access to user upd or apps be just as good as root for most cases...depending on what you want to do I guess??? Not that that would be any easier then getting root right.
What is this from? Did you sniff the dtm connection?
Forgive me it's been a while....cheers!
The dtmauth code is viewable in /pps/system/dtmauth by devuser.
And yes, upd would be about as useful as root. It would allow us to enable ad-hoc wifi, usb otg and other such things anyway.
Edit: And we have Native SDK beta ;) http://03268fe.netsolhost.com/bbbeta/
I guess HaTaX was referring to:
- "PermitRootLogin yes" in /etc/ssh/sshd_config
- the following public / private keys
/var/etc/ssh/ssh_host_rsa_key
/var/etc/ssh/ssh_host_rsa_key.pub
Code:$ cat /var/etc/ssh/ssh_host_rsa_key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3GMBQoWXA4d1jGufHk5qYis4ttYqOJLearHILCt2aPKqQzTbPLW/Yx+VXMaNNYxsTVdECfuS4iYzTfN+QJqccGUfWLHpwdOod/GdAMh+rCRcclsMYVASnSYsAPnxqfg80Wc49Ti9/NJlgySNRLc4EsePxlhERwm1PINkfAoGYFfAkdRDoGiVGhwM17qT5MyTdmEZrp67TTNhsXHKn1VeKCgNzfCh5Fmcb43iBJT0XRgG9hsVoNCC/0KSZBdANTLmefstdYh3YXHAhH8cRDQl8sI2HiWU1BRZxvHV6LouR9h0/vrFXs2M/PzgyegB5LaKGuQ6Z1v5bEezzYjXcJ8Bqw== root@localhost
blackberry-connect starts sshd on the playbook, but unfortunately with devuser restriction
anybody decompiled Connect.jar which is what blackberry-connect runs? Wondering if devuser is sent from it$ pidin -F%n%A 2> /dev/null | grep sshd
usr/sbin/sshd /usr/sbin/sshd -D -o permitopen="127.0.0.1:8000" -o PasswordAuthentication=no -o AllowUsers=devuser -R
I decompiled Connect.jar. The file you are interested in is jqconndoor.jar.
I can confirm that there is never a mention of devuser or AllowUsers when the client connects.
I assume this also prevents devuser from running sshd again with root allowed or simply using login.
/etc/shadow is empty, you can't simply use login anyway
decompiled connect.jar/jqconndoor.jar too, on the playbook side it connects to the binary /base/bin/qconnDoor
and guess what?
jqconndoor.jar has still a lot of potential, there's plenty of optionnal/overridable settings ;)Code:t:bin tieum$ strings /Users/tieum/Downloads/qconnDoor |grep devuser
AllowUsers=devuser
P.S., I found this:
Seems to allow iPod devices and mounts them to /fs/ipod
$ cat /base/etc/enum-usb.conf
# IPod Devices
#
Device vid=05AC,did=12*
#
##Check for the presence of an Audio class interface first. If the Audio class
##interface is present, use that configuration. If it is not present, select
##the configuration with a UMASS class interface.
#
Config class=01
Set usr_spec_id=AppleIpod
Set inc_usr_spec_id=/fs/ipod
Config class=08
Also, this. A http server running as root?
$ cat /base/etc/inetd.conf
#ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd -l
#telnet stream tcp nowait root /usr/sbin/telnetd in.telnetd
#http server is required in production to do backups and development installs
#http stream tcp nowait root /usr/sbin/bozohttpd httpd -c /opt/www/cgi /opt/www/root
https stream tcp nowait:120 root /usr/sbin/bozohttpd httpds -c /opt/www/scgi-dev -Z /etc/www/cacert.pem /etc/www/privkey.pem /opt/www/root
And yeah qconnDoor only allows devusers. If we could overwrite it, we could get root. But we need root to overwrite it :(.
By the way, qconnDoor only has one fixed purpose. It doesn't accept any commands. You validate the QCONNR301Z signature and then the swallow string and it opens sshd and qconn -- both only with devuser access.
This string in qconnDoor gives me a good chuckle
Must have been some Monty Python fans within the QNX group. :)Code:What's the airspeed velocity of an unladen swallow?
Maybe you guys would find the setuidgid file from the current 2942 image useful?
Yeah I saw that string when I was sniffing the packets when I was writing my own Connect app in Qt.
Said Connect app is now released here.
Makes this guide redundant. Is capable of running on all OS, including ones without Java such as mobile phones.
Thanks! This is great. There are a bunch of tools I need to compile for a proper work environment.
@xsacha
I have just a small question
Does "/tmp/setuidgid root /bin/sh" still work in ssh
If yes we're can I get setuidgid
Cause we can't cp it from system.:cool:
Doesn't work for me... using the setuidgid binary from the above post.
$ ls -l setuidgid
-rwxrwxrwx 2 devuser devuser 18288 Aug 25 2011 setuidgid
$ /tmp/setuidgid root /bin/sh
setuidgid: fatal: unable to setgid: permission denied
$ /tmp/setuidgid root /proc/boot/ksh
setuidgid: fatal: unable to setgid: permission denied
That looks a bit chicken / egg to me. Surely if that's a binary to do a setuid and setgid, it'd probably need to be owned by root with at least setuid bit (and presumably setgid bit set) in terms of it's permissions?
And it's been a while, but don't some flavours of Unix not like that if write perms are completely open? (I could have dreamt that bit though...)
You can't chown the binary to root or set setuid, so I think this hole is closed.
One potential attack vector is to modify the binary permissions on system startup. It's possible to do this on the latest Android, there's a small window where any commands can be run as root after doing a bogus backup and restore.
That's why I said it's kinda chicken / egg - you can't do it because you need the elevated rights, and the binary won't actually do the setuid / setgid because it doesn't have the correct permissions.
If you can get it on there with the correct permissions, that'd be one thing - but I can't see how without actually having root. (Notwithstanding what you wrote in your next paragraph).
As a Unix systems programmer, in a past life, nearly every Unix platform I worked on, that had a C compiler, I tended to write and compile, chown and chmod my "chon" (or whatever you wanted to call it) "utility" - but that was more about retaining the ability to still assume root, as opposed to never actually having it. Once you've managed to get on as root, even briefly, one way, or another, you've got something to work with, but without being able to act as root - however briefly - even if you have a precompiled binary like this, it's not going to work unless you can get the owner and perms set.
I don't have access to a computer for a while, are these binaries available online without installing momentics? If not I'd really appreciate getting them.
I installed BGShell Plus and I don't even have access to diff nor elvis, ouch!
Posted via CB10