Alright, because I had the feeling that the simple "UNIVERSAL" password didn't unlock all commands, I set out to find out how the weird password with ~'s is created that the rom upgrade utility uses.
Here's what I came up with after several hours of debugging/disassembling
Code:
unsigned long Crc32Table[256] =
{
0x00000000, 0x77073096, 0xEE0E612C, 0x990951BA, 0x076DC419, 0x706AF48F, 0xE963A535, 0x9E6495A3,
0x0EDB8832, 0x79DCB8A4, 0xE0D5E91E, 0x97D2D988, 0x09B64C2B, 0x7EB17CBD, 0xE7B82D07, 0x90BF1D91,
0x1DB71064, 0x6AB020F2, 0xF3B97148, 0x84BE41DE, 0x1ADAD47D, 0x6DDDE4EB, 0xF4D4B551, 0x83D385C7,
0x136C9856, 0x646BA8C0, 0xFD62F97A, 0x8A65C9EC, 0x14015C4F, 0x63066CD9, 0xFA0F3D63, 0x8D080DF5,
0x3B6E20C8, 0x4C69105E, 0xD56041E4, 0xA2677172, 0x3C03E4D1, 0x4B04D447, 0xD20D85FD, 0xA50AB56B,
0x35B5A8FA, 0x42B2986C, 0xDBBBC9D6, 0xACBCF940, 0x32D86CE3, 0x45DF5C75, 0xDCD60DCF, 0xABD13D59,
0x26D930AC, 0x51DE003A, 0xC8D75180, 0xBFD06116, 0x21B4F4B5, 0x56B3C423, 0xCFBA9599, 0xB8BDA50F,
0x2802B89E, 0x5F058808, 0xC60CD9B2, 0xB10BE924, 0x2F6F7C87, 0x58684C11, 0xC1611DAB, 0xB6662D3D,
0x76DC4190, 0x01DB7106, 0x98D220BC, 0xEFD5102A, 0x71B18589, 0x06B6B51F, 0x9FBFE4A5, 0xE8B8D433,
0x7807C9A2, 0x0F00F934, 0x9609A88E, 0xE10E9818, 0x7F6A0DBB, 0x086D3D2D, 0x91646C97, 0xE6635C01,
0x6B6B51F4, 0x1C6C6162, 0x856530D8, 0xF262004E, 0x6C0695ED, 0x1B01A57B, 0x8208F4C1, 0xF50FC457,
0x65B0D9C6, 0x12B7E950, 0x8BBEB8EA, 0xFCB9887C, 0x62DD1DDF, 0x15DA2D49, 0x8CD37CF3, 0xFBD44C65,
0x4DB26158, 0x3AB551CE, 0xA3BC0074, 0xD4BB30E2, 0x4ADFA541, 0x3DD895D7, 0xA4D1C46D, 0xD3D6F4FB,
0x4369E96A, 0x346ED9FC, 0xAD678846, 0xDA60B8D0, 0x44042D73, 0x33031DE5, 0xAA0A4C5F, 0xDD0D7CC9,
0x5005713C, 0x270241AA, 0xBE0B1010, 0xC90C2086, 0x5768B525, 0x206F85B3, 0xB966D409, 0xCE61E49F,
0x5EDEF90E, 0x29D9C998, 0xB0D09822, 0xC7D7A8B4, 0x59B33D17, 0x2EB40D81, 0xB7BD5C3B, 0xC0BA6CAD,
0xEDB88320, 0x9ABFB3B6, 0x03B6E20C, 0x74B1D29A, 0xEAD54739, 0x9DD277AF, 0x04DB2615, 0x73DC1683,
0xE3630B12, 0x94643B84, 0x0D6D6A3E, 0x7A6A5AA8, 0xE40ECF0B, 0x9309FF9D, 0x0A00AE27, 0x7D079EB1,
0xF00F9344, 0x8708A3D2, 0x1E01F268, 0x6906C2FE, 0xF762575D, 0x806567CB, 0x196C3671, 0x6E6B06E7,
0xFED41B76, 0x89D32BE0, 0x10DA7A5A, 0x67DD4ACC, 0xF9B9DF6F, 0x8EBEEFF9, 0x17B7BE43, 0x60B08ED5,
0xD6D6A3E8, 0xA1D1937E, 0x38D8C2C4, 0x4FDFF252, 0xD1BB67F1, 0xA6BC5767, 0x3FB506DD, 0x48B2364B,
0xD80D2BDA, 0xAF0A1B4C, 0x36034AF6, 0x41047A60, 0xDF60EFC3, 0xA867DF55, 0x316E8EEF, 0x4669BE79,
0xCB61B38C, 0xBC66831A, 0x256FD2A0, 0x5268E236, 0xCC0C7795, 0xBB0B4703, 0x220216B9, 0x5505262F,
0xC5BA3BBE, 0xB2BD0B28, 0x2BB45A92, 0x5CB36A04, 0xC2D7FFA7, 0xB5D0CF31, 0x2CD99E8B, 0x5BDEAE1D,
0x9B64C2B0, 0xEC63F226, 0x756AA39C, 0x026D930A, 0x9C0906A9, 0xEB0E363F, 0x72076785, 0x05005713,
0x95BF4A82, 0xE2B87A14, 0x7BB12BAE, 0x0CB61B38, 0x92D28E9B, 0xE5D5BE0D, 0x7CDCEFB7, 0x0BDBDF21,
0x86D3D2D4, 0xF1D4E242, 0x68DDB3F8, 0x1FDA836E, 0x81BE16CD, 0xF6B9265B, 0x6FB077E1, 0x18B74777,
0x88085AE6, 0xFF0F6A70, 0x66063BCA, 0x11010B5C, 0x8F659EFF, 0xF862AE69, 0x616BFFD3, 0x166CCF45,
0xA00AE278, 0xD70DD2EE, 0x4E048354, 0x3903B3C2, 0xA7672661, 0xD06016F7, 0x4969474D, 0x3E6E77DB,
0xAED16A4A, 0xD9D65ADC, 0x40DF0B66, 0x37D83BF0, 0xA9BCAE53, 0xDEBB9EC5, 0x47B2CF7F, 0x30B5FFE9,
0xBDBDF21C, 0xCABAC28A, 0x53B39330, 0x24B4A3A6, 0xBAD03605, 0xCDD70693, 0x54DE5729, 0x23D967BF,
0xB3667A2E, 0xC4614AB8, 0x5D681B02, 0x2A6F2B94, 0xB40BBE37, 0xC30C8EA1, 0x5A05DF1B, 0x2D02EF8D
};
unsigned long Crc32(const unsigned char *pData, unsigned long nSize, unsigned long nPrev=0) {
unsigned long nCrc32=nPrev;//^0xFFFFFFFF;
while (nSize) {
nCrc32=((nCrc32) >> 8) ^ Crc32Table[(*pData) ^ ((nCrc32) & 0x000000FF)];
pData++;
nSize--;
}
//nCrc32 = nCrc32^0xFFFFFFFF;
return nCrc32;
}
//By TheBlasphemer
void DecodeSecurityBuffer(unsigned char *szBuffer) {
unsigned char pSolution[16];
memset(pSolution,20,sizeof(pSolution));
unsigned long nFirstCrc=Crc32(szBuffer,16,0);
unsigned long nSecondCrc=Crc32(szBuffer,32,0);
unsigned long nThirdCrc=nFirstCrc+nSecondCrc;
memcpy(pSolution,&nFirstCrc,sizeof(unsigned long));
memcpy(&pSolution[4],&nSecondCrc,sizeof(unsigned long));
memcpy(&pSolution[8],&nThirdCrc,sizeof(unsigned long));
unsigned long nFourthCrc=0;
unsigned long i;
for (i=0; i<12; i++)
nFourthCrc+=pSolution[i];
memcpy(&pSolution[12],&nFourthCrc,sizeof(unsigned long));
for (i=0; i<16; i++) {
if (pSolution[i]<'0')
pSolution[i]='0';
else if (pSolution[i]>'~')
pSolution[i]='~';
else if (pSolution[i]=='=')
pSolution[i]='>';
else if (pSolution[i]=='?')
pSolution[i]='@';
}
memset(szBuffer,0,32);
memcpy(szBuffer,pSolution,16);
}
void DecodeRadioSecurityBuffer(unsigned char *pBuffer) {
unsigned char pSillyStuff[]={0x1F,0x00,0x1E,0x01,0x1D,0x16,0x0A,0x0F,0x0E,0x08,0x03,0x19,0x06,0x17,0x11,0x0B,0x0A,0x11,0x00,0x16,0x04,0x0C,0x1D,0x07,0x0F,0x1A,0x01,0x0B,0x0D,0x10,0x17,0x1F};
unsigned char pTraditionalBuffer[32];
unsigned short al=0;
unsigned long i;
for (i=0; i<32; i++)
pTraditionalBuffer[i]=0xCF-(i*4);
for (i=0; i<16; i++)
pTraditionalBuffer[i*2]=pBuffer[pSillyStuff[i]];
DecodeSecurityBuffer(pTraditionalBuffer);
for (i=0; i<32; i++)
pBuffer[i]=0xFF-(i*3);
for (i=0; i<16; i++)
pBuffer[pSillyStuff[16+i]]=pTraditionalBuffer[i];
}
How to use them?
To identify with the normal bootloader
send an "info 3" command. This will send you a lot of data encapsulated within HTCS(data)(crc)HTCE.
You need 32 bytes starting from offset 0x100 (256).
copy that data to a new buffer, pass it to DecodeSecurityBuffer, and that same buffer will now contain the 16-byte password
This is tested on the Universal, and it also matches the information on the Hermes
To identify with the radio bootloader
First send "rtask a" to go into bootloader mode. Then send "rinfo". This should again give you a lot of data encapsulated in a HTCS-HTCE block.
copy 32-bytes starting from offset 0x2B0 to a temporary buffer, and run it through DecodeRadioSecurityBuffer. This new buffer now contains the radio password, but it is not a normal string.
To use it, send "rpass \r" (mind the space between rpass and \r), then send "HTCS" + the password + the Crc of the password as bytes + "HTCE". It should either return "T " for succes, or "F " for failure (Encapsulated in the HTCSHTCE block)
This was only tested on the Universal
Have fun, and let me know if it's of any use
I've tested the algoritms on the Hermes too and they work, so the password and radio-password calculations are the same on both TyTN and Universal.
The attachment shows the USB log on the Hermes.
It is possible that the algo was not changed since himalaya.
And knowing radio bootloader password may give the another method of SIM unlocking/IMEI manipulation. Who would check that?
Well, as far as I know, you're the only one capable of something like that... I have no idea where to get started on that
mamaich said:
It is possible that the algo was not changed since himalaya.
Click to expand...
Click to collapse
Don't know about Himalaya, but I can confirm it is the same on the Alpine Bootloader.
mamaich said:
And knowing radio bootloader password may give the another method of SIM unlocking/IMEI manipulation. Who would check that?
Click to expand...
Click to collapse
How can we test that? my Hermes is SIM Unlocked, the Hermes bootloader has no help at all, and there's not much known info on the radio bootloader commands:
http://wiki.xda-developers.com/index.php?pagename=Hermes_BootLoader
(see the bottom of the page)
Also, do you know if it is possible to get SuperCID on the Hermes? Where should I start looking to gather info on that?
Thanks!
TheBlasphemer: I've not had a chance to test your stuff yet, but thanks for your great research! You've been missed, nice to have you back
V
pof said:
I've tested the algoritms on the Hermes too and they work, so the password and radio-password calculations are the same on both TyTN and Universal.
The attachment shows the USB log on the Hermes.
Click to expand...
Click to collapse
POF，how do you do!
if SPL=1.06， CAN OBTAIN CID？ CAN OBTAIN SUPER CID?
MY CID have closed.
howto run it through DecodeRadioSecurityBuffer
How do you actually "run it through DecodeRadioSecurityBuffer" do you have to use some sort of program to use this script??
Thanks for the code. Works fine with BlueAngel too.
FYI:
"info 6" - it is probably query for AC power state. Nothing more.
Presently we're running a little short on kernel exploits, with the following being the only one that looks remotely plausible:
http://xorl.wordpress.com/2010/01/14/cve-2009-4141-linux-kernel-fasync-locked-file-use-after-free/
Big hold-up? For all that we have a trigger, we don't have an exploit. I believe it's up to us at this point to make that happen.
If I'm reading it right, it looks like the bug initially rears its head right here:
Code:
void __kill_fasync(struct fasync_struct *fa, int sig, int band)
{
while (fa) {
struct fown_struct * fown;
if (fa->magic != FASYNC_MAGIC) {
printk(KERN_ERR "kill_fasync: bad magic number in "
"fasync_struct!\n");
return;
}
[B]fown = &fa->fa_file->f_owner;[/B]
/* Don't send SIGURG to processes which have not set a
queued signum: SIGURG has its own default signalling
mechanism. */
if (!(sig == SIGURG && fown->signum == 0))
send_sigio(fown, fa->fa_fd, band);
fa = fa->fa_next;
}
}
... as fa_file now points to invalid memory (having been free'd earlier). The f_owner member gets shot out to send_sigio, which look like this:
Code:
void send_sigio(struct fown_struct *fown, int fd, int band)
{
struct task_struct *p;
enum pid_type type;
struct pid *pid;
int group = 1;
read_lock(&fown->lock);
type = fown->pid_type;
if (type == PIDTYPE_MAX) {
group = 0;
type = PIDTYPE_PID;
}
[B]pid = fown->pid;[/B]
if (!pid)
goto out_unlock_fown;
read_lock(&tasklist_lock);
do_each_pid_task(pid, type, p) {
send_sigio_to_task(p, fown, fd, band, group);
} while_each_pid_task(pid, type, p);
read_unlock(&tasklist_lock);
out_unlock_fown:
read_unlock(&fown->lock);
}
... in which we see the f_owner member being dereferenced. Also it gets pushed through several other functions which may be exploitable.
There are several questions to be answered before we can start attacking this:
Can we resolve the address of the fa_file data structure so we can overwrite the f_owner value?
Can we do anything with it once we've done that? (Presumably we can set it to zero to cause a null-pointer dereference, but we're mmap_min_addr = 32768 on the most recent versions, so unless we can flag the mmap region to grow down and apply memory pressure to reach page 0 this will do us no good.)
Failing the plan above: are any of the functions that f_owner gets pushed into vulnerable? I evaluated this over the weekend, but without the help of a trained kernel dev I'm not going to get very far.
While I studied a lot of this in uni, I'll admit I'm green when it comes to actually writing these exploits. I'm hoping that this will get the creative juices flowing, and perhaps provide a more comprehensive resource in case any hard-core kernel hackers want to take a look at what we're doing or give us pointers (harhar) in the right direction.
Thanks, guys. Great work up to this point.
In the original POC if you change /bin/true to /system/bin/sh you can get a new shell to open just not as root. So I'm guessing that their needs to be more added to the POC to make it a full exploit.
Right, the fork()'s in the PoC exist only to cause the file descriptor's fasync_struct to be erroneously killed, not start a root session. The root session would need to be started (presumably) by the kernel doing something to our maliciously crafted fown_struct.
The tough part is figuring out exactly where and what that fown_struct needs to be.
Well I definetly agree with you that this seems to be our best best bet I am some what of a newbie when it comes to linux allthough i am learning as i go. Do you know of any good sites to read up on kernel hacking?
Sorry Guys just got the word that this one is dead for us.....
Here is the explantion i got.
some_person said:
Nope, the bug didn't exist in 2.6.27. That's why they say >= 2.6.28 are vulnerable.
As far as how the bug works, there are 2 other issues. 1) our kernel probably wasn't compiled with AT_RANDOM 2) we don't have an elf executable.
The exploit you found does not give us root access, it crashes the system. Basically, you open the "random number generator" file, lock it, and close it... but the lock release when you close it. Then you have to call an elf executable because that generates a random number (running an elf executable) provided the kernel was compiled AT_RANDOM. you continue to call that executable (and generating random numbers) until the the lock is released on the "random number generator" file... then it's your program's turn... the kernel tries to send your program notification that the file is available, but your program has moved on. BLAM the kernel stops (or "oops").
Click to expand...
Click to collapse
Sorry to dredge up an old thread:
This exploit *will* work. According to Zanfur, the hole is in our kernel. We need to use it without AT_RANDOM (which I dont know how to do).
http://sourceware.org/ml/libc-alpha/2008-10/msg00016.html
I am pretty sure we do have elf executables, here is proof:
% file m6
m6: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
If our kernel is susceptible to this bug then it should work, as long as there is a way to do it without at random.
Though I do not in any way represent my self as a hacker or developer I was wondering if I could throw in my 2 cents. I notice that this bug/exploit won't work because it requires AT RANDOM. I was wondering if it s possible to write code that does what the function does and insert it in. Is root required to do this (i.e. insert code into the kernel that wasn't there before) or is this a matter of know-how? Just some brainstorming I thought that I would throw in.
jballz0682 said:
Though I do not in any way represent my self as a hacker or developer I was wondering if I could throw in my 2 cents. I notice that this bug/exploit won't work because it requires AT RANDOM. I was wondering if it s possible to write code that does what the function does and insert it in. Is root required to do this (i.e. insert code into the kernel that wasn't there before) or is this a matter of know-how? Just some brainstorming I thought that I would throw in.
Click to expand...
Click to collapse
This won't get us root. Even zanfur said it. Moving on....
Framework43 said:
This won't get us root. Even zanfur said it. Moving on....
Click to expand...
Click to collapse
To clarify, even if we get AT_RANDOM functionality working, we can't use this to exploit our kernel. All we can do with this is get data from a file that was recently closed. The point of this exploit is to send a signal to a process, but there are no processes we could send a signal to that would give us root.
Our kernel seems practically invulnerable, it appears that almost all exploits are patched
I need a way to search in StorageFiles with dynamically pattern, which comes from a TextBox. The directive "Windows.Storage.Search" doesnt exist in windows phone 8.1 runtime, as i saw. Now my question is, how can i do this in alternative way?
The only way to do it with WP 8.1 since Microsoft ALWAYS fails to implement the important things are to query using LINQ.
Ex:
Code:
var result = (await Windows.Storage.ApplicationData.Current.LocalFolder.GetFilesAsync(Windows.Storage.Search.CommonFileQuery.OrderByName)).
Where(x => x.Name.
Contains(x => txtBox.Text));
That's about all you can do pretty much. (Thanks Microsoft).
Thank you for the example. But it wont work for me, it shows me the following error(s):
Code:
A local variable named 'x' cannot be declared in this scope because it would give a different meaning to 'x', which is already used in a 'parent or current' scope to denote something else
and
Code:
Cannot convert lambda expression to type 'string' because it is not a delegate type
Thats really odd from Microsoft, that they havent implementet the search function like in WinRT (Windows Store App).
The first error is pretty simple. You already have the variable named "x" and it would be very bad if compiler didn't give you that error.
Change the name of the variable to something else that you don't use in that scope and it will work.
And for second problem, try this one:
Code:
private List<string> Result()
{
var result = ((List<Windows.Storage.Search.CommonFileQuery>)Windows.Storage.ApplicationData.Current.LocalFolder.GetFilesAsync(Windows.Storage.Search.CommonFileQuery.OrderByName)).Where(x => x.ToString().Contains(txtBox.Text));
return result as List<string>;
}
private async Task<List<string>> ResultAsync()
{
return await Task.Run(() => Result()).ConfigureAwait(continueOnCapturedContext: false);
}
You should call ResultAsync method and get the result in this way:
Code:
List<string> myList = ResultAsync().Result;
That's not going to work. You can't cast a StorageFile as a string.
To fix my code (simple lambda typo)
Code:
var result = (await Windows.Storage.ApplicationData.Current.LocalFolder.GetFilesAsync(Windows.Storage.Search.CommonFileQuery.OrderByName)).
Where(x => x.Name.
Contains(txtBox.Text));
if(result.Any())
{
// Do shtuff
}
Also, you should never access the .Result of an async task because you never know if it completed yet.
Ok, first error is done, but the second error is still here
Code:
Cannot convert lambda expression to type 'string' because it is not a delegate type
You are missing the point of the TAP (Task Async Pattern).
Both main thread and async method will be in execution in the same time. When the async method finish his work, main thread will stop and catch the result trough the Result property.
TAP is the recommended way of asynchronous programming in C#. The only thing with TAP is to use ConfigureAwait method in non-console type of apps to avoid deadlock.
Sooner or later you will get the result from TAP method. Nothing will get in the conflict with the main thread.
Oh wait, @andy123456 I updated my response. I forgot String.Contains ISNT a lambda .
@Tonchi91, I know all about the TAP. I've been using it since it was CTP. I've seen the awkward situations with threading in WP .
Now... if he did
Code:
List<string> myList;
ResultAsync().ContinueWith(t=> { myList = t.Result; });
I wouldn't be worried .
Ok the errors are gone, but the debugger show me the following exception:
Code:
Value does not fall within the expected range
Is this search method case-sensitive? I tried with an exact input in the TextBox.
Hmmm. Let's see your full code.
its actually only for testing, so i added your code to a button (asnyc) and will show the output in a textBlock.
Code:
private async void buttonTest_Click(object sender, RoutedEventArgs e)
{
//Result();
var result = (await Windows.Storage.KnownFolders.CameraRoll.GetFilesAsync(Windows.Storage.Search.CommonFileQuery.OrderByName)).
Where(x => x.Name.
Contains(textBox_test.Text));
if (result.Any())
{
// Do shtuff
textBlock_test.Text = result.ToString();
}
}
The error is coming from here
Code:
var result = (await Windows.Storage.KnownFolders.CameraRoll.GetFilesAsync(Windows.Storage.Search.CommonFileQuery.OrderByName))
andy123456 said:
its actually only for testing, so i added your code to a button (asnyc) and will show the output in a textBlock.
Code:
private async void buttonTest_Click(object sender, RoutedEventArgs e)
{
//Result();
var result = (await Windows.Storage.KnownFolders.CameraRoll.GetFilesAsync(Windows.Storage.Search.CommonFileQuery.OrderByName)).
Where(x => x.Name.
Contains(textBox_test.Text));
if (result.Any())
{
// Do shtuff
textBlock_test.Text = result.ToString();
}
}
The error is coming from here
Code:
var result = (await Windows.Storage.KnownFolders.CameraRoll.GetFilesAsync(Windows.Storage.Search.CommonFileQuery.OrderByName))
Click to expand...
Click to collapse
Oh Camera Roll.. You MIGHT need to have the capability to view the camera roll enabled. I forget what it's called, but you need a specific cap in order to view from there. Also, I would try to see if you can use a generic folder instead.
I would try Windows.Storage.ApplicationData.Current.LocalFolder.GetFilesAsync() as your method after the await just to test whether you can read correctly.
Yes but in wp8.1 runtime app, there arent caps anymore. The capability for access to the pictures is simply calles pictures library and is enabled. I have tested it as you said, but it gives me the same exception.
A quick tip: another way to do this is to use the Win32 C runtime API. You can, for example, use the FindFirst/NextFile functions (http://msdn.microsoft.com/en-us/library/windows/desktop/aa364418(v=vs.85).aspx) which support searches using wildcards (* and ? characters in the first parameter). These functions are wrapped in my NativeLibraries classes, but are also just publicly available for third0party developers to call from their own C++ DLLs.
Alternatively, you can use the .NET System.IO.Directory class, which has functions like EnumerateFiles(String path, String searchPattern). This is probably the better way to do it, actually.
Of course, if you want these operations to not block the current thread, you'll need to explicitly put them in their own thread or async function.
EDIT: This also assumes you have read access to the relevant directories. You application data directory works fine, for example (you can get its path from the relevant StorageFolder object). Other directories that can be accessed via WinRT functions may go through a broker function instead of being directly readable.
The point is, that i have an array with filenames. Now i need the StorageFile files which contains these filenames. My idea was to search for these files and return the files as StorageFile, so i can work with these. Or is there a simpler / another way?
http://msicc.net/?p=4182 <-- try this
Thank you, i have already done this and its working. But how can i compare the Files to read, with already read files and take only the not yet read files?