Jump to content

no42

Dedicated Members
  • Posts

    925
  • Joined

  • Last visited

  • Days Won

    17

Posts posted by no42

  1. The schematics should be released by Hak5 licensed under the TAPR Open Hardware License (www.tapr.org/OHL). I have a duck and would like to be able to program it for other uses than originally intended and feel that releasing the schematics should be a given at the price. Any other votes for this ?

    The schematics would make it easier to develop additional functionality, and possible add-ons e.g. flash memory instead of/ in conjunction with the sdcard.

  2. does this firmware still function the same on windows?

    and what about the duckencoder, is there an updated one with a few extra languages?

    thank you Jason and Darren for releasing this

    I am sure once the process for figuring out other languages/key codes becomes second nature will make this project bloom again:-D

    I will try later.... (edit) Actually still works fine in Windows(/edit)

    Sadly, does not work for me in Linux Gentoo kernel 3.2.1, or Ubuntu Kernel 11.04 3.0.1.

    Looking at the USB packets there are descriptors for an apple keyboard (?why?), and it tries to setup Mass Storage support (i can see LUN setup). Still get a few malformed USB packets but not as many as the previous firmware. So the USB handshake looks like it needs more work, but looks like we are getting closer.

    There are a lot of code changes in the hex file...so Im interested in what has actually changed in the code.

    ASF Framework has about 10 layers of abstraction which makes things difficult, but once you get it right, the USB handshake should work on any OS. I don't forsee the need for different firmwares for different OS's. So in theory it should work in both Linux and Windows.

    Think this release is just to settle people, who appear fed up. To prove support is actually still ongoing. ]

    Would be nice to see updates in the git source repo.

  3. I kinda forgot where in the prerequisite circle jerk I'm at, but on BT5R1, I need gmake....

    google has the answer: http://forums.techarena.in/operating-systems/1414561.htm

    Finally, If your going to run linux use a sane distro like ubuntu, or centos - dont run backtrack its missing loads of dependancies (its really a cut-down version of linux, Im surprised it works half the time).

    Buy a ubuntu book, the learn ubuntu, once you've got the hang of it, you can move onto other linux OS's like Gentoo or Mint or Arch.

  4. Does anyone know if the hak 5 devs are still working on this or is it a flop?

    I am not a hak5 developer, and have been working on the Ducky in my spare time.

    Unfortunately, work commitments and bills means my normal day-night job has taken presidence.

    Once I get spare time, I can resume work on the Ducky.

    I looked into alternate firmware LUFA a while back, but the library is more for 8bit AVR's not 32bit, LUFA is easier then ASF but not yet fully supported for 32bit AVRs.

    ASF framework has about 10 layers of abstraction making it hard to weed out bugs. I have had more success in breaking the Ducky rather than making it better.

    Hopefully, we can make progress on the firmware and get it to work in OSX and Linux soon.

    Language Support is a drag, most key scan codes are now known, its just swapping the characters around for individual languages. This would be easier if people with different languages + keyboards would learn a programming language like perl or java. There are examples for UK and German-IBM, I started BE but I no longer have the time to finish this.

    --Snake Out!

  5. 00 00 2F 00 å

    00 00 33 00 ö

    00 00 34 00 ä

    02 00 2F 00 Å

    02 00 33 00 Ö

    etc

    The scan codes are the same on keyboards they are just interpreted differently depending on the language setting. It would be no problem mapping them like you map your ['; or {@: but I just figured there was no point.

    Guess it depends if you ever need to use them? I leave it to the community.

  6. Hardware wise all I've noticed is that the AP51 has a stronger processor and slightly more memory.

    I personally added the Mk 3 features to the fon v1 way back as a POC, the only problem that arose was when network sniffing/MiTM, if the processor hit 100% or the memory hit 100% the fon would reboot, and lose the data.

    I believe the Mark 3, interface and scripts should work on the fon.

    The problem is that its complex and a lot of work, if you dont know what your doing its difficult to debug and fix.

    Darren and the Team are doing an amazing job, at simplifying this processes so that eventually it will be available to everyone.

    Its understandable that we all have other projects/jobs that take up most of our time.

    We all just have to be patient.

×
×
  • Create New...