Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/3031 Thanks!
[Music]
okay so uh Legacy do devices are going
to be our history in fact they already
are our history but unlike my father's
old slide rule where we need to be able
to preserve both the hardware and the
software um and uh my time is going to
be telling us how he's been reversing
the um an old iPod Touch to produce a
qimo iOS version that will allow us to
emulate these devices and keep them keep
them up to date keep them you know
usable into the future and with that I'm
going to hand it over to
mattin thank you very much for the kind
introduction so good evening everyone uh
my name is Martine and I'm very happy to
be here today to present uh my
multi-year project actually on creating
an open source emulator of Legacy Apple
devices and in this 30 minutes talk I
will explain a bit about which device I
emulate how I emulate it uh my
philosophy behind it my Approach and we
talk a bit about the technical details
and this talk will particularly focus on
the iple touch which I believe is one of
the most iconic devices that Apple has
uh ever created and uh this uh talk will
focus on the iple Touch first generation
and the second generation
so a bit about myself uh so I'm a
postdoctoral researcher at epfl in
Switzerland uh my main research focus is
not insecurity but it's more in
distributed systems where I focus on
machine learning systems and the
question on how to make them scalable
and robust but I'm also a reverse
engineering Enthusiast and I've been
doing this for many years and also
during my PhD I managed to publish a
paper that was about the reverse
engineering of mobile banking
implementations so in this project we
reverse engineered a few mobile Banks in
the Netherlands as well uh as in Germany
and other countries and we managed to
automate money transfers and this was
before International money transfers
became very quick uh due to psd2
regulations
Etc so I first would like to talk a bit
about my motivation for the project uh I
think in 2021 I was reading uh a blog
post written by Jonathan EC and it this
blog post he described how he managed to
emulate um an iOS kernel in with qmu uh
and he managed to run into an
interactive B shell and I was reading
this blog post and he gave some
technical details and I was fascinated
fascinated by that that and I was
thinking would it be possible to uh do
that for other device and how difficult
would it be to do it from scratch
because his um his work uh it was very
great but it used a lot of hexs and
works around to get uh working so I
decided to embark on this journey um try
to reverse engineer on the stand uh
about these Legacy devices uh which I
considered at the time a fun Challenge
and I also wanted to contribute a bit to
long-term Hardware preservation because
I think it's it's really nice to have uh
uh devices that are not produced
physically anymore to still be able to
emulate them uh with
software so where to start and the first
question that came to my mind is which
device should I emulate I mean over the
many years that Apple has existed they
have created many different devices and
the contemporary devices if you think
about them are extremely complicated and
as a consequence they are very hard to
to emulate so they have neural engines
they for AI workloads they have phase ID
Touch ID engines secure enclaves which
are very opaque and really difficult to
understand and reverse engineer uh but
also softic security measures like trust
cashes which is essentially a mechanism
uh a set of hashes that Apple considers
trustworthy so you can only run binaries
uh that are in these kind of trust
cashes so I was thinking and actually my
first Apple device was an iple touch 2G
and um I thought well you know let's go
one step back and start with the first
generation iel touch that seems that
device was released in 2007 and it uses
the rv6 instruction set and I thought it
was simple enough to emulate well that
were some famous last words because this
do quite a while in order to get up and
running uh you can see the device here
on the right uh so maybe you did own one
at one point
uh but it got um superseded by the iple
touch 2G uh one year later in
2008 so I was not the first one to
actually uh emulate these kind of
devices uh the first uh serious attempt
I could find uh was in 2012 by uh
someone on Twitter called CMW domme and
he managed to emulate the s5l 8900 uh
which is the S so of the Apple touch 1G
as well as the iPhone 2g and he managed
to get some peripherals up and running
but and he managed to emulate the boot
boot ROM unfortunately I couldn't get
his code to code to run so um even
though he did a lot of work on on on
making uh some peripherals uh documented
um it was a bit difficult for me to to
um directly integrate it and as far as
I'm aware this project and the the the
person behind it uh he also founded
corellian which you might know as the
commercial company that uh provides
virtualized uh iPhone and Android uh
devices there's another work by Jonathan
EC that was the blog post that I was
referring to and he managed to emulate
an iPhone 6s plus uh as well as an
iPhone 11 emulator by Trang um so they
all have have different uh they all
targeted different uh s so's different
architectures uh uh but none of them
actually managed to get into uh had the
iconic user interface uh or get other
components like the multi-touch uh up
and running I'll talk a bit about it
later and finally you also have open I
boot open iBot is an open source boot
loader for um uh early early Apple
devices um um it replaces the main
bootloader and it was originally used to
boot into different operating systems
including Androids which would run uh
although very unstable on uh the ipot
touch
2G and I really learned a lot from all
these projects and I think I wouldn't
have been able to carry out this project
and get this far without uh without like
the help of all these project and all
the people behind this project so I want
to take this opportunity as well to
thank everyone in the open source
ecosystem that has contributed to uh
these projects so I'm very happy with
them
[Music]
yes so let's talk about uh this emulator
so I'm using cuu for the emulation part
uh which is an open source framework for
Hardware emulation uh with qmu you can
Define your machine you can Define your
peripherals and you can uh Define the
expected Behavior once you start talking
to these peripherals uh it is a very
convenient uh framework uh it's also
very wellmaintained and it's very
popular it has integrated support for
many popular uh Hardware uh components
as well as protocols including USB
drivers network interface controllers
SPI sqc sdio so all the kind of
protocols would need to uh create a
device um an emulated device that that
you can actually use so unfortunately it
has a very steep learning curve so it is
in it is a bit difficult to get into but
by looking at uh other projects uh
there's the documentation is also rather
uh well almost non-existent uh but by
looking to other projects and how they
actually uh function uh I was able to
figure out uh a lot of things and also
of course through a lot of trial and
error
and of course during this emulation I
need a way to debug my the binaries that
are being emulated because of course it
doesn't run out of the box I cannot
expect that if I emulate binary it will
like immediately load everything
correctly so I needed a debugger and for
that I use GDB and Q uh by default start
a GDB server so it was very convenient
to who can to this GDB server and be
able to uh debug your binary so you can
see the in screenshot here that you're
able to look at the registers being uh
filled you can uh go through the
instructions uh that helps to understand
program flow um you can step you can um
set hardware watch points and break
points so that that was also very very
helpful in order to um to make progress
in this project and I've actually used
this GDB a lot I think this was my main
debugging tool and even though I am
aware that you can uh write GDP plugins
it is very cumbersome and it really
relies on the particular image that you
are uh using in order um to get
meaningful uh results out of
that and I need to understand binaries
as well right because uh I need to
understand uh what happened what kind of
code is executed when running the
emulator I need to understand where
things can go wrong and where uh the
kernel kernel for example hangs and I
rever engineered all this with gidra and
or gidra however you pronounce it
it is an open source tool created by the
NSA and published by the NSA a few years
ago and um it has support for many
different architectures and instruction
sets um uh in the screenshot here you
can see uh an example of um the SPI
controller the start method to be
specifically you can see the row
instructions and you have the decompiled
uh code on the right as well and if you
set uh your variables and you name your
variables right uh you can actually get
pretty readable uh codee that is very
helpful in understanding how things work
so this shows uh the SPI uh controller
uh which is a key component because it
also uh interacts with many different
things I'll talk about about it a bit
later in this presentation but overall
it is a very awesome
tool Now My Philosophy during this
emulation was that I want to stay close
as close as possible to the real
Hardware I want to follow the co the
execution the code flow exactly as apple
and as the architecture and the binary
intend me to follow it and the reason so
that that means that I want to uh avoid
relying on Hax work around image
patching uh kernel patching whatever uh
because I was under the impression that
this would really bite me later on so
you would um work a bit on the on
getting the device up and running you
would get uh further and further in the
boot stage uh through like patching and
dis abling particular peripherals or
disabling particular function jumps uh
but there is a very high probability
that this will bite you later on and I
found many various occasions where um
and I noticed that um the interaction
with peripherals get more and more
involved as uh the device runs and the
device uh
boots so it it sounded like a good idea
however the emulator in the end ended up
with also with a bunch of hex um some of
them were really unavoidable without
very very extensive uh uh work uh some
of them were well just out of laziness
so uh yeah so I had a few workarounds uh
but I'm pretty sure that with future
work uh we can reduce the number of
workarounds uh in in these emulators but
most of the peripherals uh are actually
uh there so let's dive a bit more into
the details and I will now explain the
the boot chain how exactly the uh these
older iPhones uh and iple touches are
booting
and this boot chain uh is bit involved
it contains various stages it also
starts with the secure on boot ROM which
is like the first stage uh uh the very
first code that actually runs on the
device it is a piece of code that is uh
embedded in the device so finding a
vulnerability in here or a Jailbreak in
the iOS world uh is very much desirable
because you cannot just easily patch uh
this out so the responsibility of that
of the boot Ram is to load the first
level boot loader which is the lowlevel
boot loader or
LLB uh sorry that boot loader loads the
main boot loader which is called iboot
that iboot loads the X and new kernel
the kernel uh then starts a process
called launch D this is the very first
process and runs a super user on the
also for Mech and that launchd uh
program eventually launch the
springboard and springboard is um uh
well the UI chef and that loads the
iconic home screen with all the
applications in there and from there you
can uh start other applications as well
like the alarm Safari uh your timers
your clocks whatever so my goal was to
go beyond existing work and really go to
our springboard and be able to emulate
uh third party uh apps as
well so the boot ROM let let's start
with the first part uh so my initial
atttention was to uh start working on
the boot ROM and get set up and running
and this uh the main functionality of
the boot ROM is basically to initialize
some uh key peripherals like a timer
like a clock some controllers a USB uh
and then it will either load lb the
lowlevel boot loader or it will put the
device into dfu which is a special
restoration mode that allows you to
restore the device through
iTunes so unfortunately uh even though I
was able to run uh a few instructions on
in the boot loader I very quickly found
out that it actually jumps to some
unknown memory locations uh in in the
memory and to date I haven't really
figured out uh what what this this code
at this unknown memory location is uh
nor do I have access uh to this code I
could download the boot ROM actually
from a website so that it's publicly
available but um well this piece of
memory was not available to me so I was
a bit lost there and I couldn't really
continue also since I didn't have a
physical uh device um that time so that
was a bit difficult and I suspect it has
something to do with uh encryption
decryption decryption logic because in
order to load the next um uh binary
there is some some some verification
going on and some encryption and
cryptographic
operations so then I decided well then
let's start with lowle bootloader right
we can load the lowle bootloader into
memory and start emulating that well it
has the same problem it also jumps to
these unknown memory locations so so
that was also not very convenient to me
unless I start like guessing and
Implement these unknown memory location
which at this point I really had no idea
again uh what they were actually doing
so then I decided to skip these two um
components these two images and go
directly to the main boot loader I
boot uh and let's let's also look bit at
code I'm going to show a few Snippets
later on as well uh so in order to to
load with Q IMU you can just um well
fetch the file from um uh from your host
um from your host and load it into
memory you put it into the the ram of of
the emulated guest device um and you set
the program counter to uh the first
instruction in that
image so then I was able to at least
execute some uh execute some uh parts of
I booots um and iboot is mainly
responsible for loading the kernel from
uh the N flash memory from uh your F
system uh and if something goes wrong it
will start it will go into recovery mode
and to understand this I could download
the binary uh but I still had to
decompile the binary uh but it turned
out that the iboot source code actually
got leaked in 2018 uh I was very lucky
with that um so I don't know who leaked
it but uh the person that leaked it I'm
very grateful for them uh or or team
behind it uh because it really helped me
to understand uh some of the
uh devices in particularly the
cryptographic uh engines that uh uh are
actually in the device and how you can
interact uh with
them so before I proceed I would like to
uh draw some attention to something
called the device tree uh the device
tree you might know it from Linux it is
a basically a tree it is a dictionary
that contains uh all the peripherals all
the hardware that's uh that's in your
device and it also contains some
properties of these Hardware like a
serial number or your Mac address or
other uh important uh things uh that you
would need during uh uh execution of the
device so you can see an example here on
the right of the slide uh this is the
AES um uh cryptographic engine uh you
can see some um information about uh
memory about uh which interrupt
controller uh manages interrupts if it
raises an interrupt uh some name some
device type an interrupt code some some
information as well uh for this I
actually used the public uh device Tre
dump on GitHub as reference to on to see
which kind of devices are there and to
also extract as much information as I
could uh from these um uh from this
device tree and now now I was initially
thinking well how difficult can it be to
to to emulate this well I recently made
a diagram with only a subset of the
peripherals that I emulated and this is
how it uh actually looks uh so these
even though these devices are uh almost
15 years old uh they contain many
different controllers many different
Hardware components that are all uh
connected uh uh Mo most most likely
through a system bus but some of these
devices are also controlled uh through
other different protocols like uh um so
for example like SBI or
IC uh so in order to get these
peripherals up and running I had to make
sure that the controller was
uh the the associated controllers were
working uh nicely as
well as I said most of the the hardware
components actually uh are connected to
the system bus and you can interact with
them so the kernel the CPU interacts
with these devices through something
called MMO and MMO stands for memory
mapped IO and it essentially means that
each device get assigned a small part in
the main memory and if you write or read
uh from an address in that memory it
will actually be handled by the device
itself so uh you can see here on the
right um um again a subset of all the
peripherals that I meant that were
needed in order to get the full boot
chain up and running uh there are
actually more than this and there are
also peripherals that I haven't even
touched yet um but it um um but
essentially my task now boils down to
understanding these peripherals uh
understand the registers behind them and
uh basically return the right value when
uh for each
register so let let's look a bit at how
that is done with qemu so with Q IMU you
first have to um well create a machine
uh I won't show the code for that but
assume you have a machine you can then
create the uh peripherals that are
connected to that machine and in this is
in this uh example I'm showing um uh how
the system uh integrated chip um is
declared uh this is a very simple uh
component that simply contains some
generic system information like the
version of the the chipset being used
and I thought it had something like the
time or something so it is relatively
simple so what happens here is that um
uh I I Define a structure with um well
the name of the device uh the parent
which is like a system bus device this
signifies that it is connected to the
system bus uh I create a special struct
which contains the state of this device
so using this structure uh called iot
touch sisic State I can store some
intermediate State and keep track of
things that are going on in the device
itself and uh I I um declare some
initialization methods as both for the
particular instance that I'm creating as
well for the
clause and this is the part where things
got really interesting because uh I now
have to the uh Define and Implement many
different callbacks uh for reading and
writing uh to each of the registers of
each peripheral so at the top here you
can see uh the wreath method um which
takes as uh input some opaque method
which you can simply cast to the state
object that uh that keeps track of the
state of the hardware uh I do that in
the line below that uh it you get the
the offset of um of the register that
you are uh currently reading and you
have some another size variable that I'm
currently not using uh because uh I
always know that the memory
I'm operating in 32bit mode so I always
know that um the value I should return
can be at most uh uh well 32 bit so what
I then do is um based on the the offset
based on the address that I um that this
read meod is called with I have to do
something right and in this case uh if
the power on control register is being
invoked I return a value of 42 now this
value is is I think for for presentation
purposes completely arbitrary but um I
will show in the next slide that things
can get complic complicated pretty
quickly um so like as you move on with
emulation and you get more peripherals
up and running you also have to extend
these kind of methods to return
appropriate values for particular
conditions that you are in because
ultimately the value that you are
returning uh depends on the current
state of the peripheral as well as the
um well register being uh uh being uh
read and Below you can see this uh well
almost the same write method uh this is
called when you write to a particular
register um it it also contains the
value being written and uh you can do
some custom logic uh when particular
registers are being written
to so this is an example of a bit more
complicated uh method this is uh the
read method for the SPI controller um so
in case you are reading from the rore RX
data register I am doing some logic I am
um uh preparing uh a buffer I'm I'm uh
preparing the device to return um well
values um that the kernel that the CPU
uh would expect and the SPI particularly
has taken me uh quite some time to get
right because it it's there are very
like tiny Edge conditions and small
things uh based on the word size based
on uh the buffer sizes
in which you need to return something um
something different than you might uh
expect and finally you can attach you
have to attach your peripheral the
hardware that you created to the machine
itself um uh what you what you do is you
create uh an object in this case it's
the um uh you can see that in the second
line you create um this peripheral uh
you create um you uh well store it
somewhere in the third line uh you
create the MMA o region for that um and
uh after that you can attach some
interrupts uh to this particular uh
device and the the code of the interrupt
that you assign to a device should also
match with um with the one that is
declared in the device tree so this is
where the device tree has been
tremendously helpful to understand um
the interrupt structure between all the
different uh
peripherals so so let's move a bit
higher into uh into the stack so after
the main boot loader has been well
mostly running uh I now had to um well
emulate and make sure that the kernel
runs uh the main responsibility of the
kernel the first responsibility actually
is to set up um some CPU to set up uh uh
tasks uh the task subsystem and then it
will actually start loading the device
drivers and it will load almost all the
yes almost all the uh drivers that the
device uh
needs and um uh for this it uses IIT IIT
is a framework by Apple that you can be
used is used to uh write write drivers
it is very well structured I um so that
was quite nice it was uh um that made it
easier to understand uh what's going on
and starting a driver essentially
usually involves uh writing to some
configuration registers uh uh that
resetting the device clearing interrupts
cleaning up other data so um usually
like my task was to like uh if a driver
starts and it gets stuck somewhere or
you get an error trying to see what's on
what's going on trying to understand uh
uh the expected return code trying to
make sense out of that like instead of
just blindly returning the value that it
would expect I would try to uh look up
uh on the internet I would try to find
data sheets in order to uh hopefully
understand um where which register uh
stores and uh controls what and this was
not always possible like many of these
peripherals that I'm working with are
proprietary uh but most of them follow a
somewhat similar structure you usually
have some registers that are used for
configuration to read the status to uh
set some interrupts to read interrupts
so sometimes you can make sense out of
them uh but some devices are quite
difficult as I will explain I think in
two slides so after all these drivers
are loaded it will actually start launch
D and uh then it will move to uh user
l so this was basically the task that I
was stuck on for uh I think over a year
uh and after after this year I got most
of the important peripherals fully
functional and that would include the
clock the timers the vector interrupt
controllers the direct memory access
controllers and the cryptographic
engines uh so these are very important
in order to get something uh get to some
somewhere useful
and for some peripherals I only have
paral support so uh I just have enough
support to make it past the initial um
stage to make sure that they load and
that the kernel is Happy uh with the
state they are currently in uh that
includes uh peripherals like TV out
which triggers when you connect uh the
device to through USB to uh uh a TV uh
the GPU as well uh the accelerometer and
the light sensors which are I would say
not very critical for uh normal system
operation so about the GPU rendering I
was actually very lucky and I could uh I
was able to avoid G rendering on the GPU
uh by setting a particular flag uh an
environment variable to be specific if
that wouldn't have been possible I would
have to reverse engineer um uh the
communication with GPU so at that time
they were using a power VR
mbx uh which uh is completely
proprietary and as far as I'm aware
there has been no serious effort at
least public efforts to reverse engineer
that uh so and I looked at the device
and it it looks very complicated so I
was very happy that I could uh avoid
that and instead um rely on software
based uh
rendering so lots of work to do still
there are still many peripherals that
are incomplete but at least I'm very
happy that at that point at this point I
could boot to
userland and one of the things I would
also need to boot to user L is
persistence uh so it's during uh during
the boot sequence the device would
occasionally read from uh different
kinds of memory uh persistent memory
like the the nor and the non um they
were they were actually quite different
from between the iot touch 1G and 2G so
in a sense the iot touch 2G has been
like a revamp of of the 1G and that they
basically fixed well many of the
mistakes what they considered mistakes
in the first generation and did
something else in the second
generation the main difficulty here is
that uh what you how you actually store
data on uh on the hardware in in the
actual um actual flash memory is
completely different than how the
operating system sees it and I will show
that in the next slide and figuring out
this particular mapping and how a
particular like page is translated to um
some higher level entity uh took uh yeah
took I think at least two months to
figure out especially for the nons uh
which I will show a diagram in a moment
so I ended upgr a few scripts uh that
convert a ro file system uh as well as
uh the images and then prepares um uh a
nor and a nonmemory that would be usable
by the emulator that I've um I have
written so just to give a quick
impression of of how this uh translation
would work so at the top here you have
uh the F system which is H HFS plus uh
plus and if it would request the block
uh some data from uh your flash drive it
will uh it is is being addressed using
LBA logical block address but this is
not actually how it is stored and how it
uh how the request goes to the actual
underlying Hardware it will undergo
different uh Transformations uh by a
layer called FTL and vfl and then you it
will result in a physical uh page number
as well maybe some other
information so I had to like uh
understand these mapping and then create
basically do the reverse in order to to
uh create the proper file
system so the final uh the most
difficult one of one another difficult
part here was the multi-touch and even
the multi-touch is a peripheral that is
responsible for uh detecting touches and
translating a touch uh into uh an XY
coordinate and even though this sounds
like a very simple problem it is
actually a very uh difficult both
mathematical as well as a physical
problem because there are many
complications when you touch the screen
uh um and this was also evident in the
code because um it has a very
complicated initi initialization
procedure so the moment you would start
this device it uh it would start
calibration it would upload some
firmware uh I found out it's using
sappire 2 so it's some kind of embedded
firmware that is uh um that would has a
firmware being loaded uh and also you
can talk with it through SBI and this is
uh where SBI was really battle tested uh
uh and stress tested uh so I found
different several bucks uh in my SPI
implementation uh uh so I had to get it
up and running before multitouch would
be happy so far I've done everything I
explained without an actual device um
but for this I really required a real
device because uh everything that the um
that the device would that the code
would do I wouldn't understand so what I
did I got got gifted a real device by a
friend and I installed open I boot which
is this open source boot loader and then
I talked to the device um directly and I
would be uh I would read out the frames
and I would play with a touch in order
to understand different values that um
the device would return back to
me so after all this work uh I was very
happy to uh finally see the home screen
being uh rendered it will take uh thank
you this was uh roughly in uh last year
October uh this was the IPO touch 1G and
I decided to immediately move on to the
ipot touch 2G because it has a more it
has an SDK and it also has better
support for thirdparty applications
which is something where I want to go
and up to two months ago I finally got
that also up and running uh with iOS
2.1.1 so yeah that also works now and
thank you
[Music]
again and all I combined all of this in
uh the Q iOS uh emulator which is an
open source emulator uh you can scan the
QR code and you can go to the GitHub
repository uh it currently has support
for the ipot touch 1G and 2G compilation
is a bit difficult though it's usually
it's it's mostly works on Mech but I'm
working on other os's as well and I'm
currently focused on the stability of
the ipot touch 2G and contributions are
more than uh welcome so feel free to
create issues or reach out to me maybe
also after this talk that's it for now
uh thank thank you for your attention
and if you want to know more you can
either go to my GitHub or you can go to
my personal website where you can find
some blog post as well thank
[Applause]
[Music]
you yes I can very quickly give a small
a quick demo um hopefully that works
so I'm not sure how visible it would be
actually um so so it now boots um so it
goes to the the boot loader which is
very quick then it goes to the kernel
and then I think after like 20 seconds
it uh it
boots um multitouch is also working so I
can use my cursor to uh control the
device uh I can press buttons I can uh
go back to the home screen uh and I can
also uh type some stuff as well so
overall it is pretty functional I'm
still haven't installed third party apps
but hopefully a volunteer here or
contributor can help me do this so I
think that's all for
now awesome my time so uh we have some
time for questions um we have four
microphones in the room and we have a
signal agel on the internet um are there
any questions there I see one on
microphone 3 hi thank you for your talk
um you mentioned something about frames
in your debug screenshot um maybe I
missed it but what is a frame in this
context yeah that that's a very good
question I actually prepared a slide for
that um so let me go let me go back um
uh to that um I think this should work
uh yes so um if you um talk to the
multi-touch uh driver it will um give
you back something called a frame which
is essentially a data structure that uh
usually has uh other data structures in
there so in this case this Frame
consists I think of of three different
layers and at the lowest layer you have
a frame that uh has some information
about a particular touch on the screen
it has like a u um an XY it has some
velocity of how you move your finger as
well as a radius like like how how
basically how big your finger is and uh
some depth so I hope that answers your
question a bit on what the frame is
thank you um question from microphone
four uh hi great talk I'm actually
wondering about thec on those devices
because I presume it's Samsung so I'm
wondering if you had like found some
public documentation about it about
interrupt controller and stuff uh the
interrupt control Yes actually yes uh
particular in the the uh interrupt
controller is actually um uh a viic 192
I think or pl1 192 uh so this this is
actually a device that uh is very
closely related to another uh documented
device so there were like some some very
tiny differences between these two that
I had to figure out how uh were
different but but some of them indeed
were were were partially open okay and
one more question if you don't mind uh
are you planning to upam this to Kimu or
are you going to keep it your three um
what exactly uh are you planing to
Upstream those changes to qim or oh uh
Upstream the changes oh uh that's a good
question I haven't really thought about
it yet um I don't know I haven't really
read into the policy of cimu so that
would also depend on the uh on the
developers there um most of the code is
is very hacky but then I looked at other
examples in qim as well and they're also
well not uh the nicest code out there so
yeah maybe okay thank you very much
microphone one thanks for the
interesting talk I would like to know
what happened to those unexpected
addresses The
Bu sequence jump to in the you mentioned
in the beginning
uh thank you for your question so you
asked like what happened to these
unknown memory instructions what you do
with those um I actually found out later
on in the kernel yeah I didn't really
have time for that to go into more
details uh when executed the kernel I
actually found out there is um there was
again this jump to um to this uh memory
location although indirectly through the
low-level bootloader and that would like
trampoline to another instruction and um
but then at that point I had more
contacts so I was pretty sure it is
related to the uh to the crypting the um
uh the the image the firmware image so
as you might know um you have this ipsw
file which is like the main uh uh bundle
the main operating system for iOS and
all these files are encrypted and at
that time they were using img2 which is
like a horribly broken format right now
but that logic that um that you mention
actually contained the decryption for
that so what I did I used a workaround
to uh patch that memory address jump to
qim implement uh my decryption logic and
c and then put back the right decrypted
uh image in memory so that's how I
circumvented uh this decryption okay
thanks microphone to yeah thank you for
the great talk um I was wondering you
were mentioned corelan before which is
uh a vendor providing uh virtual devices
for uh Apple products right um Apple
doesn't really like their devices to be
virtualized which we could see from the
5 year long lawsuit where Apple tried to
sue
corellium like uh how do you see like
the the legality or like did you already
receive a letter from the Apple lawyers
or something thank you for your question
no I I think I'm I'm still too
insignificant uh to receive any uh seas
and deas de any letters or something
related to that uh talking about
corellium I think it's pretty impressive
what they managed to pull off because uh
emulating this kind of stuff is really
really difficult and they have much more
things going on including Wi-Fi
jailbreaking uh uh direct access to to
the raw memory things I can only like
dream of in my emulator right because
that would make debugging so much uh
more difficult uh I mean to be fair I
don't think many people would care if if
like you um emulate uh these Legacy
devices uh the moment you start going to
more recent devices things would get
more interesting uh uh for example I'm
thinking about reversion engineering the
secure and clay for the neural engine um
but again these devices are one
extremely complicated and two the uh the
decryption keys of the the firmware is
not public so I have very little hope of
actually moving uh beyond anything uh
than the let's say the iPhone x or
11 and we have one final question from
the
internet um there is there any work on
the iPod Classic as well and there's
what
is there any work on the iPod Classic
yes there is um I think you have it's
called Rockbox it is an open source um
um operating system and kernel for uh
the ipot touch classic um it uses some
similar peripherals uh I think the
factor interrupt controller and the dma
are similar uh I actually talked with uh
I think it was half a year ago someone
was in uh in loan where I live and and
he dropped by and we talked and he he
worked on RSE engineering the iPod uh
iPod Classic and other uh older iPods
gener um devices and he actually
explained a lot about me that the things
that I didn't know like how um about the
storage thing so so yeah I really I
learned from them as
well and with that um that's the end of
our session could you join me in in
thanking my time on this wonderful talk
and very important talk for the
future
[Music]