Hello, yesterday I received my copyright assignment and today I'll send
it back signed. It obliges me to completely report about the state of my
code. For creating xnu loader I used no other code then my own and
different places in grub as a template. However I have previously seen
APSL-licence
This whole debate made read up a little bit on TPM, for example I
checked http://www.osxbook.com/book/bonus/chapter10/tpm/
(osx book is a very nice resource for mac/os x system internals)
regarding tpms on apple hardware.
Now contrary to what some outdated resources/rumours say, at least all
newer
Jan Alsenz wrote:
phcoder wrote:
Oh, I want!
If I remember correctly, exactly this broke the protection on some
game console!
Do you refer to Xbox crack based on King kong game? For once their goal
is the evil one. For second the problem is a buffer overflow in
rendering engine, not the not che
phcoder wrote:
>> Oh, I want!
>> If I remember correctly, exactly this broke the protection on some
>> game console!
> Do you refer to Xbox crack based on King kong game? For once their goal
> is the evil one. For second the problem is a buffer overflow in
> rendering engine, not the not checking p
Oh, I want!
If I remember correctly, exactly this broke the protection on some game console!
Do you refer to Xbox crack based on King kong game? For once their goal
is the evil one. For second the problem is a buffer overflow in
rendering engine, not the not checking part. If you want to make a
Hi,
Any comment about this ?
On Sun, Feb 15, 2009 at 11:14 PM, Bean wrote:
> Hi,
>
> The new version contains the following changes:
>
> 1, The handler module register commands terminal_input and
> terminal_output. This is for backward compatible of grub.cfg.
> Currently, the commands are regist
Vesa Jääskeläinen wrote:
> Jan Alsenz wrote:
>> Vesa Jääskeläinen write:
>>> I do like the idea what some protected systems use, they sign the binary
>>> (in our case .mod file and kernels of loaded OSes). Now in that scenario
>>> it is responsibility of the kernel module loader to first verify the
Jan Alsenz wrote:
> Vesa Jääskeläinen write:
>> I do like the idea what some protected systems use, they sign the binary
>> (in our case .mod file and kernels of loaded OSes). Now in that scenario
>> it is responsibility of the kernel module loader to first verify the
>> signature for correctness.
Vesa Jääskeläinen write:
> Hi All,
>
> Ok. Please keep the fighting of TPM out of this thread ;). Lets keep it
> to the topic first... (I am already waiting for summary of that other
> discussion at some point ;))
>
> Jan Alsenz wrote:
>> Next I think we can agree, that some sort of trusted boot
Do you know if it is possible to determine where the files come from?
Well it's possible looking at filename and root drive but it's not
reliable (e.g. ata0 can be hd0 but also hd1, when we'll have network
support it will be even less obvious. Actually it's something grub2's
architecture is t
phcoder wrote:
>> Ok, but your already talking of a specific solution here. My
>> conclusion would
>> be: The hooks need to be able to determine the filename, that is
>> currently read.
>>
> And then also where it comes from but some files may have different
> filenames. IMO the solution work indep
Hi All,
Ok. Please keep the fighting of TPM out of this thread ;). Lets keep it
to the topic first... (I am already waiting for summary of that other
discussion at some point ;))
Jan Alsenz wrote:
> Next I think we can agree, that some sort of trusted boot chain can be useful.
>
> Also there sho
Oh... The usage information was left behind :)
You might need to have most recent QEMU and GDB versions for most
challenging bugs :)...
1. Copy grub.gdb and gmodule.pl to your build directory.
2. Create image for QEMU (grub2.iso in my case).
3. Launch QEMU with GDB stub:
qemu -s -S -cdrom grub
Ok, but your already talking of a specific solution here. My conclusion would
be: The hooks need to be able to determine the filename, that is currently read.
And then also where it comes from but some files may have different
filenames. IMO the solution work independently of the order of files
Hi All,
I was debugging some problem lately and felt that I need to use
debugger. As I like how JTAG debugging works I wanted to have similar
feeling :). Obivious choice is to use QEMU.
QEMU provides a GDB stub that can be used to debug code running on its
virtual session. I also found out that V
For some reason he wants to store the data encrypted in multiple
locations rather than using a simple terminal to retreive the data
over network which makes things needlessly hard.
He perhaps needs important amount of computing power. And in his case
"all in centre" may require too much bandwidth
phcoder wrote:
>> - hooks for any disk read (not sure if write is necessary)
> This way how trusted grub does it is an ad-hoc solution which results in
> a MESS. They just try to hash and rehash everything without design. So
> if grub is instructed to load all modules in a directory and filesystem
On 22/02/2009, phcoder wrote:
> >
> > > In any case, if your attacker is that much determined to archieve their
> goal,
> > > reverse engineering a small chip isn't going to stop them.
> > >
> > Reverse engineering the TPM chip is very costly. And I'm not going to try
> to protect data from NSA or
El sáb, 21-02-2009 a las 14:13 +0100, Robert Millan escribió:
> On Tue, Feb 10, 2009 at 12:44:14PM +0100, Javier Martín wrote:
> > >
> > You're welcome. I see that nevertheless the "0 != " comparisons were
> > substituted for standard C int-to-bool-conversion-based comparisons.
> > Maybe people sh
- hooks for any disk read (not sure if write is necessary)
This way how trusted grub does it is an ad-hoc solution which results in
a MESS. They just try to hash and rehash everything without design. So
if grub is instructed to load all modules in a directory and filesystem
is reindexed then gr
Hello!
Alright, lets try to end the pointless (in the sense, that I guess noone here,
including myself, will change their opinion anytime soon) TPM discussion and get
something done.
First I'd say we can agree, that we don't agree on whether/how to use a TPM.
I don't know about you, but I can per
In any case, if your attacker is that much determined to archieve
their goal,
reverse engineering a small chip isn't going to stop them.
Reverse engineering the TPM chip is very costly. And I'm not going to
try to protect data from NSA or CIA or another three-letter agency.
On this you have to t
Robert Millan wrote:
Hi,
The problem with elf64 in our multiboot loader is that it duplicates a lot
of code from elf32 and this eventually leads to bitrot.
In fact, grub_multiboot_load_elf32 and grub_multiboot_load_elf64 are supposed
to be almost identical, and only differ in s/32/64/ reference
23 matches
Mail list logo
